Feature

Many times object-oriented programming (OOP) is billed as the end-all solution to cure the spaghetti code that can come from procedural style applications. After all, you just have to stuff your logic code into a component (big OOP buzzword - encapsulation), and now your code is instantly better, right? How hard is it to stick a createObject function call or a <cfobject> tag in when you need to access that bit of code? Can anybody look into the future and see a problem here?

Let's look at an example. Many object-oriented articles use cars as examples, so we'll stick with the trend. When we need to find out information about a given car, we simply instantiate the Car object as follows:

<cfset oCar = createObject('component', 'com.mydomain.Car').init() />

Nice and easy, right? However, our application is going to get a bit more complex. Our car is not going to do much without an engine and a transmission. An engine and a transmission are not a simple property though; these are also objects with their own properties. In order to build our model, we need a couple more lines of code.

<cfset oEngine = createObject('component', 'com.mydomain.Engine').init() />
<cfset oTrasmission = createObject('component', 'com.mydomain.Transmission').init() />
<cfset oCar = createObject('component', 'com.mydomain.Car').init(oEngine, oTrasmission) />

Still, not too bad. But what happens when the business model continues to grow? None of us have ever experienced anything called scope creep, right?

The Problem
Every time we need a new Car instance, we have to remember all of the different dependencies a Car object has (the engine, the transmission, etc.) and write all of the different createObject function calls (in the right order) while getting the component path for each one correct. But wait, at the moment, our Car object is kind of dumb. We need to go to the database and load information about our car, right? We need to create some data access objects, each of which requires a data source object. The stack of objects we need just to create a car almost makes you think about going back to procedural programming!

Add in the difficulty of a component path changing or a new dependency being added to the car object and all of a sudden we have spaghetti code all over again. So much for OOP being the solution to all the world's (or at least software developments) problems!

Introducing Design Patterns
If OOP is not the solution, then Design Patterns must be, right? Well, maybe. Design Patterns are simply standard solutions to common issues that arise in software design. Many design patterns apply to object-oriented development, but not all of them. A design pattern is not a piece of code that you can simply plug into your application. It is more of a template that offers guidance on how to solve different problems that may arise.
Some different examples of design patterns include:

• Decorator Pattern: Wrap an existing object with a new "decorator" and expand the functionality of the original object without making changes to the code.
• Singleton Pattern: Restrict implementation of certain objects to a single instance across the application.
• Façade Pattern: Provide a simplified interface to a larger collection of objects.
• Observer Pattern: Allow objects to interact with their environment without being tied to it.

The Factory Pattern
Today, we are going to look at the Factory Pattern, which will hopefully help clean up some of this mess we're in. In the real world, what does a factory do? It makes things, right? Think of the GM Bowling Green Assembly Plant. At one end you say "I want a new red Corvette," and at the other end of the factory, out comes a new Corvette (a new instance). I don't know anything about creating engines or transmissions. All I did was ask the factory for a new Corvette. Somewhere within the factory is the knowledge of what exactly makes up a Corvette and where to find all of the parts. The factory takes care of building the car without my having any knowledge of these specific details. Wait, factories don't have to be this specialized. In fact, I can go to the GM Bowling Green Assembly Plant and ask for a new blue Cadillac XLR. Once again, my order goes in one end and out pops a car from the other end without my having any knowledge of exactly how the car was built. This one factory builds multiple kinds of cars, possibly using some of the same parts, but all of that implementation is hidden.

How does this apply to object-oriented development?

The Object Factory
Let's take the auto assembly plant and turn it into an object model. In the business case, I know that a Car is made up of a whole series of other objects - things like an engine, transmission, seats, and even the stereo system. I don't want to keep track of all of these dependencies every time I need a new car. The solution? An auto assembly plant or, in other words, an object factory. I need an object that I can ask to give me instances of other objects. In this example, I would have a Car factory object that I could ask for different types of cars and the factory object would then give me the completed object without my code having to know anything about what makes up a Car.