Understanding Factory and Strategy Design Patterns in Java with Code Examples

When first learning design patterns, developers often use Singleton and Factory patterns most frequently; after encountering an article on Domain‑Driven Design, the author began exploring the Strategy pattern, finding that applying design patterns reduces code redundancy and makes service‑layer code cleaner.

The author notes that the Strategy pattern shares conceptual similarities with micro‑services, citing a DDD example of a bank transfer that clarifies logic and eliminates redundant code.

Although Factory and Strategy patterns may appear similar, their UML diagrams show only minor differences, prompting a deeper code‑level comparison.

First, an interface People is defined with three methods:

public interface People {
    void eat();
    void run();
    void wear();
}

Two concrete implementations, Xiaoming and Xiaohong, provide specific print statements for each method:

public class Xiaoming implements People {
    @Override
    public void eat() { System.out.println("小明吃饭"); }
    @Override
    public void run() { System.out.println("小明跑步"); }
    @Override
    public void wear() { System.out.println("小明穿衣"); }
}

public class Xiaohong implements People {
    @Override
    public void eat() { System.out.println("小红吃饭"); }
    @Override
    public void run() { System.out.println("小红跑步"); }
    @Override
    public void wear() { System.out.println("小红穿衣"); }
}

The simple factory PeopleFactory returns an instance based on a name string:

public class PeopleFactory {
    public People getPeople(String name) {
        if (name.equals("Xiaoming")) {
            return new Xiaoming();
        } else if (name.equals("Xiaohong")) {
            return new Xiaohong();
        }
        return null;
    }
}

The Strategy pattern is implemented in StrategySign, which can be constructed either with a People object or a name string, and delegates execution to the encapsulated People:

public class StrategySign {
    private People people;

    public StrategySign(People people) { this.people = people; }

    public StrategySign(String name) {
        if (name.equals("Xiaoming")) {
            this.people = new Xiaoming();
        } else if (name.equals("Xiaohong")) {
            this.people = new Xiaohong();
        }
    }

    public void run() { people.run(); }
}

A test class runs both patterns and shows identical output:

@Test
public void testSign() {
    PeopleFactory peopleFactory = new PeopleFactory();
    People people = peopleFactory.getPeople("Xiaohong");
    System.out.print("工厂模式-------------");
    people.run();

    StrategySign strategySign = new StrategySign("Xiaohong");
    System.out.print("策略模式-------------");
    strategySign.run();
}

The key difference is that the Factory pattern focuses on object creation and returns a concrete implementation, while the Strategy pattern emphasizes the process, allowing dynamic composition of behavior without changing the factory.

By extending the Strategy's run method to call eat(), run(), and eat() sequentially, developers can chain multiple actions without adding new methods for each combination, illustrating greater flexibility compared to the Factory approach.

Finally, the author draws an analogy between the Strategy pattern and micro‑service architecture: each method (eat, run, wear) can be seen as an independent service, and the Strategy pattern connects them to form higher‑level behavior, mirroring the goal of reducing coupling in micro‑services.