设计模式学习之策略模式和简单工厂模式的对比

设计模式系列往期文章

1. 设计模式学习之策略模式
2. 设计模式学习之策略模式在前端的应用
3. 设计模式学习之简单工厂模式
4. 设计模式学习之工厂方法模式
5. 设计模式学习之抽象工厂模式

在这之前我们已经介绍过了策略模式和简单工厂模式，也清楚策略模式属于行为模式，简单工厂模式属于创建型模式，但是在实际使用的过程中经常把它们混淆在一起，有些分不清楚，本文对比一下这两种设计模式。

为什么很容易把策略模式和简单工厂模式弄混呢？以下面的代码为例：

interface PainterIntf {
	void paint();
}

class APainter implements PainterIntf {
	@override
	public void paint() {
		System.out.println("paint method for APainter");
	}
}


class BPainter implements PainterIntf {
	@override
	public void paint() {
		System.out.println("paint method for BPainter");
	}
}

class Client {
	public static void main(String[] args) {
        String type = "A";
        PainterIntf painter = null;
        if (type.equals("A")) {
        	painter = new APainterIntf();
        } else {
        	painter = new BPainterIntf();
        }
        painter.paint();
    }
}

这段代码使用了什么设计模式呢？GPT给的答案如下：

这段代码使用了工厂方法模式，这是一种创建型模式，用于根据不同的条件创建不同的对象。在这个例子中，根据type的值，创建了APainter或BPainter的实例，并赋值给painter变量，然后调用paint()方法。工厂方法模式可以将对象的创建和使用分离，提高代码的灵活性和可维护性。

我个人认为这段代码既不是正规的简单工厂模式更不是策略模式，因为将对象创建的逻辑直接放在了Client类中，其实不是特别符合设计模式的初衷：让代码逻辑解耦。**这段代码并不是一个标准的简单工厂模式，而是一个简化的版本。**简单工厂模式的核心是定义一个工厂类，在该类中来实现具体的对象创建逻辑，而不是在客户端类中直接使用if-else判断。

这段代码也没有使用到策略模式，因为策略模式的核心是定义一个策略接口，让不同的算法实现这个接口，然后在一个上下文类中维护一个策略对象的引用，根据不同的情况动态地替换策略对象。这样做的好处是可以将算法的使用和实现分离，提高代码的可读性和可维护性。

下图是策略模式的类图，注意到其关键是存在一个Context类，在该类中维护了一个具体的策略实例，该实例应该是由Client通过参数传递过来的：

下图是简单工厂模式的类图，其类图和策略模式最大的不同在于没有了Context类，并且多了一个工厂类，该类和具体的产品类存在依赖关系：