Abstract Factory

Intent

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Class diagram of the original GoF pattern

Improvement in MixJuice

Solved Problem(s)

Extensibility problem

In order to add new kinds of products, new creation methods should be added to AbstractFactory and ConcreteFactory classes. (This problem is mentioned at p.90,line.4-9 in the GoF book.)

Used programming technique(s)

Abstract method addition to AbstractFactory.

Consequences

• (+) New kinds of products can be added without modifying the source code.
• (-) Addition of both a new kind of products and a new concrete factory requires a complementary module.

Structure and pseudo code

module original {
  define abstract class AbstractFactory {
    define abstract AbstractProductA createProductA();
    define abstract AbstractProductB createProductB();
  }
  define class ConcreteFactory1 extends AbstractFactory {
    AbstractProductA createProductA(){...}
    AbstractProductB createProductB(){...}
  }
  define class ConcreteFactory2 extends AbstractFactory {
    AbstractProductA createProductA(){...}
    AbstractProductB createProductB(){...}
  }

  define abstract class AbstractProductA {...}
  define class ProductA1 extends AbstractProductA {...}
  define class ProductA2 extends AbstractProductA {...}

  define abstract class AbstractProductB {...}
  define class ProductB1 extends AbstractProductB {...}
  define class ProductB2 extends AbstractProductB {...}

  define class Client {
    AbstractFactory factory;
    define void m1(){
      AbstractProductA a = factory.createProductA();
      AbstractProductB b = factory.createProductB();
    }
  }
}
module extension extends original {
  class AbstractFactory {
    define abstract AbstractProductC createProductC();
  }
  class ConcreteFactory1 {
    AbstractProductC createProductC(){...}
  }
  class ConcreteFactory2 {
    AbstractProductC createProductC(){...}
  }

  define abstract class AbstractProductC {...}
  define class ProductC1 extends AbstractProductC {...}
  define class ProductC2 extends AbstractProductC {...}

  class Client {
    define void m2(){
      AbstractProductC c = factory.createProductC();
    }
  }
}

Another solution in MixJuice

Solved Problem(s)

Extensibility problem

In order to add new product, new creation method should be added to the Factory class. (This problem is mentioned at p.90,line.4-9 in the GoF book.)

Type safety problem

The original GoF pattern requires downcast from AbstractProduct to a concrete Product in order to invoke the specific methods of the Product. (This problem is mentioned at p.91,line27-40 in the GoF book.)

Complexity problem

The class structure of the original GoF pattern is complicated. (This problem is not mentioned in the GoF book.)

Used programming technique(s)

Implementation selection for Product classes.

Consequences

• (+) New kinds of product can be added without modifying the source code.
• (+) Downcasts are no longer needed.
• (+) Class structure is not complicated.
• (-) This solution is applicable only if just one implementation of ConcreteFactory is used in a program.

Structure and pseudo code

module products {
  define class ProductA {
    define abstract ProductA();
    ...
  }
  define class ProductB {
    define abstract ProductB();
    ...
  }
}

module products.implementation1 extends products {
  class ProductA {
    ProductA() {...}
    ...
  }
  class ProductB {
    ProductB() {...}
    ...
  }
}

module products.implementation2 extends products {
  class ProductA {
    ProductA() {...}
    ...
  }
  class ProductB {
    ProductB() {...}
    ...
  }
}

module client extends products {
  ... new ProductA() ...
  ... new ProductB() ...
}

Top