My Favorite Pattern....

In my first post to this blog I mentioned that you are unlikely to find any ground breaking software ideas. My target audience is the beginning to intermediate programmer that is learning coding and design. I stand by that, that is the spirit with which this is written.

Several years ago, the "Gang of Four" came out with their book "Design Patterns: Elements of Reusable Object-Oriented Software". Much to my chagrin, I've never read the book cover to cover. I have resorted to reading interpretations by others. To be honest, I've only used a few of their patterns in real life. The Factory Method Pattern, however, is one that I find myself using over and over. There is a ton of information available on the net about it. There is nothing new here, but this is my contribution to the reader on how I use it.

The factory method pattern allows multiple similar objects to be created and used by the application, without the application having to know a lot of the details of what the objects are doing. In my opinion, one of the keys to writing a good maintainable application is to remove as much detail as possible from the top level code. The details need to be "hidden" in lower level objects. The trouble with this idea however is that you create many small objects that do similar yet different functions. These objects need to be able to share commonly needed functionality while being able to add their own distinct functionality. This is where the factory method pattern excels.

Here are a few real world examples that I've implemented lately:

An application needs to be able to generate several reports. Each report has its own set of parameters that it needs. Some reports require a specific date, while others need a date range for example. There is a common UI used to provide the parameters for the report, once the needed data is provided, each report does it's own thing in generating the output.

A food broker needs to be able to communicate with multiple external entities (manufacturers, distributors, customers etc.) via EDI. The EDI format is standard, and like all standards, everybody has their own version of it. The application needs to communicate with all external entities using their version of the "standard".

A company that hosts conferences needs to be able to update a Microsoft Dynamics CRM database on site during the conference. They have a custom application that uses bar codes to identify attendees that need to be updated. Several different types of business entities need to be updated. The workstations that the attendees visit communicates with a common server and send transactions depending on the update needed. The server needs to identify the transaction and send the correct update to Dynamics CRM.

Enter the factory method pattern...

The factory method pattern allows several similar yet different classes to be created easily. Each class can share common code (placed in the base abstract class) but has the ability to modify the functionality to meet its individual needs. The factory class is responsible for identifying the needed concrete object and creating it. The controlling code can then use the created object as needed without knowing the specific class that has been created.

In the report example listed above, the base class contains needed UI support routines as well as an abstract GenerateReport() method. Each concrete implementation can override the UI routines as needed as well as implementing the needed report generation. The factory creates the concrete report object based on the user's selection. The controlling code interrogates the created object to find out what parameters are needed and shows or hides input controls based on the information needed. Once the parameters for the report are provided, the GenerateReport() method is called to create the final output.

The EDI example may be obvious, the abstract base class contains common EDI functionality, the concrete classes implement each entities version of the standard. The factory determines who we are talking to and generates the appropriate class. The differences in formats is completely hidden from the controlling application.

In the Microsoft Dynamics CRM example, the server receives a transaction from a workstation, the factory determines what type of concrete class is needed, the concrete class implement the logic needed to update the appropriate type, the abstract class provides support logic needed by all concrete classes.

So what are the benefits of doing things this way? Here are a few off the top of my head:

1. The top level code doesn't contain the detail of what is begin updated and how. The logic at the top level is minimal, understandable and maintainable.

2. For each detailed concrete class, the code required is minimal. If you design the base abstract class well, then you will find that each concrete class contains very little code, only the code required to implement the differences will appear.

Ok, I have to come up with some shortcomings of the pattern...

Hmmm....well, I guess some folks my struggle with inheritance, however, if you are going to be a successful developer using object oriented languages you will need to become very familiar with that. You especially need to be very familiar with some of the qualifiers like public, protected, static and abstract. I love the static keyword, it means very different things depending on where its used.

Documentation is key. It is difficult to look at the code and determine what is going on unless you are familiar with the specific technique. Learn UML, a picture is worth a thousand words goes for documentation as well. Assume that the person coming behind you to maintain your code is a beginner. You will thank me one day because if you stay in this business long enough, there will come a time when you look at your own code and say "What was I thinking?"