Take the 2-minute tour ×

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?

share|improve this question
Specifically for the decorator, look at NSProxy - stackoverflow.com/questions/4312339/… . GoF patterns seem to be trying to solve language deficiencies in C++. Look to see if there are other idioms within objective C that do not need a pattern to implement. Don't try to write C++ in objective C. –  MichaelT Jun 13 '12 at 19:02
add comment

1 Answer

up vote 3 down vote accepted

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.

share|improve this answer
add comment

Your Answer


