Category: Design Patterns

Abstract Factory Pattern

February 4th, 2023
In the last two posts on Factory Pattern using Factory method – part 1 and part 2, we went through how factory method works, using the toyota car factory example. Let’s continue to build on that example and understand the Abstract Factory Pattern.

Using the factory method, we implemented our interfaces CarFactory and ToyotaCar and their concrete implementations for Toyota. But the toyota leaders found out that their factories in California and Washington are not using the genuine toyota parts while assembling Toyota cars, thereby degrading quality of the cars. And so toyota has decided to create a factory for genuine toyota parts that produces these parts and sends them to the car factories.

Let’s call the parts factory ToyotaPartsFactory. CaliforniaToyotaPartsFactory and WashingtonToyotaPartsFactory will now supply these parts to the CaliforniaToyotaCarFactory and WashingtonToyotaCarFactory respectively
```
public interface ToyotaPartsFactory {

       public Engine createEngine();
       public Wheels wheels();
       public Seats seats();
}
```
Abstract Factory Pattern using Toyota Parts Factory example
```
public class CaliforniaToyotaPartsFactory implements ToyotaPartsFactory {
 
      public Engine createEngine() {
            return V8Engine();
      }

      public Wheels createWheels() {
            return AlloyWheels();
      }

      public Seats createSeats() {
             return LeatherSeats()l
      }
}
```
Our new ToyotaCar object would now have an abstract method called assembleParts. This would be implemented by the subclasses to use the correct parts while assembling the car. In our concrete CarFactories, we will now be passing the respective ToyotaPartFactories. As shown below, in the CaliforniaToyotaPartsFactory we are passing the CaliforniaToyotaPartsFactory.
```
public abstract class ToyotaCar {
       String modelName;
       Engine engine;
       Wheels wheels;
       Seats seats;

       abstract void assembleParts();

       void polish() {
            System.out.println("Polishing "+modelName+" car";
       }
}

public class Sienna extends ToyotaCar {
        ToyotaPartsFactory toyotaPartsFactory;

        public Sienna(ToyotaPartsFactory toyotaPartsFactory) {
             this.toyotaPartsFactory = toyotaPartsFactory;
         }

         void assembleParts() {
              System.out.println("Assembling "+modelName+" car";
              engine = toyotaPartsFactory.createEngine();
              wheels = toyotaPartsFactory.createWheels();
              seats = toyotaPartsFactory.createSeats();
         }
}

public class CaliforniaToyotaCarFactory extends CarFactory {
        ToyotaCar createCar(String model) {
               ToyotaCar car = null
        ToyotaPartsFactory toyotaPartsFactory = new CaliforniaToyotaPartsFactory();
        if(model.equals("sienna") {
            return new Sienna(toyotaPartsFactory);
        } else if(model.equals("highlander") {
            return new HighLander(toyotaPartsFactory);
        } else if(model.equals("prius") {
            return new Prius(toyotaPartsFactory);
        else {
            return null;
        }
     }
}
```
We now have the power to create a family of different part objects. That’s what an Abstract Factory does. It gives an interface for creating a factory of products. The second advantage is decoupling. Our code for creating products (ToyotaCar) is decoupled from the code for creating the other line of product families. It opens up the architecture for creating different types of factories needed, with each decoupled from others.

Abstract Factory Pattern

Thanks for stopping by! Hope this gives you a perspective on Abstract Factory pattern. Post comments to start a discussion. See you in the next post.

Factory Pattern using Factory Method – Part 2

January 28th, 2023

Continuing on the example of ToyotaCarFactory from our last post Factory Pattern – Part 1, the main aim of the ToyotaCarFactory is to fulfill an order for a ToyotaCar. There are multiple models of Toyota and the factory should manufacture them all.

Our Creator is the CarFactory, having the createCar() factory method which would hold the object instantiation part. ToyotaCarFactory is our concrete creator class which would be responsible for creating the different ToyotaCar objects by providing an implementation of createCar() method.

As we can see below in the CarFactory code, createCar is our factory method, it is abstract and so will get implemented in subclasses.

public abstract class CarFactory {

     public ToyotaCar orderCar(String model) {
            
            ToyotaCar car;
            car = createCar(model);
            car.assembleParts();
            car.polish();

            return car;
      }
      protected abstract ToyotaCar createCar(String model);
}

CaliforniaToyotaCarFactory and WashingtonToyotaCarFactory are our two factories in California and Washington respectively. CaliforniaToyotaCarFactory produces ToyotaCar objects of type Sienna, Highlander and Prius. WashingtonToyotaCarFactory produces ToyotaCar objects of type Sienna, Highlander, Tacoma. Now if Toyota decides to open another factory in Texas, they will just need to implement TexasToyotaCarFactory and have the concrete objects of the models that that factory will produce. See, how easy it is to add new factories without modifying the already written code.

public class CaliforniaToyotaCarFactory extends CarFactory {
     ToyotaCar createCar(String model) {
        if(model.equals("sienna") {
            return new Sienna();
        } else if(model.equals("highlander") {
            return new HighLander();
        } else if(model.equals("prius") {
            return new Prius();
        else {
            return null;
        }
    } 
}

public class WashingtonToyotaCarFactory extends CarFactory {
     ToyotaCar createCar(String model) {
        if(model.equals("sienna") {
            return new Sienna();
        } else if(model.equals("highlander") {
            return new HighLander();
        } else if(model.equals("tacoma") {
            return new Tacoma();
        else {
            return null;
        }
    } 
}

As we can see, the concrete classes which extend out CarFactory interface are actually creating new ToyotaCar objects, ie, subclasses are deciding which objects to initialize.

Let’s see how our ToyotaCar and it’s subclasses would look like.

public abstract class ToyotaCar {
       String modelName;
       String engine;
       String wheels;
       String seats;

       void assembleParts() {
            System.out.println("Assembling "+modelName+" car";
       }

       void polish() {
            System.out.println("Polishing "+modelName+" car";
       }
}

public class Sienna extends ToyotaCar {
        
       public Sienna() {
           modelName = "Sienna";
           engine = "XXX";
           wheels = "four";
           seats = "leather";
      }
}

public class Highlander extends ToyotaCar {
        
       public Highlander() {
           modelName = "Highlander";
           engine = "XXX";
           wheels = "four";
           seats = "leather";
      }
}

Let’s group them all together. To order a Sienna from Califonia factory of Toyota, we will need to initialize the CaliforniaToyotaCarFactory and then call the orderCar method on it with “sienna” as parameter. This would in turn call the createCar implementation of CaliforniaToyotaCarFactory, which will initialize the Sienna object.

public class ToyotaTestDrive {

public static void main(String[] args) {
      CarFactory calToyotaCarFactory = new CaliforniaToyotaCarFactory();
      CarFactory washToyotaCarFactory = new WashingtonToyotaCarFactory();

      ToyotaCar car = calToyotaCarFactory.orderCar("sienna");
System.out.println("Ordered Car "+car.getName());

      ToyotaCar car = washToyotaCarFactory.orderCar("tacoma");
System.out.println("Ordered Car "+car.getName());

In next post we will see, how Abstract Factory Pattern work.

Factory Pattern using Factory Method- Part 1

January 22nd, 2023
Why the need for factory pattern?

Let’s take example of a ToyotaCarFactory, the main aim of the ToyotaCarFactory is to fulfill an order for a ToyotaCar. There are multiple models of Toyota and the factory should manufacture them all.

The orderCar method would look something like this –
```
ToyotaCar orderCar(String model)
{
    ToyotaCar car;

    if(model.equals("sienna") {
       car = new SiennaToyotaCar();
    } else if(model.equals("highlander") {
       car = new HighLanderToyotaCar();
    } else if(model.equals("prius") {
       car = new PriusToyotaCar();
    } 

    car.assembleParts();
    car.polish();
    car.testDrive();
}
```
If Toyota decided to launch three other methods, the object instantiation part would keep on increasing. And we would need to change it, make sure nothing breaks, add the code to correct part. Our code is not closed for modification, as every time new type of toyota car is added, we have to open this and modify it.

If instead we would have implemented against a CarFactory interface, then we would have given the responsibility of instantiating the required objects to the subclasses. And say other car manufacturers want to use the same CarFactory, we could easily add new concrete subclasses without causing changes to existing ones.

That’s the advantage of coding to interfaces as opposed to coding to concrete implementation. Your code is following the principle of “Open for extension, closed for modification”.

Factory Pattern

Creator is the interface which has the factory method. But the subclasses which implement the factory method actually create the Product objects.

Example

Let’s use an example to better understand this pattern.

Example of Factory Pattern using Toyota Car manufacturing

Continuing on our Car manufacturing example, our Creator is the CarFactory, having the createCar() factory method which would hold the object instantiation part. ToyotaCarFactory is our concrete creator class which would be responsible for creating the different ToyotaCar objects by providing an implementation of createCar() method.

We will see a sample implementation in the following post.
Decorator Pattern

January 15th, 2023
What is Decorator Pattern?

Decorator pattern attaches additional responsibilities to an object dynamically (at runtime). It provides flexible alternative to subclassing for extending functionality.

It involves a set of Decorator classes that are used to wrap concrete components. Decorator classes mirror the object they wrap and change the behavior of concrete components by adding new functionalities.

Let’s use an example to understand this pattern –

We have our Pizza delivery service, we offer basic pizza with different types of bases and varieties of toppings like veggies, protein, extra cheese etc. Each different topping has it’s own price which adds up to the final cost.

Say we implement this using inheritance, we would have our main object Pizza with some functionality and then we will have separate classes for different pizza on the menu, example one for cheese pizza, veggie delight pizza, etc.

Pizza object

The main drawbacks here would be that
1. if any other topping is added, we will have to go an update Pizza’s cost method,
2. Add it as variable with it’s accessors to the Pizza class
3. If cost of any topping changes/discounts come, we would have to go and change it in Pizza class.
4. All the different pizza types would not need all the toppings, example cheese pizza would not need veggies/protein, etc.
Let’s see how we can have an extensible solution using Decorator pattern –

We will have our main Pizza object and our Toppings decorator object. CheesePizza is our Concrete component example. We have our ToppingsDecorator which is extended by different toppings that we add. We can see the following advantages –
1. if you want to add a discount on the pizza, you can just create another decorator Discount on the pizza object.
2. If prize of any topping changes, we just need to go to that concrete decorator and update the cost.
Pizza object using Decorator Pattern

Open-Closed Design Principle and Decorator Pattern

Open-Closed principle states that classes should be open for extension and closed for modification. If we find that our existing code needs new logic, example new behavior like adding discount, decorator pattern allows us to add that without modifying the existing object.

Drawbacks
- It could result in lot of small decorator objects, increasing number of objects and complexity
Real World Examples
- Java I/O package classes
- Java Streams API

Observer Pattern

January 8th, 2023

Observer pattern is one of the behavioral design patterns used in object oriented world of programming.

Definition – Observer pattern defines a one-to-many relationship between objects. When state of one object changes, all the dependent objects are notified and updated.

There is a Subject interface and a ConcreteSubject that implements the Subject interface. There is an Observer interface and multiple observers implementing that interface. Observers use the Subject interface to register and unregister and also to get notified about the changes. Observer interface generally has one function that is called by the Subject whenever there is a state change.

One way to visualize this is the newspaper subscription in the real world. As soon as a newspaper is published, all the subscribers get the new copy.

In java, common example of observer pattern are Observer interface, EventListeners in awt and swing, Observable, JMS etc.

Best to use an example to understand this pattern.

Usecase – Let’s say there is a pantry containing items. And there are different shopping lists based on different stores we visit. As soon as any item in pantry finishes we want to add that item to all the shopping lists.

Visualizing Observer Pattern for Shopping list

Pantry is our subject. KitchenPantry is concrete subject implementing the Pantry interface. SuperStoreList is our observer interface. CostcoList and WalmartList are our observer. Both observers can register using the attach method and deregister using the detach method. As soon as the item is removed from KitchenPantry, it will be added both the observer’s lists using the update method. KitchenPantry will use notify to call that update method.

public interface Pantry
{

      public void attach(SuperStoreList list);
      public void detach(SuperStoreList list);
      public void notify();
}

public interface SuperStoreList 
{
      public void update(String item);
}

public class KitchenPantry implements Pantry
{
      private List<SuperStoreList> superStores;
      private String item;

      public KitchenPantry()
      {
             superStores = new ArrayList<SuperStoreList>();
      }
      
      public void attach(SuperStoreList list)
      {
              superStores.add(list);
      }

      public void attach(SuperStoreList list)
      {
              superStores.remove(list);
      }

      public void notify(String item)
      {
              for(SuperStoreList list: superStores)
              {
                    list.update(item);
              }
      }

      public void setItem(String item)
      {
              this.item = item;
              itemAdded();
      }

      public void itemAdded()
      {
              notify(item);
      }


      public String getItem()
      {
              return this.item;
      }

}

public class CostcoList implements SuperStoreList
{

      private List<String> costcoList;
      private KitchenPantry kitchenPantry;

      CostcoList(KitchenPantry kitchenPantry)
      {
           costcoList = new ArrayList<String>();
           this.kitchenPantry = kitchenPantry;
           kitchenPantry.attach(this);
      }

      public void update(String item)
      {
           costcoList.add(item)
      }

      public void display()
      {
          System.out.println("Costco list : ");
          for(String item : costcoList)
          {
               System.out.println(item);
          }
      }
}

public class WalmartList implements SuperStoreList
{

      private List<String> walmartList;
      private KitchenPantry kitchenPantry;

      CostcoList(KitchenPantry kitchenPantry)
      {
           walmartList = new ArrayList<String>();
           this.kitchenPantry = kitchenPantry;
           kitchenPantry.attach(this);
      }

      public void update(String item)
      {
           walmartList.add(item)
      }

      public void display()
      {
          System.out.println("Walmart list : ");
          for(String item : walmartList)
          {
               System.out.println(item);
          }
      }
}

public class App
{
       public static void main(String[] args)
       {
             KitchenPantry kitchenPantry = new KitchenPantry();
             CostcoList costcoList = new CostcoList(kitchenPantry);
             WalmartList walmartList = new WalmartList(kitchenPantry);

             kitchenPantry.setItem("milk");

             costcoList.display();
             walmart.display();
}

Hope this helps. Thanks for stopping by.

Category: Design Patterns

Abstract Factory Pattern

Factory Pattern using Factory Method – Part 2

Factory Pattern using Factory Method- Part 1

Why the need for factory pattern?

Example

Decorator Pattern

What is Decorator Pattern?

Open-Closed Design Principle and Decorator Pattern

Drawbacks

Real World Examples

Observer Pattern