DEV Community: Nguyễn Huy Hoàng

Design pattern (part 4): Behavioural pattern I

Nguyễn Huy Hoàng — Sun, 30 Apr 2023 02:35:43 +0000

When I learned about coding principles like SOLID, one principle has always stood out:

Functions should do one thing. They should do it well. They should do it only.

When I think back to the code I wrote in the past, many of them did not pass this principle. And one of the reasons behind it is that the functionalities of the components are being divided inappropriately. Components knew too much and even intervened in the functionalities of other components. Moreover, some functionalities of similar purposes are not grouped together and instead are spread out in many different places.

When resolving these problems, I have created solutions that I can reuse many times. And when I came across behavioral patterns, I realized that I have unintentionally re-invented many of them! People usually say not to reinvent the wheel, but in my opinion, sometimes doing so can result in a deeper understanding of the underlying ideas and thus will be able to apply them better.

Importance of Behavioural Patterns

When learning more about behavior patterns, I can see the quality of my code improve by a huge margin. This is because, as I have described above, these patterns are time-tested and re-invented many times to solve a common problem: lack of clear boundaries in programming.

When components in a system don’t have clear boundaries, components will usually get outside of their scope of responsibilities very quickly. A new feature that requires reading from another component? Just connect directly. Need to copy the state of an object? Reflection on the way (Yes, I did that).

When components intervene in others’ affairs, it can cause a lot of headaches trying to change any of them. You can try to think of it as trying to untangle a bunch of wired earbuds and charging cables. Yeah, good luck with that.

Not only less readable and less maintainable, it also introduces security risks to the system. One component that can read the internal properties of other components can become a hub for malware that will spread to the entire system.

Benefits of using Behavioural Patterns

More functional: Using behavioral patterns can unlock a whole lot of possibilities previously unavailable through traditional means. This is because when an object is not doing what it is supposed to do, it will have many difficulties, or simply be outright impossible to carry out such tasks.
More readable: Code will be easier to read since you know exactly where to look for a particular functionality.
More flexible: Since the responsibilities are divided neatly into components, we can easily change and add functionalities by modifying the individual components without affecting other components
More secure: A component does not have any unnecessary information about other components, thus reducing the risks of an attack spread out on the system

Understanding Behavioural Patterns

1. Chain of responsibility

Imagine you are going to court. You want to sue someone. You start by sueing them in your local court. If the local court cannot handle the case, it will forward the case to the higher court. The higher court will then decide whether to handle the case or forward it to the higher court. This is the chain of responsibility pattern.

The main idea of the chain of responsibility pattern is to decouple the sender of a request from the receiver of the request by allowing more than one object to handle the request. Each object in the chain has a reference to the next object in the chain. The request is passed along the chain until an object handles it.

If you take a closer look, you will realize that the logic can be implemented in a nested if-else. However, the chain of responsibility pattern allows you to change the chain dynamically at runtime. Moreover, you can pass the request to any object in the chain, instead of the first.

Example:

public interface Handler {
    void setNext(Handler handler);
    void handleRequest(Request request);
}
public class ConcreteHandler implements Handler {
    private Handler next;
    public void setNext(Handler handler) {
        next = handler;
    }
    public void handleRequest(Request request) {
        if (shouldForward(request)) {
            next.handleRequest(request);
        } else {
            // handle the request
        }
    }
    // other methods
}
public class Request {
    // logic here
}
public class Main {
    public static void main(String[] args) {
        Handler handler1 = new ConcreteHandler();
        Handler handler2 = new ConcreteHandler();
        handler1.setNext(handler2);
        Request request = new Request();
        handler1.handleRequest(request);
    }
}

2. Command

Imagine you are a manager. One day, you receive a request from your employee via an email. You decided to do the task. However, the next day, you receive another, similar request from your employee via a phone call. You, a bit annoyed, still decided to do the work. The next day, you receive another request from your employee via a text message. This goes on for a few days. You are annoyed by the requests that are very similar to each other but are notified to you in different ways.

Instead, you decided to ask your assistant to handle the requests. Your assistant will receive the requests and send them to you via email. You will then do the work. This is the command pattern.

The main idea of the command pattern is to encapsulate a request as an object. This opens up a lot of possibilities: you can queue the requests, log the requests, undo the requests, etc. Furthermore, it decouples the invoker of the request from the business logic that handles the request.

The implementation of the command pattern has the following parts:

Create the command interface with an execute() method.
Create the invoker class that stores the reference to the command object and call the execute() method.
Create the command classes that implement the command interface. These classes store the reference to the receiver objects and call the appropriate method of the receiver on execute() method call.

Example:

public interface Command {
    void execute();
}
public class ConcreteCommand implements Command {
    private Receiver receiver;
    public ConcreteCommand(Receiver receiver) {
        this.receiver = receiver;
    }
    public void execute() {
        receiver.action();
    }
}
public class Receiver {
    public void action() {
        // logic here
    }
}
public class Invoker {
    private Command command;
    public void setCommand(Command command) {
        this.command = command;
    }
    public void executeCommand() {
        command.execute();
    }
}
public class Main {
    public static void main(String[] args) {
        Receiver receiver = new Receiver();
        Command command = new ConcreteCommand(receiver);
        Invoker invoker = new Invoker();
        invoker.setCommand(command);
        invoker.executeCommand();
    }
}

3. Iterator

Imagine you are visiting your friend's house. You want to see all the rooms in the house. However, you don't know the house is structured. You can try to guess the structure of the house and visit the rooms. If you guess wrong, you will have to go back to the starting point and try again, which is time-consuming and annoying. Instead, you can ask your friend to guide you through the house. Your friend knows the structure of the house and can guide you to visit all the rooms. This is the iterator pattern.

The main idea of the iterator pattern is to provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. The iterator pattern essentially delegates the responsibility of accessing and traversing the elements of an aggregate object to that object itself.

One of the advantages of the iterator pattern is that it decouples the algorithm for accessing and traversing the elements of an aggregate object from its underlying structure. Moreover, you can create different iterators for the same aggregate object, just like your friend can guide you through the house in different ways.

Example:

public interface Iterator {
    boolean hasNext();
    Object next();
}
public class Tree {
    // logic here
    public Iterator createIterator() {
        // choose which iterator to return
    }
}
public class TreeIterator implements Iterator {
    // logic here
}
public class TreeIteratorPreOrder implements Iterator {
    // logic here
}
public class Main{
    public static void main(String[] args) {
        Tree tree = new Tree();
        Iterator iterator = tree.createIterator();
        while (iterator.hasNext()) {
            System.out.println(iterator.next());
        }
    }
}

4. Mediator

Imagine you are in a group chat with your friends. You want to send a message to your friend. You can send the message directly to your friend. However, if you want to send the message to multiple friends, you will have to send the message to each of them. This is time-consuming and annoying. Instead, you can send the message to the group chat. The group chat will send a message to all your friends. This is the mediator pattern.

The main idea of the mediator pattern is to encapsulate the interaction between objects in a separate object and decouple the objects from each other. The objects only need to know the mediator object, instead of knowing each other. The mediator object knows the interaction between the objects and can easily change the interaction without changing the objects.

The mediator pattern promotes the Single Responsibility Principle by keeping the interactions between objects in a distinct object. Moreover, the mediator pattern centralizes the control of the interaction between objects, making it easier to maintain and extend.

The implementation of the mediator pattern has the following parts:

Create the mediator interface and implement it.
When an object wants to interact with other objects, it notifies the mediator object. The mediator then sees which objects are involved in the interaction and executes the interaction.

Example:

public interface Mediator {
    void notify(Component sender, String event);
}
public class ConcreteMediator implements Mediator {
    Button button;
    TextBox textBox;
    public void register(Component component) {
        if (component instanceof Button) {
            button = (Button) component;
        } else if (component instanceof TextBox) {
            textBox = (TextBox) component;
        }
    }
    public void notify(Component sender, String event) {
        if (sender == button && event.equals("click")) {
            // do something
        } else if (sender == textBox && event.equals("click")) {
            // do something
        }
    }
}
public class Component {
    private Mediator mediator;
    public Component(Mediator mediator) {
        this.mediator = mediator;
    }
    public void click() {
        mediator.notify(this, "click");
    }
}
public class Button extends Component {
    public Button(Mediator mediator) {
        super(mediator);
    }
}
public class TextBox extends Component {
    public TextBox(Mediator mediator) {
        super(mediator);
    }
}
public class Main {
    public static void main(String[] args) {
        Mediator mediator = new ConcreteMediator();
        Button button = new Button(mediator);
        TextBox textBox = new TextBox(mediator);
        mediator.register(button);
        mediator.register(textBox);
        button.click();
    }
}

Note that in this example, the concrete mediator knows the concrete components. This is not always the case. The concrete mediator can be decoupled from the concrete components by using the observer pattern.

5. Memento

Imagine you are working for an event organizer. You are organizing a big event. After the event is done, you must reorganize everything on the stage back to its original state. You can try to remember the original state and reorganize everything back to that state. However, this is time-consuming and error-prone. Furthermore, there are many things in the stage that you don't know how to reorganize. Instead, you can pay for the owner of the stage to reorganize everything back to its original state. This is the memento pattern.

The main problem that this pattern solves is the broken responsibilities of the components. The components are trying to invade each other's privacy, and do things that they are not supposed to. The memento pattern solves this problem by delegating the responsibility of restoring the state of an object to the object itself. The object can easily save and restore its state because it knows its state. In fact, this is the only way to restore the state of an object without compromising security and privacy.

So how does the memento pattern work? The memento pattern has the following parts:

The originator is the object that wants to save and restore its state.
The memento is the object that stores the state of the originator. The memento can only be accessed by the originator. This is usually done by making the memento an inner class of the originator.
The caretaker is the object that manages the memento. When the caretaker wants to save the state of the originator, it asks the originator to create a memento. When the caretaker wants to restore the state of the originator, it sends the memento back to the originator. The caretaker does not know what is inside the memento.

Example:

public class Originator {
    private String state;
    public void setState(String state) {
        this.state = state;
    }
    public String getState() {
        return state;
    }
    public Memento createMemento() {
        return new Memento(state);
    }
    public void restoreMemento(Memento memento) {
        state = memento.getState();
    }
    public class Memento {
        private String state;
        public Memento(String state) {
            this.state = state;
        }
        public String getState() {
            return state;
        }
    }
}
public class Caretaker {
    private List<Originator.Memento> mementos = new ArrayList<>();
    private Originator originator;
    public void saveState() {
        memento = originator.createMemento();
        mememtos.add(memento);
    }
    public void restoreState() {
        memento = mementos.getAndRemoveLast();
        originator.restoreMemento(memento);
    }
}
public class Main {
    public static void main(String[] args) {
        Originator originator = new Originator();
        Caretaker caretaker = new Caretaker();
        originator.setState("state 1");
        caretaker.saveState(originator);
        originator.setState("state 2");
        caretaker.restoreState(originator);
        System.out.println(originator.getState());
    }
}

Summary

In this blog post, we have emphasized the significance of behavioral patterns and the advantages they bring to software development. We also cover some of the most commonly used behavioral patterns. In the next part of the series, we will learn more about other patterns. To gain a better understanding of the concept, I suggest trying to explain the patterns in your own words. Additionally, you can experiment with implementing the patterns in your projects.

In this post, we have covered some of the common behavioral patterns and their benefits. However, there are still more patterns to explore. So, stay tuned for the next post where we'll discuss the remaining behavioral patterns. If you have any questions or thoughts, please feel free to leave a comment below. I'll be happy to address them!

Design pattern (part 3): Structural patterns

Nguyễn Huy Hoàng — Sun, 23 Apr 2023 08:59:36 +0000

After the previous post about creational patterns, in this post, we will talk about structural patterns.

Creational design patterns are an essential part of software development. However, they are often overlooked and misunderstood by developers. In this blog post, we will explore why these patterns are crucial and how they can benefit your code.

The Importance of Structural Design Patterns

Many people don't have a clear understanding of what these patterns are or how they can benefit their code.

One reason is that many developers are not taught about these patterns in their education or training. Additionally, some developers may find the patterns too abstract or complicated to understand.

However, if used correctly, these patterns can make a big difference in your code.

What are Structural Design Patterns?

Structural design patterns are design patterns that help you to create a structure for your code. They are used to simplify the design by identifying the relationships between classes and objects.

Think about them like interpreters. They help simplify the relationship between the classes and objects while also making the structure of your code flexible and easy to understand.

Common structural patterns

1. Adapter

The name pretty much says it all. (phew, no metaphors needed!)

The adapter pattern is used to adapt one interface to another. This is useful when you have two incompatible components that you need to work together.

The main idea behind the adapter pattern has two parts:

Create an adapter interface that defines the methods that the client needs to use.
Create a concrete adapter class that implements the adapter interface. This adapter receives the input from the client, "converts" it to the format that the other component needs, and then passes it to the other component.

Note that the client can also use the concrete adapter class directly. However, this is not recommended because it will make the code harder to maintain. Moreover, using the adapter interface will make it easier to change the concrete adapter class in the future.

Example:

public interface XMLToJSONAdapter {
  void processXML(String xml);
}

public class XMLToJSONAdapterImpl implements XMLToJSONAdapter {

    private JSONProcessor jsonProcessor;

    @Override
    public void processXML(String xml) {
        String json = convertXMLToJSON(xml);
        jsonProcessor.processJSON(json);
    }

    private String convertXMLToJSON(String xml) {
        // convert XML to JSON
        return json;
    }
}

public class Client {

    private XMLToJSONAdapter adapter;

    public void processXML(String xml) {
        adapter.processXML(xml);
    }
}

public class Main {
    public static void main(String[] args) {
        JSONProcessor jsonProcessor = new JSONProcessorImpl();
        XMLToJSONAdapter adapter = new XMLToJSONAdapterImpl(jsonProcessor);
        Client client = new Client(adapter);
        client.processXML(xml);
    }
}

2. Bridge

Imagine you have a TV and a remote control.

The remote control can be used to control your TV. However, the remote control is not compatible with other TVs. This means that if you want to use the remote control on another TV, you will need to buy a new remote control.

One day, your friend gave you a universal remote control and told you that it can be used on any TV. You tested it on your TV and it worked perfectly. When you used it on other TVs, you realized that the remote control is also compatible with other TVs, regardless of the brand.

The question is: how can the remote control be able to control other TVs without knowing the internal structure of the TV?

The answer is: by using the bridge pattern.

The main idea behind the bridge pattern is to control the TV using an interface. This way, we will delegate the actions to the TV itself. The remote control only acts as a controller, transmitting the commands from the user to the TV.

The implementation of the bridge pattern has these parts:

Create an interface that defines the methods of the object that will be controlled.
Create a concrete class that implements the interface. This class will execute the commands from the controller.
Create a controller class that contains an instance of the concrete class. This class will receive the commands from the user and pass them to the concrete class. Thus, this controller class acts as a bridge between the user and the concrete class.

Example:

public interface TV {
    void on();
    void off();
    void setChannel(int channel);
}
public class SonyTV implements TV {
    @Override
    public void on() {
        System.out.println("Sony TV is on");
    }

    @Override
    public void off() {
        System.out.println("Sony TV is off");
    }

    @Override
    public void setChannel(int channel) {
        System.out.println("Sony TV channel is set to " + channel);
    }
}
public class RemoteControl {
    private TV tv;

    public RemoteControl(TV tv) {
        this.tv = tv;
    }

    public void on() {
        tv.on();
    }

    public void off() {
        tv.off();
    }

    public void setChannel(int channel) {
        tv.setChannel(channel);
    }
}

public class Main {
    public static void main(String[] args) {
        TV tv = new SonyTV();
        RemoteControl remoteControl = new RemoteControl(tv);
        remoteControl.on();
        remoteControl.setChannel(5);
        remoteControl.off();
    }
}

3. Composite

Imagine you have a box.

The box can contain other boxes. It can also contain other items such as books, pens, and so on.

The question is: how can you calculate the total cost of the box?

The first obvious solution is to unbox the box and calculate the cost of each item. However, this is not a good solution because it will require knowing the internal structure of the box.

The solution? Use the composite pattern.

The main idea behind the composite pattern is to delegate the calculation of the total cost to the box itself. The box will go through all the items in the box and calculate the total cost. If one of the items is a box, it will also go through the items in that box and calculate the total cost, and so on.

The greatest benefit of using the composite pattern is that you don't need to know the internal structure of the box. Moreover, each box can have its implementation of the calculation of the total cost, such as adding a discount, tax or shipping cost.

Example:

public interface Item {
    int getPrice();
}
public class Book implements Item {
    private int price;

    public Book(int price) {
        this.price = price;
    }

    @Override
    public int getPrice() {
        return price;
    }
}
public class Box implements Item {
    private List<Item> items;

    public Box(List<Item> items) {
        this.items = items;
    }

    @Override
    public int getPrice() {
        int total = 0;
        for (Item item : items) {
            total += item.getPrice();
        }
        return total;
    }
}

public class Main {
    public static void main(String[] args) {
        Item book1 = new Book(10);
        Item book2 = new Book(20);
        Item book3 = new Book(30);
        Item box1 = new Box(Arrays.asList(book1, book2));
        Item box2 = new Box(Arrays.asList(book3, box1));
        System.out.println(box2.getPrice()); // 80
    }
}

4. Decorator

This name of the pattern is a little misleading.

One other name for this pattern is the wrapper pattern. Instead of modifying the original class, the decorator pattern creates a wrapper class that contains the original class.

The main idea behind the decorator pattern is to add new functionality to the original class without modifying it. This is useful when you want to add new functionality to the original class without changing the original class.

However, what fascinates me the most about this pattern is that it can be used on top of each other. This means that you can add multiple decorators to the original class, therefore adding a "chain" of functionality to the original class.

Example:

public interface Processor {
    void process(String message);
}
public class Decorator implements Processor {
    private Processor processor;

    public Decorator(Processor processor) {
        this.processor = processor;
    }

    @Override
    public void process(String message) {
        processor.process(message);
    }
}
public class Stage1Decorator implements Decorator {
    @Override
    public void process(String message) {
      super.process(message);
      process1(message);
    }
}
public class Stage2Decorator implements Decorator {
    @Override
    public void process(String message) {
      super.process(message);
      process2(message);
    }
}
public class Main {
    public static void main(String[] args) {
        Processor processor = new Stage1Decorator();
        processor = new Stage2Decorator(processor);
        processor.process("Hello World");
    }
}

5. Facade

Again, the name of the pattern is pretty self-explanatory (finally, something that the programmers named well!).

The facade pattern is used to provide a simplified interface to a complex system. This is useful when you have a complex system that you want to hide the complexity from the client.

I believe that the facade pattern is one of the most used patterns. You may not know it by name, but you have probably used it before. For example, a utility class that contains a bunch of static methods that you used to simplify your code.

Example:

public class Facade {
    public void process() {
        Stage1 stage1 = new Stage1();
        stage1.process();
        Stage2 stage2 = new Stage2();
        stage2.process();
        Stage3 stage3 = new Stage3();
        stage3.process();
    }
}
public class Main {
    public static void main(String[] args) {
        Facade facade = new Facade();
        facade.process();
    }
}

6. Flyweight

Imagine you have a vacuum cleaner.

In your house, you have a lot of surfaces that need to be cleaned. However, each type of surface has a different cleaning method. For example, you have a wooden floor, a carpet, a marble floor, and so on.

The question is: how can you clean all the surfaces in your house using the same vacuum cleaner?

The solution? You use different attachments for the vacuum cleaner. For example, you can use a wide brush for the carpet, a small brush for the wooden floor, and so on.

The main idea behind the flyweight pattern is to extract the common parts of the objects and store them in a separate object. This way, you can use the same object for multiple purposes.

Example:

public class Attachment {
    private String name;

    public Attachment(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}
public class AttachmentFactory {
    private static final Map<String, Attachment> attachments = new HashMap<>();

    public static Attachment getAttachment(String name) {
        Attachment attachment = attachments.get(name);
        if (attachment == null) {
            attachment = new Attachment(name);
            attachments.put(name, attachment);
        }
        return attachment;
    }
}
public class VacuumCleaner {
    private Attachment attachment;

    public void setAttachment(Attachment attachment) {
        this.attachment = attachment;
    }

    public void clean() {
        System.out.println("Cleaning with " + attachment.getName());
    }
}

public class Main {
    public static void main(String[] args) {
        VacuumCleaner vacuumCleaner = new VacuumCleaner();
        vacuumCleaner.setAttachment(AttachmentFactory.getAttachment("brush"));
        vacuumCleaner.clean();
        vacuumCleaner.setAttachment(AttachmentFactory.getAttachment("wide brush"));
        vacuumCleaner.clean();
    }
}

7. Proxy

Those of you who used a VPN before know what the proxy pattern is.

The main idea behind the proxy pattern is to provide a placeholder for another object to control access to it.

You can think of it as having an assistant that does all the work for you. The assistant will control who can reach out to you, and also handle all the requests that you receive.

The proxy pattern has many uses:

It can be used to provide a placeholder for a remote object.
It can be used to hide the complexity of the original object.
It can be used to add new functionality to the original object.
It can be used to control access to the original object.

The implementation of the proxy pattern is very similar to the implementation of the facade pattern, with several parts:

The interface defines the functionality of the original object.
Both the original object and the proxy object implement the interface.
The proxy object contains a reference to the original object.
When the client calls a method on the proxy object, the proxy object calls the same method on the original object, with additional functionality.

Example:

public interface Image {
    void display();
}
public class RealImage implements Image {
    private String filename;

    public RealImage(String filename) {
        this.filename = filename;
        loadFromDisk(filename);
    }

    private void loadFromDisk(String filename) {
        System.out.println("Loading " + filename);
    }

    @Override
    public void display() {
        System.out.println("Displaying " + filename);
    }
}
public class ProxyImage implements Image {
    private RealImage realImage;
    private String filename;

    public ProxyImage(String filename) {
        this.filename = filename;
    }

    @Override
    public void display() {
        if (realImage == null) {
            realImage = new RealImage(filename);
        }
        realImage.display();
    }
}
public class Main {
    public static void main(String[] args) {
        Image image = new ProxyImage("test_10mb.jpg");
        image.display();
        System.out.println("");
        image.display();
    }
}

That is all for this post. I hope you enjoyed it, and I hope that you learned something new.

A good way in my opinion to learn more about design patterns is to try to explain them in your own words. This way, you will be able to understand the idea behind the pattern, and you will be able to use it in your projects.

Remember that this is only a brief introduction to the design patterns. The details of each pattern are much more complex, and you should read more about them if you want to use them in your projects. I will also write more posts about design patterns in the future.

Resources

Design pattern (part 2): Creational patterns

Nguyễn Huy Hoàng — Sun, 16 Apr 2023 05:46:04 +0000

I. What is a creational pattern again?

Creational patterns are design patterns that deal with object creation mechanisms. The main idea of these patterns is to control the object-creation process in a way that it is more flexible and efficient.

The reason behind the pattern is that basic forms of object creation could result in design problems or add complexity to the design. Creational design patterns solve this problem by controlling this object creation process.

II. What are the most common creational patterns?

1. Singleton

- Intent

Think of a printer.

If multiple printers are used simultaneously, managing them can be a nightmare. You can't be sure that the right printer is used for the right job.

Moreover, if you want to change the configuration of the printer, you have to change it for all printers.

- Motivation

The singleton pattern is a creational design pattern that ensures that only one object of its kind exists and provides a single point of access to it for any other code.

In our metaphor, it ensures that only one printer is used for all printing activities. You always know what is the configuration of the printer, so no more confusion.

- Structure

The main idea behind the singleton pattern has two parts:

Hide the constructor of the class so that no other code can instantiate it.
Use that constructor to instantiate a single instance of the class, and provide a global point of access to it.

- Example

public class Printer {
    private static Printer instance = null;
    private Printer() {}
    public static Printer getInstance() {
        // If no instance exists, create one
        if (instance == null) {
            instance = new Printer();
        }
        // if an instance already exists, return it
        return instance;
    }
}

2. Factory

- Intent

Imagine you work at a transportation company.

Say you have to deliver a top-secret package to a client.

You have to make sure that the package is delivered safely, and that the client is the only one who can open it. Even you, who is delivering the package, are not allowed to know what is inside.

- Motivation

The main idea behind the factory pattern is to create objects without exposing the instantiation logic to the client and refer to newly created objects using a common interface.

In our metaphor, we defer the creation of the package to a factory, and we only know that the general form of the package is a box, so we can't know what is inside.

Not only does this pattern allow us to have zero knowledge of the package, but it also allows us to deliver other types of packages, as long as they are wrapped in a box.

- Structure

The main idea behind the factory pattern has two parts:

Create an interface for creating an object, but let subclasses decide which class to instantiate.
The caller of the factory method only refers to the factory through the interface, so it doesn't know which class is instantiated.

- Example

public interface Box {
    public void open();
    public void transport();
}
public class SecretBox implements Box {
    public void open() {
        System.out.println("The box is opened");
    }
    public void transport() {
        System.out.println("The box is transported");
    }
}
public interface BoxFactory {
    public Box createBox();
}
public class SecretBoxFactory implements BoxFactory {
    public Box createBox() {
        return new SecretBox();
    }
}
public class Client {
    public void transport(BoxFactory factory) {
        Box box = factory.createBox();
        box.transport();
    }
}
public class Main {
    public static void main(String[] args) {
        Client client = new Client();
        client.transport(new SecretBoxFactory());
    }
}

3. Abstract Factory

- Intent

Imagine you work at a furniture company. (I know, I know, you're tired of the metaphor)

You learned about factories, and you created factories that create tables and chairs and deliver them to clients.

Then, a day later, a client called to complain that the tables and chairs he bought from you don't match.

You realize that you have used factories of different styles to create the tables and chairs, and that's why they don't match.

So what now?

- Motivation

The main idea behind the abstract factory pattern is pretty much the same as the factory pattern, but it extends to creating related objects. Essentially, it is a combination of the factories of multiple objects into a single factory.

In our metaphor, we have a factory interface that creates tables and chairs, and we want to create a factory that creates tables and chairs of different styles. When we call the factory, we can always be certain that the table and the chair are of the same style, without having to know which style it is.

- Structure

The main idea behind the abstract factory pattern has three parts:

Each concrete class of a family has to implement a family of interfaces.
Create a factory interface for creating that family of interfaces without specifying their concrete classes and defer the creation of the concrete class to subclasses.
The caller of the abstract factory method only refer to the factory through the interface, so it doesn't know which style is instantiated. However, it knows that the table and the chair are of the same style.

- Example

public interface Table {
    public void create();
}
public interface Chair {
    public void create();
}
public class ModernTable implements Table {
    public void create() {
        System.out.println("A modern table is created");
    }
}
public class ModernChair implements Chair {
    public void create() {
        System.out.println("A modern chair is created");
    }
}
public class VictorianTable implements Table {
    public void create() {
        System.out.println("A victorian table is created");
    }
}
public class VictorianChair implements Chair {
    public void create() {
        System.out.println("A victorian chair is created");
    }
}
public interface FurnitureFactory {
    public Table createTable();
    public Chair createChair();
}
public class ModernFurnitureFactory implements FurnitureFactory {
    public Table createTable() {
        return new ModernTable();
    }
    public Chair createChair() {
        return new ModernChair();
    }
}
public class VictorianFurnitureFactory implements FurnitureFactory {
    public Table createTable() {
        return new VictorianTable();
    }
    public Chair createChair() {
        return new VictorianChair();
    }
}
public class Client {
    public void createFurniture(FurnitureFactory factory) {
        Table table = factory.createTable();
        Chair chair = factory.createChair();
        table.create();
        chair.create();
    }
}
public class Main {
    public static void main(String[] args) {
        Client client = new Client();
        client.createFurniture(new ModernFurnitureFactory());
        client.createFurniture(new VictorianFurnitureFactory());
    }
}

4. Builder

- Intent

Again, imagine you work at a construction company. (Oh well, here we go again)

For a house, you know that it has to be built in a certain order: the foundation, the walls, the roof, and so on.

However, for each step, you can use different materials, different styles, and so on. You don't know what the client wants, so you have to give the client the freedom to choose what materials and styles to use.

- Motivation

The main idea behind the builder pattern is to delegate the construction of a complex object to other objects called builders.

In our metaphor, we have a construction company that builds houses. The company has a builder interface that defines the steps of building a house.

The company has a director that uses the builders that implement the interface to build a house. The director doesn't know the details of how builders build the house, but he knows that the house is built in a certain order.

Note that in the pattern, the client can use the director to build a house, and the client can also use the builder interface directly to build a house itself.

- Structure

The main idea behind the builder pattern has three parts:

Create a builder interface that defines the steps of building a complex object.
For each step, create a concrete builder that implements the builder interface and builds the step.
Create a director that uses the builder interface to build a complex object. The director doesn't know the concrete classes of the builders, but he knows the order of the steps.

- Example

public interface HouseBuilder {
    public void buildFoundation();
    public void buildWalls();
    public void buildRoof();
    public House getHouse();
}
public class ModernHouseBuilder implements HouseBuilder {
    private House house;
    public ModernHouseBuilder() {
        house = new House();
    }
    public void buildFoundation() {
        house.setFoundation("Modern foundation");
    }
    public void buildWalls() {
        house.setWalls("Modern walls");
    }
    public void buildRoof() {
        house.setRoof("Modern roof");
    }
    public House getHouse() {
        return house;
    }
}
public class VictorianHouseBuilder implements HouseBuilder {
    private House house;
    public VictorianHouseBuilder() {
        house = new House();
    }
    public void buildFoundation() {
        house.setFoundation("Victorian foundation");
    }
    public void buildWalls() {
        house.setWalls("Victorian walls");
    }
    public void buildRoof() {
        house.setRoof("Victorian roof");
    }
    public House getHouse() {
        return house;
    }
}
public class House {
    private String foundation;
    private String walls;
    private String roof;
    public void setFoundation(String foundation) {
        this.foundation = foundation;
    }
    public void setWalls(String walls) {
        this.walls = walls;
    }
    public void setRoof(String roof) {
        this.roof = roof;
    }
    public String getFoundation() {
        return foundation;
    }
    public String getWalls() {
        return walls;
    }
    public String getRoof() {
        return roof;
    }
}
public class Director {
    public void buildHouse(HouseBuilder builder) {
        builder.buildFoundation();
        builder.buildWalls();
        builder.buildRoof();
    }
}
public class Client {
    public void buildHouse(HouseBuilder builder) {
        Director director = new Director();
        director.buildHouse(builder);
        House house = builder.getHouse();
        System.out.println(house.getFoundation());
        System.out.println(house.getWalls());
        System.out.println(house.getRoof());
    }
}
public class Main {
    public static void main(String[] args) {
        Client client = new Client();
        client.buildHouse(new ModernHouseBuilder());
        client.buildHouse(new VictorianHouseBuilder());
    }
}

5. Prototype

- Intent

Imagine you are working on a Microsoft Docs file (Better now). You have a document with a lot of text, and you want to create a copy of the document.

You can copy the text, but then you will lose other information such as the formatting of the text, the metadata, and so on.

You can go through the document and copy each piece of information, but that will take a lot of time. Also, sometimes you only know the general structure of the document, but you don't know the details of the document.

- Motivation

The prototype pattern is used when you want to create a copy of an object, but you don't know the details of the object.

It delegates the creation of the copy to the object itself. The object that you want to copy is called the prototype.

Thus, you can copy all the information of the object, including the internal, private information. Moreover, by creating a common interface for all the objects, you can copy objects without knowing their concrete classes.

- Structure

The main idea behind the prototype pattern has three parts:

Create a prototype interface that defines the clone method.
Create concrete prototypes that implement the clone method. The clone method creates a copy of the object.
Create a client that uses the clone method to create a copy of an object.

- Example

public interface Document extends Cloneable {
    public Document clone();
}
public class WordDocument implements Document {
    private String text;
    public WordDocument(String text) {
        this.text = text;
    }
    public Document clone() {
        return new WordDocument(text);
    }
    public String getText() {
        return text;
    }
}
public class Client {
    public void createDocument(Document document) {
        Document documentCopy = document.clone();
        System.out.println(documentCopy.getText());
    }
}
public class Main {
    public static void main(String[] args) {
        Client client = new Client();
        client.createDocument(new WordDocument("Hello world"));
    }
}

III. Summary

In this article, we learned about the creational design pattern type, and we learned about the main patterns of the type:

Singleton
Factory
Abstract factory
Builder
Prototype

That's all for this week's article. I hope you enjoyed it. If you have any questions, feel free to ask them in the comments.

Design pattern (part 1): Wait, pattern ?

Nguyễn Huy Hoàng — Sun, 09 Apr 2023 04:11:38 +0000

A pattern in design ? What are you talking about ?

Hey, let me tell you a little secret. As a beginner, one of the best ways to enhance your skills as a software engineer is to learn design patterns. They can make your code more flexible, maintainable, and easier to change or fix.

With the "why" out of the way, let's jump to the "how"!

What exactly does a design pattern do ?

Think of a spoon.

Is it the best tool you can use to stir your coffee ? Yes.

Are there only one way to stir your coffee using the spoon ? No.

Design patterns are the same.

They are a proven way to solve a particular problem.

They have a certain idea behind them to solve that particular problem, but the idea can be applied in many different ways.

Okay, but what does it look like ?

The descriptions of these patterns are usually formalized to enable their application in various contexts. They are usually described in the following way:

Intent: What is the problem that the pattern is trying to solve ? What is the general idea behind the pattern ?
Motivation: Explain the problem in more detail, and why the pattern is a good solution.
Structure: Describe the structure of the pattern, and how it is implemented.
Example: Provide a code example of the pattern in action.

What are the most common design patterns types ?

Most common design patterns are divided into three categories:

Creational patterns: The idea behind these patterns is to create objects in a controlled way so that the characteristics of the objects are suitable for the problem at hand.
Structural patterns: The idea behind these patterns is to make it easier to design systems by identifying a simple way to realize relationships between entities.
Behavioral patterns: The idea behind these patterns is to make the communication between objects more flexible and efficient.

In this post, we have discussed about design pattern definition, roles and types. We will dive deeper in the most common patterns in the next posts. Stay tuned!