Ramifications

[Previous] [Next]

The Object Factory design pattern allows a client application to remain oblivious to the properties of concrete classes that implement the interface the client expects. As a result, the concrete classes can be modified to introduce new behavior into the client application without the client's knowledge. The client code remains frozen and rebuilding the client application is not required. Depending on the system design, you might not even need to restart the system to realize the new behavior. This capability is utopia for a software system.

Utilizing the Object Factory design pattern allows the component designer to regulate the creation process of concrete class instances. For example, you can prohibit creation of an object if the client doesn't have the required security clearance. Another situation worth considering is from a purist standpoint: an object should never be created in an invalid state. A client should be able to invoke all interface methods without the object raising an exception as the result of invalid state conditions. The Object Factory design pattern allows you to create an object in any of its possible states, or in some cases a single valid state, by permitting the client to pass parameter values to its interface creation methods.

The previous two points combined make the Object Factory design pattern a crucial ally and sometimes a required partner in implementing many of the other design patterns described in this book. For example, implementing the Singleton design pattern (Chapter 10) would be impossible. A local/remote transparent Smart Proxy design pattern (Chapter 7) would be very difficult to accomplish. The Repository design pattern (Chapter 11) would be less elegant.