How to Make iPhone Apps

How to Get More Code Flexibility with an Abstract Factory

Matthew Campbell, August 12th, 2009

Now it is time to take things a little bit further and make our code super flexible.

We already know how a factory pattern can work since we implemented an example of a factory in the previous article. That gave us a central place to handle the production of objects in our system.

In order to get the ability to change our entire app in just one line of code we need to go further and convert our factory into an abstract factory. That this means is that instead of having a factory that returns a set of objects we will first have a definition of a factory which we think of as the abstract factory. Next, we will have multiple factories that satisfy the definition of a factory but return separate variations of objects.

Here is what we are going to do to convert our code from yesterday into something that would support the abstract factory pattern.

Change Factory’s class methods into instance methods

Since we want to be able to swap out specific factories in place of the single Factory that we have been using we will need to work with instances. In other words, we will not be able to rely on class methods. The first thing we need to do then is to change all of the class methods in Factory into instance methods.

NOTE: class functions and class methods are used directly with a class name while instance functions and methods require an instantiated object to be used.

To do this we simply open the Factory.h file and change all the plus signs in front of each method into minus signs:

Do the same for the implementation file:

Define two more factory classes that inherit from Factory

To do this I simply added two new NSObject classes using XCode. Then I defined the class to inherit from Factory and not NSObject. My new factories classes are called Factory_A and Factory_B (real original huh?).

I also made sure to change the code in the original Factory back to the simple default objects. Here is what Factory_A interface file looks like:

Override Factory’s methods to customize our new factory classes

If you just leave the methods alone your new factory will behave just like the old one. If you want to change the objects that are returned you can override the functions like so:

As you can imagine Factory_B follows a similar pattern, but it is returning a different title string and a different view controller. Now we have three ways to use factories to build our objects and soon it will easy to swap them out.

Add a Factory property to the app delegate

The easiest way to make our factory available every component in the system is to simply add it as a property to our app delegate. Our property can just be defined as “Factory” since all of our factory objects will inherit from Factory.

In the implementation file you can use @synthesize in the usual way to finished the factory property.

Assign a factory object to the Factory property

Now it is simply a matter of assigning an instance of the factory object to our app delegate’s factory property and we are set:

Opps – One More Thing To Do!

Back in my view controllers I was simply using the class function to get the title from the Factory class. I now need to get the title from the factory instance. To do that I need to retrieve the factory instance from the app delegate. This is how each component will get access to the factory instance:

Essentially, all we did was replace the functionality of our original static factory with an instance of a Factory. The real power will come into play when we want to test a different build that we have coded into a new factory instance. The only place we will need to change our code (once everything else is set) is in the app delegate where we assign the instance variable. So, now we can have all of our code centralized AND we can swap out entire builds by simply assigning a different factory instance.