小谈设计模式（9）—工厂方法模式

本文主要是介绍小谈设计模式（9）—工厂方法模式，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

专栏介绍

专栏地址

link

专栏介绍

主要对目前市面上常见的23种设计模式进行逐一分析和总结，希望有兴趣的小伙伴们可以看一下，会持续更新的。希望各位可以监督我，我们一起学习进步，加油，各位。

工厂方法模式

工厂方法模式是一种创建型设计模式，它定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法模式将对象的实例化推迟到子类中进行。

角色分类

抽象产品（Abstract Product）

定义了产品的接口，是具体产品类的共同父类或接口。

具体产品（Concrete Product）

实现了抽象产品接口的具体类。

抽象工厂（Abstract Factory）

定义了创建产品的接口，包含一个或多个创建产品的抽象方法。

具体工厂（Concrete Factory）

实现了抽象工厂接口，负责实例化具体产品。

核心思想

将对象的创建与使用分离，客户端通过调用工厂方法来创建对象，而不是直接实例化具体产品。这样做的好处是，客户端只需要知道抽象产品和抽象工厂的存在，而无需关心具体产品的细节。当需要创建不同类型的产品时，只需要实现对应的具体产品和具体工厂即可，而不需要修改客户端的代码。

Java代码实现：

假设有一个汽车工厂，可以生产不同类型的汽车，包括小轿车和SUV。首先定义一个抽象汽车类（AbstractProduct）：

public abstract class Car {public abstract void drive();
}

然后定义具体的小轿车类（ConcreteProduct1）和SUV类（ConcreteProduct2），它们都继承自抽象汽车类：

public class SedanCar extends Car {@Overridepublic void drive() {System.out.println("Driving sedan car...");}
}public class SUV extends Car {@Overridepublic void drive() {System.out.println("Driving SUV...");}
}

接下来定义抽象汽车工厂类（AbstractFactory），其中包含一个创建汽车的抽象方法：

public abstract class CarFactory {public abstract Car createCar();
}

然后定义具体的小轿车工厂类（ConcreteFactory1）和SUV工厂类（ConcreteFactory2），它们都继承自抽象汽车工厂类：

public class SedanCarFactory extends CarFactory {@Overridepublic Car createCar() {return new SedanCar();}
}public class SUVFactory extends CarFactory {@Overridepublic Car createCar() {return new SUV();}
}

最后，在客户端代码中使用工厂方法来创建汽车对象：

public class Client {public static void main(String[] args) {CarFactory factory1 = new SedanCarFactory();Car sedanCar = factory1.createCar();sedanCar.drive();CarFactory factory2 = new SUVFactory();Car suv = factory2.createCar();suv.drive();}
}

输出结果为

Driving sedan car...
Driving SUV...

分析

通过工厂方法模式，客户端代码只需要与抽象产品和抽象工厂进行交互，而无需关心具体产品的创建过程。当需要新增其他类型的汽车时，只需要实现对应的具体产品和具体工厂即可，而不需要修改客户端的代码，实现了代码的可扩展性和可维护性。

优缺点分析

优点

符合开闭原则

工厂方法模式通过引入抽象工厂和具体工厂的概念，使得系统的扩展性更好。当需要新增一种产品时，只需要新增对应的具体产品和具体工厂，而不需要修改已有的代码，符合开闭原则。

封装了对象的创建过程

客户端只需要关心抽象产品和抽象工厂，而无需关心具体产品的创建过程。具体产品的创建过程被封装在具体工厂中，使得客户端代码更加简洁、可读性更高。

降低了客户端和具体产品的耦合

客户端只依赖于抽象产品和抽象工厂，而不依赖于具体产品。这样可以使客户端代码与具体产品解耦，提高代码的灵活性和可维护性。

可以通过配置文件等方式动态指定具体工厂类

工厂方法模式可以通过配置文件、反射等方式动态指定具体工厂类，从而实现更加灵活的对象创建方式。

缺点

增加了系统的复杂度

引入抽象工厂和具体工厂的概念，使得系统的结构变得更加复杂。如果系统中只有少量的产品，使用工厂方法模式可能会显得过于复杂，不利于维护和理解。

增加了代码的数量

工厂方法模式需要定义抽象产品、具体产品、抽象工厂、具体工厂等多个类，这增加了代码的数量。对于简单的项目，使用工厂方法模式可能会显得冗余。

客户端需要知道具体工厂类

客户端需要知道具体工厂类的存在，这增加了客户端的依赖。如果具体工厂类的创建逻辑发生变化，客户端代码也需要相应的修改。

这篇关于小谈设计模式（9）—工厂方法模式的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---