Gof Factory Method

Attendees:

   Alejandro Oyarbide
   Jack Azoulay
   Martin Laplante
   NicolaeGiurescu
   PatrickHodoul
   Steve Hebert

Discussions:

   1. Application of Factory Method in Frameworks design.
   2. Factory Method helps in isolating possible changes.
   3. Working with type, not implementation classes.
   4. Design Patterns sell an idea, not an implementation.
   5. Importance of documenting the use of design patterns in design docs/code.

Explanations

Intent: The intent is "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclass".

As explained in the intent, the typical application of Factory Method is in Frameworks.

What is a framework? A framework uses abstract classes to define and maintain relationships between objects. A framework is often responsible for creating these objects as well. The big picture for a framework is a skeleton of an application.

Do I need a Framework? The answer is depending of your context. If you create a Framework that will be used only once, perhaps it isn't the good solution. If you create a Framework that is used at least twice (or could be used several times later), the Framework is a good solution. You must never forget that the Framework gives you a skeleton with a default behavior, this point could be very interesting.

Explanations: A possible example is: you want to create a Framework (skeleton) for a building. In advance, you know some basic behavior (interactions) of your building. You will have rooms, with windows and doors, without any precision of the kind of room you will find and also the number and the kind of windows and doors. You know some basic behaviors, which could be that you need a door (which can be opened or closed), and one or more windows in each room. So you build your framework with these limitations. Now, you want to create a real building, based on your framework. You will have a specific room with two specific windows and a specific door, and the default behavior in enough. In this context, you can use the GoF-FactoryMethod to specialize the framework to your real building (in other words, this room has this door and this window).

As you can see, the GoF-FactoryMethod imposes to work with type, not implementation classes. This could be a huge advantage when implementing the default behavior or when you specialize your Framework. With this example, a door could be opened or closed. You work with the type door and not with a specific implementation of a door (even, you don't have to know what specific door you are working on).

This pattern also helps in isolating possible changes of parts. For example, you can decide to change (at compile time) the specific door you use for a specific room, without any impacts in the code. This is a side effect of working with type and not implementation.

General remarks This last part is more a general discussion about the Pattern representation in your design and code.

Design Patterns sell an idea, not an implementation. As you should never forget, the pattern gives you an idea to solve a recurrent problem. The intent was never to give you an implementation solution, the pattern gives you a possible solution with its own limitations and strengths. The purpose of the pattern is the intent, nothing else.

Importance of documenting the use of design patterns in design docs/code. As mentioned during the meeting, it's important to correctly document in the design and in the code, the use of patterns. The purpose of this recommendation is to help other developers to identify patterns and for juniors to discover pattern. In the maintenance phase, the correct documentation of patterns will explain classes relations. This aspect is also important if you want to use the patterns as a language.