Some Ways to Use the Abstract Factory

Matthew Campbell, August 14th, 2009

In the last post we implemented an abstract factory pattern, but we did not really use it all that effectively.

Today I am doing to demonstrate how (and possibly why) to use an abstract factory. So, right now we can switch our app the build to the default Factory, Factory_A and Factory_B. To do this we simply have to change one line of code in our applicationDidFinishLauching method.

The reason that I like this pattern is that I can cleanly test variations of a program without harming the components that are already there. All I need to do is to assign a different factory in my app delegate and I can change the whole app.

The simple answer for me is that I am an architecture geek when it comes to programming. I am fascinated by the idea of arranging objects into different patterns. This pattern has proven successful for me on other platforms (more on that tomorrow though).

But, there are some other reasons you may want to do something like this.

One application of this pattern is to test the effect of changing interfaces on your user’s behavior. For instance, if you are considering testing a new feature you could make a certain percentage of your users see one build.

Then you could use analytics packages such as (look up Pinch Media) to observe their behavior. Or you could simply survey your users to see how they react to the update before unleashing the update to the masses.

One obvious thing you could test is a build that included ads in your app to see if that turns off your users too much.

If you have customers that want essentially the same application but with just a slightly different feature set you could use this feature to provide different variations of your app to each user. Your users could select the build they wanted from the preferences pane on the iPhone and you could change what build you want to use the next time they start the app.

eBookAd1.001.jpg

For some people this pattern can make it easier to maintain code in the future. This is because it is very easy to swap out objects to test how they behave with different builds. However, this benefit really comes down more to programmer preference.