In my previous post, I posted some code from the CentralPA CFUG presentation that Scott Stroz and I used. It used an ObjectFactory.cfc file that I had created prior to the presentation and am kicking myself for not doing/using this earlier. Now you're probably saying to yourself... "Another ObjectFactory!!!". Yes, this one I hope will prove to have its uses.

First, a bit about objectFactories. In a nutshell, objectFactories are nothing more then an object that returns other objects given a key. Meaning once objectFactory is instantiated in the application (in our case in the Application scope as a singleton), I can simply get to any objects "known" within the objectFactory by calling it like this:

One of the advantages to this approach is obvious, there's no need to defined the entire path to the object everytime I need to instantiate it. This comes very handy if I have to make changes to my object paths, for example while using a proxy object to wrap the original object (see Decorator Pattern). When using an objectFactory, all my object paths are all in one place and not scattered throughout my entire application. Here's an example of a regular objectFactory:

And this could be instantiated in my application as:

And anytime I want to use an instance of an object I simply call it like this:

As you can see the create method simply returns the appropriate object. So if I need to change the path to use a proxy object or an object that extends the object type already in my code I simply edit the ObjectFactory.cfc file.

Okay, that was a basic example of objectFactory, now why implement object oriented principles and still have to edit the ObjectFactory.cfc file everytime I want it to be able to return a new object. Isn't the reason we like CFC's because we can reuse them across our applications? Hence the improvements I made to the ObjectFactory.cfc. First, why hard code all objects in my application in the cfswitch statement if I can simply tell the ObjectFactory.cfc what objects are there on application start? By allowing me to register each object information once into my factory and store it into a Struct data type, it now can be reused and also the create method can run faster without the need to figure out which object to instantiate via the cfswitch.

Another improvement made was to be able to tell the ObjectFactory in the register method that an object is a singleton, meaning I only want that object instantiated once in my entire application and shared everytime it's requested. This is very useful for objects like DAO's, Gateways, and Config Beans. Since in ColdFusion complex objects are passed by reference, the ObjectFactory simply stores a reference to the instantiated object before it returns the object to the user. Since ObjectFactory is already being persisted in the Application scope, the singleton object is also persisted. So let's take a look at the new improved Object Factory below:

Notice that once I instantiate the object (see Listing 4) I can then register each object into it:

For those objects I want to be instantiated as singletons like RegistrantGateway and FeeGateway notice the third optional argument is set to true. Also, in this case we are registering all objects explicitly in code, you could also read an xml file with objects definition info in it and loop through the content and register them automatically. As you can see this ObjectFactory can now be reused in any of my applications without having to make application specific changes to it, it's also a bit faster in that it doesn't have to do any loop or switch statements to find the object to instantiate it (this would really be significant in applications with many objects but worth mentioning).