DEV Community: Sota

Understanding Java Enums by Rebuilding One

Sota — Sun, 18 Jan 2026 15:53:14 +0000

Enum is just a class

Have you ever noticed that you can define an enum-like class without using the enum keyword, just like a normal class you write in everyday development?

If not, this article is worth a look!

What is an Enum?

An enum is a type that defines a fixed set of predefined, type-safe constants, optionally with behavior.

Enums were introduced in Java 5. Before that, developers implemented enum-like classes manually.

Let’s travel back to that time to better understand how enums actually work under the hood.

Code example

Basic enum

enum Fruit {
    APPLE,
    BANANA;
}

Let’s start with a simple example. This defines a type Fruit with exactly two allowed instances: APPLE and BANANA.

Although Java provides the enum keyword, the core idea behind an enum is not magical.
It can be expressed using a regular class with a few strict rules.

public final class Fruit {
    public static final Fruit APPLE = new Fruit();
    public static final Fruit BANANA = new Fruit();

    private Fruit() {};
}

APPLE and BANANA are both instances of the Fruit class. Each of them is a singleton, meaning there is exactly one instance per constant. In other words, only one APPLE object and one BANANA object ever exist in the JVM.
Because these instances are created as public static final fields and the constructor is private, no additional instances can be created.

Adding a property

Let's add a property.

public enum Fruit {
    APPLE(200),
    BANANA(150);

    private int price;

    private Fruit(int price) {
        this.price = price;
    }
}

The equivalent code without the enum keyword is shown below.
Now we have a price property, and the constructor receives a value and assigns it to that property.

public final class Fruit {
    public static final Fruit APPLE = new Fruit(200);
    public static final Fruit BANANA = new Fruit(150);

    private int price;

    private Fruit(int price) {
        this.price = price;
    };
}

Adding a method

Finally, let's add a method that returns the price with tax included.

public enum Fruit {
    APPLE(200),
    BANANA(150);

    private int price;

    private Fruit(int price) {
        this.price = price;
    }

    public double addTax() {
        return price + (price * 0.1); // add 10% taxes
    }
}

The equivalent implementation using a regular class:

public final class Fruit {
    public static final Fruit APPLE = new Fruit(200);
    public static final Fruit BANANA = new Fruit(150);

    private int price;

    private Fruit(int price) {
        this.price = price;
    };

    public double addTax() {
        return price + (price * 0.1);
    }
}

Conclusion

This demonstrates that an enum is fundamentally the same as a regular class, expressed using different syntax and enforced by the language. Each enum constant is a singleton instance, and the enum keyword exists to guarantee this pattern safely and conveniently.

Interface vs Abstract class

Sota — Sun, 18 Jan 2026 05:24:50 +0000

Interface or Abstract Class?

They are very similar, and therefore it can be confusing to know when to use each one. I’m going to answer this question in this article.

Short answer

Use an interface when…

there is no default behavior
you want to force subclasses (implementations) to implement the behavior

Use an abstract class when…

you want to define default behavior
you want to control the process flow, while the individual steps of the process are implemented by subclasses

Code Example

Interface

public interface IAnimal {
    void bark();
}

public class Dog implements IAnimal {
    @Override
    public void bark() {
        System.out.println("woof!");
    }
}

public static void main(String[] args) {
    IAnimal dog = new Dog();
    dog.bark(); // "woof!"
}

Because barking sounds depend on the animal, IAnimal does not provide a default behavior. Subclasses have no choice but to override the bark method, since failing to do so causes a compile-time error.

Abstract Class

public abstract class Animal {
    // The method is final to prevent subclasses from changing the order in which methods are called
    public final void bark() {
        takeBreath();
        makeSounds();
    }

    // private method as implementation is common for all the animals
    private void takeBreath() {
        System.out.println("taking a deep breath...");
    }

    // protected so that subclasses can override while client (main method) cannot call this method directly
    // abstract method to force subclasses to implements this method
    protected abstract void makeSounds();
}

public class Cat extends Animal {
    @Override
    public void makeSounds() {
        System.out.println("meow!");
    }
}

public static void main(String[] args) {
    Animal car = new Cat();
    cat.bark(); // "meow!"
}

I want to control the makeSounds process so that all animals take a breath first and then bark, this flow should remain constant. However, as in the previous example, barking sounds depend on the animal, so the bark method should be overridden by subclasses.

How to call third-party API in Spring Boot

Sota — Thu, 23 Jan 2025 13:20:29 +0000

Overview

I will introduce how to call third-party API in Spring Boot project. We'll send GET request to this resource https://sampleapis.com/api-list/coffee, then display response data in view (browser).

Prerequisites

You need these knowledge at basic level:

Java
Spring Boot
Thymeleaf

Development process

Create Project

Go to https://start.spring.io/ and generate a project with these dependencies:

Unzip the file and open the project in your code editor. I use Intellij community edition.

Create Controller

import com.myproject.apidemo.Coffee;

import org.springframework.core.ParameterizedTypeReference;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.*;
import org.springframework.web.reactive.function.client.WebClient;

@Controller
public class CoffeeController {

    @GetMapping("/coffee")
    public String coffee(Model model) {
        String url = "https://api.sampleapis.com/coffee/hot";

        WebClient.Builder builder = WebClient.builder();

        String coffeeList = builder.build()
                .get()
                .uri(url)
                .retrieve()
                .bodyToMono(String.class)
                .block();

        System.out.println("---------------------");
        System.out.println(coffeeList);

        model.addAttribute("coffeeList", coffeeList);

        return "coffee";
    }
}

If you can't import some of them, then one possible problem is Maven doesn't load your pom.xml file correctly. Reloading the project resolves this issue in my case.

You can directly type url in your browser and check the response data, it is a list of coffee in JSON format.

You can map response data to Java object if you want. For this, you need to create Coffee class and define fields that you want to hold as Coffee object. For me, Coffee class has two fields, title and description. This way, when response data maps to Coffee object, the object only holds title and description from response JSON data.

package com.myproject.todoapp;

public class Coffee {

    String title;

    String description;

    public Coffee() {
    }

    public Coffee(String title, String description) {
        this.title = title;
        this.description = description;
    }

    // getters and setters
    // toString method
}

import com.myproject.apidemo.Coffee;

import org.springframework.core.ParameterizedTypeReference;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.*;
import org.springframework.web.reactive.function.client.WebClient;

@Controller
public class CoffeeController {

    @GetMapping("/coffee")
    public String coffee(Model model) {
        String url = "https://api.sampleapis.com/coffee/hot";

        WebClient.Builder builder = WebClient.builder();

        List<Coffee> coffeeList = builder.build()
                .get()
                .uri(url)
                .retrieve()
                .bodyToMono(new ParameterizedTypeReference<List<Coffee>>() {
                })
                .block();

        System.out.println("---------------------");
        System.out.println(coffeeList);

        model.addAttribute("coffeeList", coffeeList);

        return "coffee";
    }
}

In this tutorial, I prefer converting the response data to Coffee object, so I stick to second version implementation.

Create View page

Finally we need view page just to display list of coffee:

<!doctype html>
<html lang="en" xmlns:th="http://www.thymeleaf.org">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Coffee</title>
</head>
<body>

<h3>Coffee List</h3>

<table>
    <tbody>
    <tr th:each="coffee: ${coffeeList}">
        <td th:text="${coffee.title}"></td>
        <td th:text="${coffee.description}"></td>
    </tr>
    </tbody>
</table>

</body>
</html>

Done! Now you should be able to get data from http://localhost:8080/coffee.

Refactoring code

Although we could successfully call the API, there's a room for improvement. Currently coffee method instantiates WebClient.Builder object each time when it gets called. This is unnecessary overhead. Better implementation is creating separate file that configures WebClient.Builder.

Create configuration file for WebClient:

@Configuration
public class WebClientConfig {

    @Bean
    public WebClient webClient(WebClient.Builder builder) {
        return builder.build();
    }
}

Inject the Bean to our Controller class:

    private WebClient webClient;

    @Autowired
    public ToDoListController(WebClient webClient) {
        this.webClient = webClient;
    }

    @GetMapping("/coffee")
    public String coffee(Model model) {
        String url = "https://api.sampleapis.com/coffee/hot";

        List<Coffee> coffeeList = webClient
                .get()
                .uri(url)
                .retrieve()
                .bodyToMono(new ParameterizedTypeReference<List<Coffee>>() {
                })
                .block();

        // other code
    }

Now Spring Boot automatically instantiates and manages WebClient object behind the scene.

Proxy Pattern

Sota — Tue, 10 Dec 2024 14:58:50 +0000

What is Proxy Pattern?

Proxy pattern is a structural pattern that provides a surrogate or placeholder for another object to control access to it.

When to use it?

There are different types of proxies depending on its specific purpose. But essentially, Proxy pattern is providing a representative for another object.

Use the virtual proxy when the creation of a resource is expensive, and you want to delay its instantiation until it is actually needed.
Use the protection proxy when you need to control access to an object, typically based on permissions or roles.
Use the remote proxy when you want to represent an object located in a different address space (e.g., on a remote server) and communicate with it as if it were local.

There are more use cases of Proxy pattern. If you're interested, you can check on the internet for these proxies: firewall proxy, smart reference proxy, caching proxy, synchronization proxy, complexity hiding proxy, copy-on-write proxy, etc.

Problem

We're developing bank system. Each customer can access to any customer's account name and account number (to send money for example), but deposit, withdraw, and view balance operations should be only allowed by its account holder.
You might think we could create two classes Holder and NonHolder, then implements corresponding behavior. But notice a customer is a holder of their own bank account and non-holder of other bank account at the same time. We could implement in the way that customer can switch Holder or NonHolder at run time, but it's dangerous because now customers can be a holder of other customer's bank account.

We need a guardian to protect credential info from non-holder. Can you guess his name? That is the protection proxy!

Structure

Before going to Solution section, let's check out general (or static) proxy structure.

Subject provides a common interface for RealSubject and Proxy. In this way, Client aren't aware they are communicating with RealSubject, but they are actually interact with Proxy, that is why Proxy is known as a surrogate or placeholder. When Client calls a method on Proxy, Proxy decides whether it calls the requested method on RealSubject or does alternative operation such as rejecting the request or displaying text while loading heavy-weight resources.

Dynamic Proxy

Dynamic proxy is the proxy that allows client to instantiate proxy at runtime. Dynamic proxy can be implemented with Java API Proxy (java.lang.reflect.Proxy).

The class diagram is a bit different from general proxy structure. Let's steps through the diagram...

Proxy now consists of two classes, Proxy and InvocationHandler classes.

Client calls a method on Proxy.

Proxy passes the method called by Client to InvocationHandler.

InvocationHandler receives the method from Proxy, and decides whether it calls the actual method on RealSubject or does alternative things.

Solution

Sorry for making you waiting for a long time, let's get into the solution.
We'll implement dynamic protection proxy.

Client
Client calls a method on Proxy.
IBankAccount
Client talks to Proxy via IBankAccount interface.
Proxy
Proxy receives method calls from Client. These methods are passed to InvocationHandler.
HolderInvocationHandler
HolderInvocationHandler handles methods calls (invocations) from account holder. Account holder are allowed to access all methods on RealSubject.
NonHolderInvocationHandler
NonHolderInvocationHandler handles methods invocations from non account holder. Non account holder can't access to some of methods such as withdraw(). For example, if non holder calls withdraw() on Proxy, NonHolderInvocationHandler will receives that call, and block access to RealSubject.

Implementation in Java

public interface IBankAccount {
    // Anyone can access to account's name and number
    String getName();
    String getAccountNumber();

    // deposit, withdraw, viewBalance is only allowed by account holder
    void deposit(double amount);
    void withdraw(double amount);
    void viewBalance();
}

public class BankAccount implements IBankAccount {

    private String name;
    private String accountNumber;
    private double balance;

    public BankAccount(String name, String accountNumber, double balance) {
        this.name = name;
        this.accountNumber = accountNumber;
        this.balance = balance;
    }

    @Override
    public String getName() {
        return name;
    }

    @Override
    public String getAccountNumber() {
        return accountNumber;
    }

    @Override
    public void deposit(double amount) {
        balance += amount;
        System.out.println(name + " deposit $" + amount);
    }

    @Override
    public void withdraw(double amount) {
        balance -= amount;
        System.out.println(name + " withdraw $" + amount);
    }

    @Override
    public void viewBalance() {
        System.out.println(name + "'s balance: $" + balance);
    }
}

public class HolderInvocationHandler implements InvocationHandler {

    private IBankAccount account;

    public HolderInvocationHandler(IBankAccount account) {
        this.account = account;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        try {
            return method.invoke(account, args);
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        }
        return null;
    }
}

public class NonHolderInvocationHandler implements InvocationHandler {

    private IBankAccount account;

    public NonHolderInvocationHandler(IBankAccount account) {
        this.account = account;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws IllegalAccessException {
        try {
            // Anyone can access to other person's name and account number
            if (method.getName().startsWith("get")) {
                method.invoke(account, args);
            } else {
                // Other methods like deposit() are not allowed by anyone but account holder
                throw new IllegalAccessException();
            }
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        }
        return null;
    }
}

public class BankAccountTestDrive {

    public static void main(String[] args) {
        BankAccountTestDrive test = new BankAccountTestDrive();
        test.drive();
    }

    public void drive() {
        // Instantiate real subject
        IBankAccount alex = new BankAccount("Alex", "123-abc-456", 500.0);

        System.out.println("-- Testing access via holder proxy --");
        IBankAccount holderProxy = getHolderProxy(alex); // Create proxy
        // Holder proxy allows everything
        System.out.println("Account name: " + holderProxy.getName());
        System.out.println("Account number: " + holderProxy.getAccountNumber());
        holderProxy.deposit(100.0);
        holderProxy.withdraw(50.0);
        holderProxy.viewBalance();

        System.out.println("-- Testing access via non-holder proxy --");
        IBankAccount nonHolderProxy = getNonHolderProxy(alex); // Create proxy
        // Non holder proxy allows getting name and account number
        System.out.println("Account name: " + holderProxy.getName());
        System.out.println("Account number: " + holderProxy.getAccountNumber());
        // Non holder proxy doesn't allow accessing credential info
        try {
            nonHolderProxy.deposit(200.0);
        } catch (Exception e) {
            System.out.println("Can't deposit from non-holder proxy");
        }
        try {
            nonHolderProxy.withdraw(50.0);
        } catch (Exception e) {
            System.out.println("Can't withdraw from non-holder proxy");
        }
        try {
            nonHolderProxy.viewBalance();
        } catch (Exception e) {
            System.out.println("Can't view balance from non-holder proxy");
        }
    }

    // This method takes a IBankAccount object (real subject) and returns a proxy for it.
    // Because proxy has the same interface as the subject, this method returns IBankAccount.
    IBankAccount getHolderProxy(IBankAccount account) {
        // Call static method newProxyInstance on Java API Proxy
        return (IBankAccount) Proxy.newProxyInstance(
                account.getClass().getClassLoader(), // Pass class loader
                account.getClass().getInterfaces(), // Proxy needs to implement the interfaces that real subject implements
                new HolderInvocationHandler(account)); // Pass real subject into the constructor of the invocation handler.
    }

    IBankAccount getNonHolderProxy(IBankAccount account) {
        return (IBankAccount) Proxy.newProxyInstance(
                account.getClass().getClassLoader(),
                account.getClass().getInterfaces(),
                new NonHolderInvocationHandler(account));
    }
}

Output:

-- Testing access via holder proxy --
Account name: Alex
Account number: 123-abc-456
Alex deposit $100.0
Alex withdraw $50.0
Alex's balance: $550.0
-- Testing access via non-holder proxy --
Account name: Alex
Account number: 123-abc-456
Can't deposit from non-holder proxy
Can't withdraw from non-holder proxy
Can't view balance from non-holder proxy

Pitfalls

Proxy increases the number of classes and objects in our design.

Comparison with Decorator Pattern

Decorator and Proxy both wraps objects, but their intent is different. Decorator adds small behavior to an object, while Proxy controls access.

You can check all the design pattern implementations here.
GitHub Repository

State Pattern

Sota — Sun, 08 Dec 2024 11:52:03 +0000

What is State Pattern?

State pattern is a behavioral pattern that allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

When to use it?

Use State pattern when you have an object whose behavior is different depending on its current state.
Use State pattern when you want to implement system that represents finite automata.

Problem

We are developing vending machine system. Here's the graph that shows the flow of how vending machine works.

If you've studied computer science, you may notice it looks like Finite Automata (if you don't know what is FA, no worries, you don't need to know about it to understand State pattern). In the graph, circles represent states and arrows represent state transaction.

Anyway, let's begin to code our first version of system.

public class VendingMachine {

    // Vending machine has four states
    final static int OUT_OF_STOCK = 0;
    final static int IDLE = 1;
    final static int HAS_MONEY = 2;
    final static int DRINK_SOLD = 3;

    // When vending machine is placed, it has no drink stocks
    int state = OUT_OF_STOCK; // Our initial state
    int stocks = 0;

    public VendingMachine(int stocks) {
        this.stocks = stocks;
        if (stocks > 0) {
            state = IDLE;
        }
    }

    public void insertMoney() {
        if (state == OUT_OF_STOCK) {
            System.out.println("ERROR: Drink is out of stock");
        } else if (state == IDLE) {
            System.out.println("SUCCESS: You inserted money");
            state = HAS_MONEY;
        } else if (state == HAS_MONEY) {
            System.out.println("ERROR: You already inserted money, you can buy now");
        } else if (state == DRINK_SOLD) {
            System.out.println("ERROR: Please wait, we're dispensing you a drink that you bought");
        }
    }

    public void pressBuyButton() {
        // if statements for each states
    }

    public void pressCancelButton() {
        // if statements for each states
    }

    public void dispenseDrink() {
        // if statements for each states
    }

    public void refill() {
        // if statements for each states
    }
}

Can you spot the problems?

This code violates open-closed principle.
This code violates single responsibility principle.
This code doesn't encapsulate what varies.
State transitions are not explicit, they are placed under the conditional statements.
If you add other states or state transitions, it is likely to cause bugs in already working code.

Solution

So, how do we tackle those problems? We are going to turn each state into an object, then implement methods representing state transition from that specific state (object).

Client
Client interact with VendingMachine.
VendingMechine
This class holds a number of states. By introducing State interface, it depends on interface not implementation.
State
Provides common interface for all ConcreteState.
ConcreteStates
Each state transaction has different behavior depending on the state. For example, insertMoney method defined in the Idle class and the one in the OutOfStock state behave differently.

Now, lots of if statements in VendingMachine are removed, and state transitions are explicit (You'll see this in implementation).

Structure

Does this structure remind you of another pattern? Yes, this class diagram is fundamentally the same as Strategy pattern, but their intents differ. We'll discuss it later.

Implementation in Java

// Declare all possible state transition methods
public interface State {
    void insertMoney();
    void pressBuyButton();
    void pressCancelButton();
    void dispenseDrink();
    void refill(int stocks);
}

public class DrinkSold implements State {

    VendingMachine machine;

    public DrinkSold(VendingMachine machine) {
        this.machine = machine;
    }

    @Override
    public void insertMoney() {
        System.out.println("ERROR: no state transition occurs");
    }

    @Override
    public void pressBuyButton() {
        System.out.println("ERROR: no state transition occurs");
    }

    @Override
    public void pressCancelButton() {
        System.out.println("ERROR: no state transition occurs");
    }

    @Override
    public void dispenseDrink() {
        machine.customerTakesDrink();
        if (machine.getStocks() > 0) {
            System.out.println("SUCCESS: DrinkSold -> Idle");
            machine.setState(machine.getIdle());
        } else {
            System.out.println("SUCCESS: DrinkSold -> OutOfStock");
            machine.setState(machine.getOutOfStock());
        }
    }

    @Override
    public void refill(int stocks) {
        System.out.println("ERROR: no state transition occurs");
    }
}

I'll skip other concrete states because they are similar, but you can check them in my GitHub repo (link to my repo is at the end of this blog).

public class VendingMachine {

    private State idle;
    private State hasMoney;
    private State drinkSold;
    private State outOfStock;

    private State currentState;
    int stocks = 0;

    public VendingMachine(int stocks) {
        idle = new Idle(this);
        hasMoney = new HasMoney(this);
        drinkSold = new DrinkSold(this);
        outOfStock = new OutOfStock(this);

        this.stocks = stocks;
        if (stocks > 0) {
            currentState = idle;
        } else {
            currentState = outOfStock;
        }
    }

    // State transition methods, actual implementation is delegated to concrete states
    public void insertMoney() {
        currentState.insertMoney();
    }

    public void pressBuyButton() {
        currentState.pressBuyButton();
        currentState.dispenseDrink();
    }

    public void pressCancelButton() {
        currentState.pressCancelButton();
    }

    public void refill(int stocks) {
        currentState.refill(stocks);
    }

    // Method to be used by concrete states to move one state to another
    public void setState(State state) {
        currentState = state;
    }

    // Helper method used when dispensing a drink on DrinkSold state
    public void customerTakesDrink() {
        if (stocks > 0) {
            System.out.println("Customer grab a drink");
            stocks--;
        }
    }

    // Getter for each state
    public State getIdle() {
        return idle;
    }

    public State getHasMoney() {
        return hasMoney;
    }

    public State getDrinkSold() {
        return drinkSold;
    }

    public State getOutOfStock() {
        return outOfStock;
    }

    public int getStocks() {
        return stocks;
    }

    public void setStocks(int stocks) {
        this.stocks = stocks;
    }

    @Override
    public String toString() {
        return "VendingMachine {" +
                "currentState: " + currentState.getClass().getSimpleName() +
                ", stocks: " + stocks +
                '}';
    }
}

public class VendingMachineTestDrive {

    public static void main(String[] args) {
        VendingMachine machine = new VendingMachine(2);

        System.out.println(machine);

        System.out.println("-- Customer insert money and cancel the transaction --");
        machine.insertMoney();
        machine.pressCancelButton();

        System.out.println("-- Customer insert money and buy a drink --");
        machine.insertMoney();
        machine.pressBuyButton();

        System.out.println(machine);

        System.out.println("-- Customer insert money and buy a drink --");
        machine.insertMoney();
        machine.pressBuyButton();

        System.out.println(machine);

        System.out.println("-- Customer insert money --");
        machine.insertMoney();

        System.out.println("-- Owner is going to refill drinks --");
        machine.refill(2);
        System.out.println(machine);
    }
}

Output:

VendingMachine {currentState: Idle, stocks: 2}
-- Customer insert money and cancel the transaction --
SUCCESS: Idle -> HasMoney
SUCCESS: HasMoney -> Idle
-- Customer insert money and buy a drink --
SUCCESS: Idle -> HasMoney
SUCCESS: HasMoney -> DrinkSold
Customer grab a drink
SUCCESS: DrinkSold -> Idle
VendingMachine {currentState: Idle, stocks: 1}
-- Customer insert money and buy a drink --
SUCCESS: Idle -> HasMoney
SUCCESS: HasMoney -> DrinkSold
Customer grab a drink
SUCCESS: DrinkSold -> OutOfStock
VendingMachine {currentState: OutOfStock, stocks: 0}
-- Customer insert money --
ERROR: no state transition occurs
-- Owner is going to refill drinks --
SUCCESS: OutOfStock -> Idle
VendingMachine {currentState: Idle, stocks: 2}

Pitfalls

State pattern tends to end up having lots of classes because you'll have as many classes as states exist. If some states are almost identical, you could combine them together. This way, we reduce duplicate code but violate single responsibility principle, remember they are trade-off when you use State pattern.
If there are many reachable states from one state, it will be more complicated to implement.

Comparison with Strategy Pattern

They both allows objects to incorporate different behavior through composition and delegation.
In Strategy pattern, "Client" changes object's behavior at runtime. On the other hand, in State pattern, "Context" changes states according to well-defined state transition methods.

You can check all the design pattern implementations here.
GitHub Repository

Composite Pattern

Sota — Sat, 07 Dec 2024 10:19:10 +0000

What is Composite Pattern?

Composite pattern is a structural pattern that allows you to compose objects into tree structures to represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

In Composite pattern, elements with child elements are called nodes and elements without children are called leaves.

When to use it?

Use Composite pattern when you need whole-part or parent-child or tree-like hierarchy.
Use Composite pattern when you want to let client to treat child and parent in a tree uniformly.

Problem

We are trying to implement simple file system. First of all, we need File and Directory classes. But it will be difficult for client to keep checking which instances of classes each object is as our file structure grows bigger.
File system is a perfect example of tree-like hierarchy, and we want to treat File and Directory uniformly. Time to use Composite pattern!

Solution

Client
Client doesn't care whether an object is instance of File or Directory thanks to FileSystemComponent. Additionally, client doesn't have to write if statements to make sure whether he is calling right methods on the right objects.
FileSystemComponent
File and Directory are seen as FileSystemComponent by Client. FileSystemComponent defines default behavior for methods, default behavior can be exception, doing nothing, returning null or false, whatever makes sense for your application.
File
This is our leaf, overriding print method that prints its name and content.
Directory
This is our node, overriding methods to add, remove, get children. print method prints out its name and calls children's print methods as well so that Client doesn't need to call each component's print method.

Structure

Implementation in Java

public abstract class FileSystemComponent {

    protected String name;

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

    public String getName() {
        return name;
    }

    public void print(int indentLevel) {
        throw new UnsupportedOperationException();
    }

    public void add(FileSystemComponent component) {
        throw new UnsupportedOperationException();
    }

    public void remove(int index) {
        throw new UnsupportedOperationException();
    }

    // Instead of throwing exception, we do nothing by default.
    // Doing nothing makes sense because leaf has no child.
    public void getChildren() {
    }
}

public class File extends FileSystemComponent {

    private String content;

    public File(String name, String content) {
        super(name);
        this.content = content;
    }

    @Override
    public void print(int indentLevel) {
        String indent = " ".repeat(indentLevel);
        System.out.println(indent + name + ": " + content);
    }
}

public class Directory extends FileSystemComponent {

    private List<FileSystemComponent> children;

    public Directory(String name) {
        super(name);
        children = new ArrayList<>();
    }

    @Override
    public void print(int indentLevel) {
        String indent = " ".repeat(indentLevel);
        System.out.println(indent + name + " directory:");
        for (FileSystemComponent child : children) {
            child.print(indentLevel + 2);
        }
    }

    @Override
    public void add(FileSystemComponent component) {
        children.add(component);
    }

    @Override
    public void remove(int index) {
        children.remove(index);
    }

    @Override
    public void getChildren() {
        if (children.isEmpty()) {
            return;
        }
        StringBuilder builder = new StringBuilder("[");
        for (FileSystemComponent child : children) {
            builder.append(child.getName() + ", ");
        }
        builder.delete(builder.length() - 2, builder.length());
        builder.append("]");
        System.out.println(builder);
    }
}

public class FileSystemTestDrive {

    public static void main(String[] args) {
        FileSystemComponent rootDirectory = new Directory("Root");
        FileSystemComponent fruitsDirectory = new Directory("Fruits");
        FileSystemComponent animalDirectory = new Directory("Animal");
        FileSystemComponent felineDirectory = new Directory("Feline");

        rootDirectory.add(fruitsDirectory);
        rootDirectory.add(animalDirectory);

        fruitsDirectory.add(new File("Appple", "red and juicy."));
        fruitsDirectory.add(new File("Banana", "yellow and sweet."));
        fruitsDirectory.add(new File("Lemon", "yellow and sour."));

        animalDirectory.add(felineDirectory);
        felineDirectory.add(new File("Lion", "King of animal."));
        felineDirectory.add(new File("Tiger", "Has cool color pattern."));

        rootDirectory.print(0);
        rootDirectory.getChildren();
        rootDirectory.remove(0);
        rootDirectory.getChildren();

        // What happens we call getChildren() on leaf? (we don't override the method in leaf class)
        FileSystemComponent file = new File("sample", "this is leaf");
        file.getChildren(); // leaf calls default behavior, doing nothing
    }
}

Output:

Root directory:
  Fruits directory:
    Appple: red and juicy.
    Banana: yellow and sweet.
    Lemon: yellow and sour.
  Animal directory:
    Feline directory:
      Lion: King of animal.
      Tiger: Has cool color pattern.
[Fruits, Animal]
[Animal]

Pitfalls

If you want a composite that keeps its children in particular order, it requires more sophisticated management scheme for adding, removing and traversing children.
As composite structure becomes larger and complex, it would be more expensive to traverse. In this case, you might consider to implement a cache that stores some data to save traversals.

You can check all the design pattern implementations here.
GitHub Repository

Iterator Pattern

Sota — Sat, 07 Dec 2024 01:21:01 +0000

What is Iterator Pattern?

Iterator pattern is a behavioral pattern that provides a way to access the elements of an aggregate (collection) object sequentially without exposing its underlying representation.

When to use it?

Use Iterator pattern when you don't want to expose the data structure of your collection.
User Iterator pattern when you want one common interface to traverse different data structures instead of having many similar traversal codes for each data structure in your app.

Problem

Company "Alpha Inc." is going to merge with "Beta Inc.". We are in HR department and have to merge their employees data together.
EmployeeListA holds Alpha employees' data, and EmployeeListB has Beta employees' data. Because EmployeeListA uses Array data structure and EmployeeListB uses ArrayList, we write two traversal codes.

public class HRDepartment {

    public void printEmployee(){
        EmployeeListA employeeListA = new EmployeeListA("Alpha Inc");
        String[] alphaEmployee = employeeListA.getEmployees();

        EmployeeListB employeeListB = new EmployeeListB("Beta Inc");
        List<String> betaEmployee = employeeListB.getEmployees();

        // Traversal code for Array
        for (int i = 0; i < alphaEmployee.length; i++) {
            System.out.println(alphaEmployee[i] + " from Alpha Inc.");
        }

        // Traversal code for ArrayList
        for (int i = 0; i < betaEmployee.size(); i++) {
            System.out.println(betaEmployee.get(i) + " from Beta Inc.");
        }
    }
}

Can you spot the problems? Here's the issue our code currently has:

We are coding to concrete implementation (EmployeeListA and EmployeeListB) not to an interface.
If we decide to switch EmployeeListA data structure from Array to another one such as hash map, we need to modify our HRDepartment class a lot.
HRDepartment needs to know aggregate's internal structure, in other words, we are exposing our collection's data structure.
We have duplication of traversal code for different data structure, Array and ArrayList.

Solution

Encapsulate iteration logic

So where to begin? Let's remove our duplicate iteration codes.
It would be great if we can encapsulate iteration logic and introduce a common interface so that HRDepartment can use just one interface to iterate any data structure.

We need Iterator interface to decouple iteration logic from HRDepartment.

public interface Iterator {
    boolean hasNext();
    String next();
}

hasNext() returns boolean value indicating whether a collection has next element or not. next() returns next element in a collection. (you will see actual implementation later)

In EmployeeListA/EmployeeListA, We removed getEmployees() method because it exposes our aggregate's data structure. And importantly, we wrote new method createIterator() which creates an corresponding concrete Iterator, for example, EmployeeListA.createIterator() instantiates EmployeeListAIterator.

Introduce common interface for aggregates

Okay, we now encapsulated Iteration logic, our aggregates do not expose their underlying representation, removed duplicate traversal codes. But still one problem remains, HRDepartment depends on concrete aggregates. Let's introduce a common interface for concrete aggregates.

Structure

Implementation in Java

I'll omit EmployeeListBIterator and EmployeeListB's implementation as they are similar to those of EmployeeListAIterator and EmployeeListA. If you're not sure how to implement them, you can check in my GitHub repo (link to my repo is at the end of this blog).

public interface Iterator {
    boolean hasNext();
    String next();
}

public class EmployeeListAIterator implements Iterator {

    private String[] employees;
    private int index = 0;

    public EmployeeListAIterator(String[] employees) {
        this.employees = employees;
    }

    @Override
    public boolean hasNext() {
        if (index >= employees.length || employees[index] == null) {
            return false;
        }
        return true;
    }

    @Override
    public String next() {
        String employee = employees[index];
        index++;
        return employee;
    }
}

public interface EmployeeList {
    Iterator createIterator();
    String getCompanyName();
}

public class EmployeeListA implements EmployeeList{

    private String companyName;
    private String[] employees;
    private int SIZE = 5;
    private int index = 0;

    public EmployeeListA(String companyName) {
        this.companyName = companyName;
        employees = new String[SIZE];
        addEmployee("Alice");
        addEmployee("Alisha");
        addEmployee("Alex");
    }

    public void addEmployee(String name) {
        employees[index] = name;
        index++;
    }

    public Iterator createIterator() {
        return new EmployeeListAIterator(employees);
    }

    public String getCompanyName() {
        return companyName;
    }
}

public class HRDepartment {

    EmployeeList listA;
    EmployeeList listB;

    public HRDepartment(EmployeeList listA, EmployeeList listB) {
        this.listA = listA;
        this.listB = listB;
    }

    public void printEmployee() {
        Iterator listAIterator = listA.createIterator();
        Iterator listBIterator = listB.createIterator();

        System.out.println("--- Employees from " + listA.getCompanyName() + " ---");
        printEmployee(listAIterator);
        System.out.println("--- Employees from " + listB.getCompanyName() + " ---");
        printEmployee(listBIterator);
    }

    private void printEmployee(Iterator iterator) {
        while (iterator.hasNext()) {
            System.out.println(iterator.next());
        }
    }
}

Output:

--- Employees from Alpha Inc ---
Alice
Alisha
Alex
--- Employees from Beta Inc ---
Bob
Bella
Benjamin

Pitfalls

Iterator itself imply no ordering in which elements are visited during iteration. The order of iteration depends on the underlying data structure being traversed, not on the Iterator.
Iterator does not support accessing elements by index.

Iterator & Iterable interface in Java

Before the end of this blog, let's check how we can use java.util.Iterator.

All Collection classes such as ArrayList, implement the Collection interface, which extends Iterable interface. Thus every Collection class is Iterable.

public class IteratorDemo {
    public static void main(String[] args) {
        List<Integer> nums = new ArrayList<>(List.of(0, 1, 2, 3));
        Iterator<Integer> iterator = nums.iterator();
        while (iterator.hasNext()) {
            System.out.println(iterator.next());
        }
    }
}

You can check all the design pattern implementations here.
GitHub Repository

Template Method Pattern

Sota — Thu, 05 Dec 2024 07:40:41 +0000

What is Template method pattern?

Template method pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

When to use it?

Use Template method pattern when you have classes that contains similar algorithms with minor differences.

Problem

Let's say we create classes represents animal behavior. Our first version of implementation is below:

Dog and Bird, they both wake up in the morning and sleep in the night, but eat different things. Our superclass Animal defines common methods for all animals such as wakeUp() and sleep(), but doDailyRoutine() method is declared as abstract and we delegate its implementation to subclasses because it is vary for each animal.

public abstract class Animal {

    public String name;

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

    public abstract void doDailyRoutine();

    public void wakeUp() {
        System.out.println(name + " wakes up in the morning.");
    }

    public void sleep() {
        System.out.println(name + " sleeps in the night.");
    }
}

public class Bird extends Animal {

    public Bird(String name) {
        super(name);
    }

    @Override
    public void doDailyRoutine() {
        wakeUp();
        eatFruit();
        sleep();
    }

    public void eatFruit() {
        System.out.println(name + " eats a fruit.");
    }
}

public class Dog extends Animal {

    public Dog(String name) {
        super(name);
    }

    @Override
    public void doDailyRoutine() {
        wakeUp();
        eatDogFood();
        sleep();
    }

    public void eatDogFood() {
        System.out.println(name + " eats dog food.");
    }
}

The problem we have is eatFruit and eatDogFood methods. Despite of different kinds of foods, they both do the same thing, eating. For just one slight difference, we need to write doDailyRoutine method in subclasses over and over. So we should pull up abstraction level to get rid of code duplication.
Also, animals may have their own behavior. We'll see how we can make a room for additional behavior, yet still reduces code duplication.

Solution

Animal
Instead of defining doDailyRoutine in subclasses, we define it in superclass Animal. All animals exactly follow the order, that is, wakeUp, eat, sleep. eat method is declared as abstract because each animal eats different things.
additionalBehavior has empty body, so it does nothing. However, we can override the method in subclasses if some animal have unique behavior. This kind of method is called hook in Template method pattern.
Animal subclasses
Although animal subclasses can't change algorithm structure, they can override some of the step methods used by doDailyRoutine(). Also, they can optionally add additional behavior by overriding the hook method.

Structure

Implementation in Java

public abstract class Animal {

    public String name;

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

    // TemplateMethod is final to prevent subclasses changes its structure
    public final void doDailyRoutine() {
        wakeUp();
        additionalBehavior();
        eat();
        sleep();
    }

    public void wakeUp() {
        System.out.println(name + " wakes up in the morning.");
    }

    public abstract void eat();

    public void sleep() {
        System.out.println(name + " sleeps in the night.");
    }

    public void additionalBehavior() {
    }
}

public class Dog extends Animal {

    public Dog(String name) {
        super(name);
    }

    @Override
    public void eat() {
        System.out.println(name + " eats dog food.");
    }

    @Override
    public void additionalBehavior() {
        System.out.println(name + " gets cuddled.");
    }
}

public class Bat extends Animal {

    public Bat(String name) {
        super(name);
    }

    @Override
    public void wakeUp() {
        System.out.println(name + " wakes up in the night.");
    }

    @Override
    public void eat() {
        System.out.println(name + " eats insects.");
    }

    @Override
    public void sleep() {
        System.out.println(name + " sleeps in the morning.");
    }
}

public class AnimalTestDrive {

    public static void main(String[] args) {
        Animal bird = new Bird("Pigeon");
        Animal dog = new Dog("Golden retriever");
        Animal bat = new Bat("Silver-haired bat");

        bird.doDailyRoutine();
        System.out.println();
        dog.doDailyRoutine();
        System.out.println();
        bat.doDailyRoutine();
    }
}

Output:

Pigeon wakes up in the morning.
Pigeon sings.
Pigeon eats fruits.
Pigeon sleeps in the night.

Golden retriever wakes up in the morning.
Golden retriever gets cuddled.
Golden retriever eats dog food.
Golden retriever sleeps in the night.

Silver-haired bat wakes up in the night.
Silver-haired bat eats insects.
Silver-haired bat sleeps in the morning.

Pitfalls

Algorithm implementations can be spread over multiple subclasses making it hard to maintain.
Granularity and flexibility are tradeoff relationship. If AbstractClass have many abstract methods, it offers more flexibility but we'll have more burden in subclasses.

You can check all the design pattern implementations here.
GitHub Repository

Facade Pattern

Sota — Tue, 03 Dec 2024 00:39:55 +0000

What is Facade Pattern?

Facade pattern is a structural pattern that provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

When to use it?

Use Facade pattern when you need simplified interface that orchestrates many classes and does the complex work.

Problem

Our company is going to sell a car. To start driving, a client needs to follow these procedure...

unlock the door
open the door
start engine
turn on the dashboard
turn on the navigation screen
if outside is dark, turn on the headlight
close the door
lock the door

Even a client hasn't pedal yet, there are already 8 steps.
How would it be in OOP? In fact, we need 5 different classes and 8 methods calls.

        door.unlock();
        door.open();
        engine.start();
        dashBoard.on();
        screen.on();
        if (isOutsideDark) {
            light.on();
        }
        door.close();
        door.lock();

The question is, is there a easier way for a client to deal with tasks such as starting driving, stopping driving and so on? Yes, there is Facade pattern.

Solution

Client
Client can use CarFacade to do a task, and have access to subsystem classes.
CarFacade
Provides simplified interface to start driving, stop driving.
Subsystem classes
Complex system that hard to use. (For the sake of simplicity, I implemented not much complex subsystem)

Structure

Implementation in Java

Implementing subsystem classes is not important to explain Facade pattern, so I omit these parts but you can check in my Github at the end of this blog.

public class CarFacade {

    private DashBoard dashBoard;
    private Door door;
    private Engine engine;
    private HeadLight light;
    private NavigationScreen screen;

    private boolean isOutsideDark;

    public CarFacade(DashBoard dashBoard,
                     Door door,
                     Engine engine,
                     HeadLight light,
                     NavigationScreen screen,
                     boolean isOutsideDark) {
        this.dashBoard = dashBoard;
        this.door = door;
        this.engine = engine;
        this.light = light;
        this.screen = screen;
        this.isOutsideDark = isOutsideDark;
    }

    public void startDriving() {
        door.unlock();
        door.open();
        engine.start();
        dashBoard.on();
        screen.on();
        if (isOutsideDark) {
            light.on();
        }
        door.close();
        door.lock();
    }

    public void endDriving() {
        light.off();
        screen.off();
        dashBoard.off();
        engine.stop();
        door.unlock();
        door.open();
    }
}

public class Client {

    public static void main(String[] args) {
        // Create components
        DashBoard dashBoard = new DashBoard();
        Door door = new Door();
        Engine engine = new Engine();
        HeadLight light = new HeadLight();
        GPS gps = new GPS();
        NavigationScreen screen = new NavigationScreen(gps);

        // Instantiates Facade with all the components in the subsystem
        CarFacade automatedCar = new CarFacade(dashBoard, door, engine, light, screen, true);

        // Use the simplified interface to start and end driving
        automatedCar.startDriving();
        System.out.println();
        automatedCar.endDriving();
    }
}

Output:

Unlock the door
Open the door
Start Engine
DashBoard displays speed: 60km/h, fuel remaining: 70%
Navigation screen displays gps: 43.01787, -76.216435
HeadLight is on
Close the door
Lock the door

HeadLight is off
Navigation screen is off
DashBoard is off
Stop Engine
Unlock the door
Open the door

Pitfalls

There is no really known pitfall to Facade.

Comparison with Adapter Pattern

Adapter pattern introduces new interface to adapt incompatible interface to the interface the client expects, while Facade pattern creates unified interface that makes subsystem easier to use.

You can check all the design pattern implementations here.
GitHub Repository

Adapter Pattern

Sota — Sat, 30 Nov 2024 06:45:13 +0000

What is Adapter Pattern?

Adapter pattern is a structural pattern that converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

When to use it?

Use Adapter pattern when you want to use legacy code or third-party libraries but its interface is incompatible with other part of your application.

Problem

We've been using an old printer but now new free software is invented which is integrated with modern printer. The problem is we can't afford to buy modern printer but still want to use the software. Is there a way of using new software but with old printer which is incompatible with the software? Yes, here Adapter pattern comes in handy.

Solution

NewSoftware
This is our Client. This only accepts ModernPrinter interface. NewSoftware thinks it's dealing with ModernPrinter.
ModernPrinter
Provides compatible interface for Client.
PrinterAdapter
Receives a method call modernPrint() from ModernPrinter, then translates it into a format the
OldPrinter
This is what we want to use but its interface is incompatible with our NewSoftware. oldPrint() gets executed when ModernPrinter calls modernPrint().

Structure

Remember an adapter can be used with any subclass of the adaptee.

Implementation in Java

public class OldPrinter {

    public void oldPrint(String document) {
        System.out.println(document + " by old printer");
    }
}

public interface ModernPrinter {

    void modernPrint(String document);
}

public class PrinterAdapter implements ModernPrinter {

    private OldPrinter oldPrinter;

    public PrinterAdapter(OldPrinter oldPrinter) {
        this.oldPrinter = oldPrinter;
    }

    @Override
    public void modernPrint(String document) {
        oldPrinter.oldPrint(document);
    }
}

public class NewSoftware {

    public static void main(String[] args) {
        OldPrinter oldPrinter = new OldPrinter();
        // Because PrinterAdapter implements ModernPrinter, it can be seen
        // as a ModernPrinter which is integrated with NewSoftware
        ModernPrinter adapter = new PrinterAdapter(oldPrinter);
        adapter.modernPrint("Hello world");
    }
}

In our assumption, you NewSoftware is integrated with ModernPrinter, so it doesn't make sense to code like oldPrinter.oldPrint("Hello world"); in NewSoftware class (even though it will be compiled without errors).

Output:

Hello world by old printer

Object and Class Adapter

What we’ve seen is called an Object Adapter, which adapts the adaptee using composition. There is another type of adapter called a Class Adapter, which uses inheritance to achieve the intent of the Adapter pattern.

Java doesn't support multiple inheritance. So we can't use class adapter in Java, but we will study it anyway as you might encounter class adapter in other language.

Because object adapter uses composition, Adapter can hold references to one or more Adaptee objects. Thus, object adapter offers more flexibility. While class adapter is tightly coupled with one and only one adaptee which leads to less flexibility.

Pitfalls

An adapter that does a lot of work besides simple interface translation results in adding/altering adaptee behavior, which is far from the intent of Adapter pattern.

Comparison with Decorator Pattern

Decorator pattern wraps object to add small behavior, while Adapter pattern wraps object to adapt to the interface that is required by Client.

You can check all the design pattern implementations here.
GitHub Repository

Command Pattern

Sota — Thu, 28 Nov 2024 23:57:24 +0000

What is Command Pattern?

Command pattern is a behavioral pattern that encapsulates a request as an independent object, thereby letting you pass requests as method arguments, queue or log requests, and support undoable operation.

When to use it?

Use Command pattern when you need to decouple an object making requests from the objects that know how to perform the requests.
Use Command pattern when you want to inject or assign different requests to objects at runtime.
Use Command pattern when you need undo or redo operation in your application.

Problem

Imagine we are designing API for a remote control that manipulates electronic devices in client house. Here we have lots of vender classes.

Introducing a common interface doesn't seem to be interesting since our vender classes are diverse, and it is also expected that we will have more vender classes.

Additionally, the remote control shouldn't consist of a set of if statements such as if slot1 == light, then light.turnOn(), else if slot1 == tv, then tv.turnOn() because it is a bad design.

Solution

Simply put, we want the remote control to know how to make a generic request but not to care about a specific vender class. To achieve this, we are going to separate our concern into two classes, one makes a request and another one actually performs the work to comply the request.

RemoteControl
This is the one that makes a request such as command.execute(), but doesn't care how to perform the work.
If you want RemoteControl to have multiple slots—for example, one for OutdoorLight and another for TV—RemoteControl can have arrays of commands, such as onCommands[] and offCommands[]. The setCommand method can take an integer to determine which slot to set. For instance, setCommand(2, TVonCommand, TVoffCommand) might assign TVonCommand to onCommands[2] and TVoffCommand to offCommands[2].
Command
Provides interface for all the ConcreteCommands.
ConcreteCommand
TurnOnOutdoorLightCommand object calls execute() method and delegates "how to turn on light" to the holding OurdoorLight object.
OutdoorLight
This is the one that knows how to perform the work to comply the request from RemoteControl.
Client
Client is responsible for creating ConcreteCommands and associates them with the corresponding Receivers.

Structure

Implementation in Java

// Receiver
public class OutdoorLight {

    public void turnOn() {
        System.out.println("Outdoor light is on");
    }

    public void turnOff() {
        System.out.println("Outdoor light is off");
    }
}

public interface Command {

    void execute();

    void undo();
}

// Concrete command
public class TurnOnOutdoorCommand implements Command {

    private OutdoorLight outdoorLight;

    public TurnOnOutdoorCommand(OutdoorLight outdoorLight) {
        this.outdoorLight = outdoorLight;
    }

    @Override
    public void execute() {
        outdoorLight.turnOn();
    }

    @Override
    public void undo() {
        outdoorLight.turnOff();
    }
}

// Concrete command
public class TurnOffOutdoorLightCommand implements Command {

    OutdoorLight outdoorLight;

    public TurnOffOutdoorLightCommand(OutdoorLight outdoorLight) {
        this.outdoorLight = outdoorLight;
    }

    @Override
    public void execute() {
        outdoorLight.turnOff();
    }

    @Override
    public void undo() {
        outdoorLight.turnOn();
    }
}

// Null Object
public class NoCommand implements Command {

    @Override
    public void execute() {
    }

    @Override
    public void undo() {
    }
}

// Invoker
public class RemoteControl {

    private Command onCommand;
    private Command offCommand;
    public Stack<Command> undoCommands;

    public RemoteControl() {
        onCommand = new NoCommand();
        offCommand = new NoCommand();
        undoCommands = new Stack<>();
        undoCommands.push(new NoCommand());
    }

    public void setCommand(Command onCommand, Command offCommand) {
        this.onCommand = onCommand;
        this.offCommand = offCommand;
    }

    public void onButtonWasPushed() {
        onCommand.execute();
        undoCommands.push(onCommand);
    }

    public void offButtonWasPushed() {
        offCommand.execute();
        undoCommands.push(offCommand);
    }

    public void undoButtonWasPushed() {
        if (!(undoCommands.peek() instanceof NoCommand)) {
            Command lastCommand = undoCommands.pop();
            lastCommand.undo();
        } else {
            System.out.println("undoCommands stack is empty!");
        }
    }
}

public class Client {

    public static void main(String[] args) {
        OutdoorLight outdoorLight = new OutdoorLight(); // Create a receiver

        // Create commands on that receiver
        // These commands are encapsulated requests in other words
        Command turnOnOutdoorLight = new TurnOnOutdoorCommand(outdoorLight);
        Command turnOffOutdoorLight = new TurnOffOutdoorLightCommand(outdoorLight);

        RemoteControl rc = new RemoteControl(); // Create an invoker
        // We can pass encapsulated requests to other object
        rc.setCommand(turnOnOutdoorLight, turnOffOutdoorLight); // Set command on that invoker

        rc.undoButtonWasPushed();
        rc.onButtonWasPushed();
        rc.offButtonWasPushed();
        rc.undoButtonWasPushed();
        rc.undoButtonWasPushed();
        rc.undoButtonWasPushed();
    }
}

Output:

undoCommands stack is empty!
Outdoor light is on
Outdoor light is off
Outdoor light is on
Outdoor light is off
undoCommands stack is empty!

NoCommand is know as Null Object which is another design pattern. It is useful when you don't have a meaning object to return. Here we use it as default command that Invoker holds so that we don't need to handle null.

Pitfalls

Client needs to do lots of things such as creating ConcreteCommands & setting corresponding Receivers, creating Invoker & setting ConcreteCommands on that Invoker.

MacroCommand

MacroCommand is a simple extension of Command pattern that allows you to have one command that turns on a light, TV, AC, coffee machine and plays music.
Let's make a new kind of Command that executes a set of other Commands.

public class MacroCommand implements Command {

    Command[] commands;

    public MacroCommand(Command[] commands) {
        this.commands = commands;
    }

    // Executes holding commands one at a time
    @Override
    public void execute() {
        for (Command command : commands) {
            command.execute();
        }
    }
}

That's it! Now we're ready to use our MacroCommand. But before that, let me show you how to implement RemoteControl that can have multiple slots as I mentioned in "Solution" section.

public class RemoteControl {

    private Command[] onCommands;
    private Command[] offCommands;

    public RemoteControl() {
        // Our RemoteControl has 3 slots
        onCommands = new Command[3];
        offCommands = new Command[3];

        Command noCommand = new NoCommand();
        for (int i = 0; i < onCommands.length; i++) {
            onCommands[i] = noCommand;
            offCommands[i] = noCommand;
        }
    }

    public void setCommands(int slot, Command onCommand, Command offCommand) {
        onCommands[slot] = onCommand;
        offCommands[slot] = offCommand;
    }

    public void onButtonWasPushed(int slot) {
        onCommands[slot].execute();
    }

    public void offButtonWasPushed(int slot) {
        offCommands[slot].execute();
    }

    // Print slots info in pretty style
    @Override
    public String toString() {
        StringBuilder stringBuilder = new StringBuilder();
        stringBuilder.append("\n------ Remote Control ------\n");
        for (int i = 0; i < onCommands.length; i++) {
            stringBuilder.append("[slot " + i + "] " + onCommands[i].getClass().getSimpleName() +
                    "    " + offCommands[i].getClass().getSimpleName() + "\n");
        }
        return stringBuilder.toString();
    }
}

Pretty simple, just use array to store multiple commands.
Finally, Client uses our MacroCommand. For the sake of simplicity, I created only two receivers, Light and CoffeeMachine.

public class Client {

    public static void main(String[] args) {
        // Create receivers
        Light light = new Light();
        CoffeeMachine coffeeMachine = new CoffeeMachine();

        // Create commands and set corresponding receivers on them
        Command lightOnCommand = new LightOnCommand(light);
        Command lightOffCommand = new LightOffCommand(light);
        Command coffeeMachineOnCommand = new CoffeeMachineOn(coffeeMachine);
        Command coffeeMachineOffCommand = new CoffeeMachineOff(coffeeMachine);

        // Create arrays of commands
        Command[] morningOn = {lightOnCommand, coffeeMachineOnCommand};
        Command[] morningOff = {lightOffCommand, coffeeMachineOffCommand};

        // Create macros
        MacroCommand morningOnMacro = new MacroCommand(morningOn);
        MacroCommand morningOffMacro = new MacroCommand(morningOff);

        RemoteControl rc = new RemoteControl();
        rc.setCommands(0, morningOnMacro, morningOffMacro);

        System.out.println(rc);

        System.out.println("--- Pushing Macro On ---");
        rc.onButtonWasPushed(0);
        System.out.println("\n--- Pushing Macro Off ---");
        rc.offButtonWasPushed(0);
    }
}

Output:

------ Remote Control ------
[slot 0] MacroCommand    MacroCommand
[slot 1] NoCommand    NoCommand
[slot 2] NoCommand    NoCommand

--- Pushing Macro On ---
Light is on
Coffee machine is on
Coffee machine is making a cup of coffee

--- Pushing Macro Off ---
Light is off
Coffee machine is off

Our MacroCommand turns on the light and starts the coffee machine, which immediately begins brewing coffee. Note that we can define a set of actions in the Receiver and use them in the execute() method of the ConcreteCommand, as shown in the UML diagram in the "Structure" section.

@Override
    public void execute() {
        coffeeMachine.on();
        coffeeMachine.makeCoffee();
    }

You can check all the design pattern implementations here.
GitHub Repository

P.S.
I'm new to write tech blog, if you have advice to improve my writing, or have any confusing point, please leave a comment!
Thank you for reading :)

Singleton Pattern

Sota — Fri, 22 Nov 2024 01:07:34 +0000

What is Singleton Pattern?

The singleton pattern is a creational pattern that ensures a class has only one instance, and provides a global point of access to it.

When to use it?

Use Singleton pattern when you want to ensure only one instance of a class exists in application.

Problem

Let's try to implement our Singleton pattern.

public class Singleton {

    private static Singleton instance;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Singleton class holds static variable instance, this is our one and only instance of Singleton class.
Constructor is declared as private so that nobody can't instantiate Singleton class except for Singleton class itself.
getInstance() returns instance of Singleton class. In this code, instance gets created when it is needed, this is called lazy instantiation.

Can you spot the problem? Think what happens when we're in multithreading environment.

The problem occurs more than one thread call getInstance() at the same time. Let's see how it occurs when we have two threads...

Thread1 checks if instance is null or not, we haven't called getInstance() before, thus instance == null is true.
Thread2 also calls getInstance() and check if instance is null. Because Thread1 just entered inside if block and didn't create object, instance is still null.
Thread1 instantiates Singleton class with new keyword.
Thread2 also instantiates Singleton class.

We now have two Singleton objects, which is not desired.

Such a situation is called race condition, where multiple threads attempt to access to shared resources at the same time but its outcome is indeterministic.

Solution 1

public class Singleton {

    private static Singleton instance;

    private Singleton() {
    }

    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Solution is just adding synchronized keyword to getInstance(). synchronized keyword can ensure only one thread can enter the method at the time and other threads wait their turn.

This works fine but synchronization is expensive. synchronization is only needed when getInstance() is called for the first time since once we get instance of Singleton, getInstance() won't enter if block and just return an object that already has been created. After the first time through, synchronization is totally unneeded overhead.

Solution 2

We can implement eager instantiation Singleton if our application always creates and uses an instance of Singleton.

public class Singleton {

    // Create an instance when Singleton class is loaded by JVM
    private static Singleton instance = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
        // instance has already been created
        return instance;
    }
}

Solution 3

if performance of getInstance() is an issue (like we pointed out in Solution 1), we can implement double-checked locking Singleton.
As name indicates, this implementation does null-check for our instance twice.

First check: if instance is null, it enters the block.
Synchronization: lock on Singleton class object (Class object is a runtime representation of the class), this ensures only one thread at a time executes the synchronized block. The synchronized block represents critical section.
Second check: this check can't occur at a time because of synchronization.

public class Singleton {

    private volatile static Singleton instance;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (instance == null) { // First check
            synchronized (Singleton.class) { // Synchronization
                if (instance == null) { // Second check
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

Solution 4

Singleton sounds simple but it has many things we have to consider such as synchronization, class loading, reflection and serialization/deserialization issues. Is there any better implementation that resolves these issues? Yes, enum provides simple implementation and resolves all the issues above.

public enum Singleton {
    INSTANCE;
}

We don't need to write our own private constructor because JVM will instantiate our INSTANCE automatically.

Structure

Pitfalls

Singleton violates the single responsibility principle as it does two jobs, ensuring only one instance exists & providing a global access point to that instance.

You can check all the design pattern implementations here.
GitHub Repository

P.S.
I'm new to write tech blog, if you have advice to improve my writing, or have any confusing point, please leave a comment!
Thank you for reading :)