The Abstract Factory Pattern

“Abstract Factory” sounds barbarian… and I have seen a few variants. It was sometimes confusing and unclear.

The Abstract Factory pattern implements the dependency of injection principle for polymorphic objects. It reverses the responsibility to create objects from the object itself to another one called Factory. For example, we want to create a list of objects representing a mathematical operation.

// parent class
class Operation {
   public double operate(double x, double y);

A class can chain operations to sum up the results of each operation:

class Operator {
  public double perform(List<Operation> ops, double x, double y) {
    double res = 0;
    for (Operation op : ops) { // new style
       res += ops.operate(x, y)


Now we can have many different operations:

class Sum extends Operation {
   public double operate(double x, double y) {
     return x + y;

class Minus extends Operation {
   public double operate(double x, double y) {
     return x - y;

class Multiply extends Operation {
   public double operate(double x, double y) {
     return x * y;

class Divide extends Operation {
   public double operate(double x, double y) {
     return x / y;

These operations can be constructed following the abstract factory pattern. It is called “abstract” because it relies on at least an abstract parent that is implemented by concrete factories depending on what is needed to be created.

interface OperationFactory {
  Operation createOperation();

class SumFactory implements OperationFactory {
  Operation createOperation() {
     return new Sum();

class MinusFactory implements OperationFactory {


// we need something (constructor, provider class, or inner builder class, etc.) to construct the factories
class FactoryProvider {
  public OperationFactory getFactory(String type) {
    switch (type)
       case "sum" :
          return new SumFactory();
       case "minus" :
          return new MinusFactory();

The abstract factory pattern matches the factory polymorphism with the classes’ polymorphism.

It is obviously unnecessary in this case, but it would make more sense if we want to accomplish something more complex, such as creating different Operators with different Operations. Operator could perform operations by sub-operators. In that case, we may have something like:

interface OperatorFactory {

   Operator buildOperator();
   Operation buildOperation();
   Operator buildInterOperationOperator(); // operator performing an operation between different operations (other than simple sum as done previously), etc.
   Operation buildInterOperation();


class DistanceCalculatorFactory implements OperatorFactory...
class PowerFactory implements OperatorFactory...
class AbsoluteFactory implements OperatorFactory...

Author: Toujon Lyfoung

This paragraph is supposed to be the place where I put my credentials and achievements. In my opinion, degrees and jobs do not tell much about a person. If you want to know me, read my posts! Blogging has been fun. I do not pretend to do much. I am simply processing, tracking and sharing my reflection. Comments are definitely welcomed to help me continue in my learning.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s