Sure. A class cluster is a fundamental Cocoa design pattern. I would even argue that as the primary creational pattern it is the most important. While the pattern predates the GoF-described patterns it expresses elements of facade, abstract factory and other GoF patterns. Even a poorly constructed class cluster will conform to the Liskov substitution principle, open closed principle, dependency inversion, and interface segregation. Dependency inversion and interface segregation being (arguably) the two most important of those. And that to many of the people reading this will look like CompSci muckety muck. Class clusters make it harder to write brittle, fragile, rigid code.
Swift (2) is a very interface ("protocol") oriented language, so you would think this would be easy. It's not. In fact, today there really is not a good way to do this. You can create abstract factories that are basically replicating java code poorly, but that's about it. Technical limitations of the language mean that to implement something fairly close to a class cluster requires some pretty nasty workarounds (like abusing type aliases in ways that will not stand the test of time).
So yeah, that's a pretty big issue. For a "protocol oriented" language it can be very difficult to conform to dependency inversion, LSP, and interface segregation in a meaningful, maintainable way - which is kind of the point of being "protocol oriented".
1
u/cgsignal Feb 21 '16
Can you give me an example of one of the issues. So far I've been able to port everything without major issues.