工厂设计模式与多态的关系：是否仅能在存在多态行为时使用？

两者的核心关联 #

工厂设计模式最常见的用法，就是和多态配合来发挥价值。简单来说，多态允许我们用父类/接口的引用指向子类实现，而工厂模式则负责把具体子类的创建逻辑封装起来，对外只暴露父类/接口类型。这样客户端代码完全不用关心到底创建的是哪个子类，只需要调用父类定义的方法就行，完美实现了创建逻辑和业务逻辑的解耦。

举个实际的代码例子：

// 定义统一接口
interface Shape {
    void draw();
}

// 具体实现类
class Circle implements Shape {
    @Override
    public void draw() {
        System.out.println("画圆形");
    }
}

class Square implements Shape {
    @Override
    public void draw() {
        System.out.println("画正方形");
    }
}

// 工厂类封装创建逻辑
class ShapeFactory {
    public static Shape createShape(String type) {
        switch(type) {
            case "circle":
                return new Circle();
            case "square":
                return new Square();
            default:
                throw new IllegalArgumentException("不支持的形状类型");
        }
    }
}

// 客户端调用
public class Client {
    public static void main(String[] args) {
        Shape shape = ShapeFactory.createShape("circle");
        shape.draw(); // 借助多态，不用关心具体实现类
    }
}

在这个例子里，工厂返回Shape接口类型，客户端通过接口调用方法，具体执行逻辑由工厂决定，多态是让这个模式能灵活扩展的关键。

工厂模式必须依赖多态吗？ #

答案是不需要，虽然多态是工厂模式最常用的搭档，但不是必要条件。

有些场景下，我们会用工厂模式封装一组没有继承关系、也无共同接口的对象的创建逻辑。比如一个工具工厂，负责创建日志器、配置读取器、数据库连接器这三个完全不相关的类：

class ToolFactory {
    public static Logger createLogger() {
        // 封装日志器的复杂初始化逻辑：加载配置、设置级别等
        return new Logger();
    }

    public static ConfigReader createConfigReader() {
        // 封装配置读取器的初始化逻辑
        return new ConfigReader();
    }

    public static DatabaseConnector createDbConnector() {
        // 封装数据库连接的初始化逻辑
        return new DatabaseConnector();
    }
}

这里的Logger、ConfigReader、DatabaseConnector之间没有任何继承关系，也不存在多态行为，但我们依然用工厂模式把它们的创建逻辑集中起来，避免客户端重复写初始化代码。这种用法虽然不如多态场景下的工厂模式“经典”，但确实是合理应用——核心是封装对象的创建逻辑，而非必须依赖多态。

不过要明白，这种无多态的工厂模式局限性很大，没法实现“替换实现类不影响客户端”的扩展能力，所以大部分实际场景中，工厂模式还是会和多态结合，才能发挥最大价值。

内容的提问来源于stack exchange，提问作者Zain Chaudhry