Factory Method and Abstract Factory
Compared
Both:
Factory Patterns
Decouple applications from specific implementation.
Client only needs to know abstract type of product.
|
Factory Method |
Abstract Factory Pattern |
|
For creating single products: (ie: DetailedRiskScore) |
For creating families of products:
|
|
Uses classes to create |
Uses objects to create |
|
Create via inheritance |
Create via object composition |
|
Uses subclasses for creation. |
Provides abstract type for creating a family of products.
Subclasses of this type define how products are produced. |
|
Extend a class and override ‘factory’ method that creates the objects. This subclass knows about the ‘concrete product’ type but its client only knows about the abstract product type. |
|
|
|
Create a ‘concrete factory type’ and pass it into some code that is written to work against the ‘abstract factory type’. |
|
Small interface (one factory method). |
Big interface (because many products). |
|
|
|
|
|
*If new products are added, then the interface must change, then the the interface of every factory subclass must change. |
|
|
|
|
|
*Often uses factory methods to create products. |
|
|
|
|
Participants: |
|
|
There are 2 sets of classes: [ IProduct <- Products], [ICreator <-Creators]. |
|
|
Creators and Products derive from interfaces. Creator relies on it’s subclasses to define the factory method which returns a Product of IProduct type. Functions other than the factory method may exist in the base class. |
|
|
The ICreator and IProduct may actually be one set of classes with the Factory method implemented in the Product class itself. A self creating class, if you will.
For instance, lets say we have RiskFactors each have a static Create() method. Why static? We don’t want to create objects in the client code
-RiskFactor a = new LocationRiskFactor().
But this would be ok
-RiskFactor = LocationRiskFactor.Create().
|
|