Software Design Patterns

FM/AF Compared

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().

 

 

 

 

0 Comments