深入理解简单工厂模式：从问题到解决方案

"本文主要介绍了简单工厂模式，它是工厂方法模式的一个简化版本，常用于学习其他工厂模式的基础。简单工厂模式并非GoF23种设计模式之一，但仍然是软件开发中常见的一种创建型设计模式。文章通过一个图表库设计的例子，展示了简单工厂模式在解决代码冗余和职责过重问题上的应用。" 在软件设计中，简单工厂模式是一种创建对象的模式，它提供了一个创建对象的公共接口，并隐藏了具体的创建过程。在上述例子中，`Chart` 类最初承担了过多的职责，包括创建不同类型的图表（如柱状图、饼状图、折线图）以及显示这些图表的功能。这种设计导致了以下问题： 1. **代码冗余与复杂性**：`Chart` 类内部充满了“if…else…”结构，随着图表类型增加，这样的条件语句会变得更复杂，增加了代码的阅读、维护和测试难度，同时也降低了系统性能，因为每次实例化都需要进行多次条件判断。 2. **高耦合**：`Chart` 类与具体的图表类型紧密耦合，修改或添加新的图表类型需要修改`Chart` 类的源码，不符合开放封闭原则，即软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。 3. **职责过重**：`Chart` 类既负责创建图表，又负责显示图表，违反了单一职责原则，一个类应当只有一个引起它变化的原因。 为了解决这些问题，简单工厂模式可以引入一个专门的工厂类，例如`ChartFactory`，这个工厂类负责根据输入的类型创建相应的图表对象，而`Chart` 类则只负责显示图表，不再包含创建逻辑。这样做的好处包括： 1. **解耦**：通过将创建过程与业务逻辑分离，提高了代码的可读性和可维护性，降低了耦合度。 2. **扩展性**：当需要添加新的图表类型时，只需修改工厂类，无需改动`Chart` 类，符合开放封闭原则。 3. **模块化**：每个图表类型都有独立的类，职责明确，有利于模块化设计和单元测试。 具体实现时，`ChartFactory` 可以有一个静态方法，接收图表类型作为参数，根据类型返回对应的图表对象。例如： ```java public class ChartFactory { public static Chart createChart(String type) { if (type.equalsIgnoreCase("histogram")) { return new Histogram(); } else if (type.equalsIgnoreCase("pie")) { return new Pie(); } else if (type.equalsIgnoreCase("line")) { return new Line(); } // 其他错误处理或默认行为 } } class Histogram extends Chart { // 柱状图的实现 } class Pie extends Chart { // 饼状图的实现 } class Line extends Chart { // 折线图的实现 } ``` 客户端代码可以这样使用： ```java Chart chart = ChartFactory.createChart("histogram"); chart.display(); ``` 通过引入简单工厂模式，代码结构变得更加清晰，职责划分明确，提高了代码的可维护性和可扩展性。这种模式虽然在某些方面可能不如其他更高级的工厂模式灵活，但对于许多简单的场景，简单工厂模式已经足够有效。