Incorporating GoF design patterns in Objective-C without Abstract/Virtual classes

Question

As someone who is becoming more comfortable working in Objective-C I would like to be able to incorporate more design patterns and OOP features in my projects but struggle to implement them as required by GoF because you cannot create an abstract class. I want to 1) avoid lots of subclassing, 2) minimize use of respondsToSelector, conformsToProtocol, etc, 3) avoid techniques like swizzling as much as possible, 4) maximize encapsulation, and 5) avoid long conditionals or lots of typedef enum.

For example, in a recent project I wanted to separate RestKit (a library for accessing RESTful services) from my UIViewController subclasses. I did so by incorporating an Adapter between the two with a base class of ModelController, which could access models. I also created the ModelControllerDelegate protocol for my VC's to wire up. But I experienced great difficulty in creating a ModelControllerDecorator without the use of an abstract base class. I wanted to be able to decorate my ModelController with different aspects, like PaginationDecorator, CompressionDecorator, QueryableDecorator, and so forth.

I've heard that using Objective-C++ is one way to incorporate more OOP features, but how about using standard Objective-C language features? How have you been able to incorporate GoF design patterns that use C++ style features (like virtual classes) in your projects?

Answer 1

I'm not sure why you would think that Objective-C's implementation of OO is in any way inferior to C++'s? Many, including the inventor of the term "OO", would argue that the opposite is true: Objective-C's OO is as good as Smalltalk's OO because, well, Objective-C's OO is Smalltalk's OO. It even uses Smalltalk's syntax!

The GoF book contains Smalltalk code for all the design patterns, the design pattern movement started in Smalltalk, many design patterns were first discovered and described in Smalltalk.

Note, however, that some of the Smalltalk implementations in the GoF book are of questionable quality. Meaning, they try to stay too close to the C++ implementation and don't leverage some of Smalltalk's dynamic features. Some of the patterns aren't even necessary at all in a language like Smalltalk or Objective-C, yet the book still contains Smalltalk implementations for them. (Three of the GoF came from the C++ community, only one from the Smalltalk community, so this kind of bias isn't really unexpected.)

I also don't quite understand why you think you can't have abstract classes in Objective-C. Of course, you can have classes where some of the methods are to be implemented by subclasses. That's the whole point of subclasses in the first place!

About Objective-C++: Objective-C is a language that was created by orthogonally bolting Smalltalk sideways onto C. One major design goal was that the Smalltalk and the C parts should not interact with each other. Objective-C++ is the same. The Smalltalk and C++ parts don't interact. Which means that you have a language with two independent, completely orthogonal type systems, and two independent, completely orthogonal object systems that do not interact or integrate at all with each other. The only thing it makes sense to use from C++ in Objective-C++ are the things that are not about OO: templates, mostly.