温故而知新之——设计模式（四）

最新推荐文章于 2021-07-29 16:28:54 发布

小蒋聊技术

最新推荐文章于 2021-07-29 16:28:54 发布

阅读量125

点赞数

本文链接：https://blog.csdn.net/wei_wei10/article/details/93626859

版权

今天来看看工厂模式究竟是一个什么玩意，能生产什么，怎么生产。工厂模式和抽象工厂模式又有哪些区别。

工厂模式：

类型：创建型模式 ,定义一个常见产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类中。这满足创建型模式中所要求的“创建与使用相分离”的特点。

工厂模式的分类：

简单工厂模式（Simple Factory），又称静态工厂方法模式（Static Factory Method Pattern）。
工厂方法模式（Factory Method），又称多态性工厂模式（Polymorphic Factory）或虚拟构造器模式（Virtual Constructor）。
抽象工厂模式（Abstract Factory），又称工具箱模式（Kit或Toolkit）。

简单工厂模式（Simple Factory）是由一个工厂类传入的参数，动态决定应该创建哪一个产品类的实例，这些产品类继承同一个父类或接口。简单工厂模式一般又称静态工厂方法模式（Static Factory Method），它属于类创建模式，但它不属于23种经典设计模式。

优点：工厂类是整个模式的关键。包含了必要的逻辑判断，根据外界给定的信息，决定究竟应该创建哪个具体的对象。使用工厂类，外界可以从直接创建具体产品对象的繁琐局面摆脱出来。仅需要负责“消费”对象，而不必管这些对象究竟如何创建及如何组织的。明确了各自的自责和权利，有利于这个软件体系结构的优化。

缺点：由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类，这违背了开闭原则。当系统中的具体产品类不断增多的时候，可能就会要求工厂类根据不同条件创建不同实例的需求。这将会导致各种条件的判断，以便选择具体的产品类型进行实例化。很容易导致工厂类变得臃肿，功能模块不断蔓延。对系统的维护和扩展非常不利。

使用场景：

工厂类负责的对象比较少；

客户只希望负责调用，对如何创建对象和对象内的实现逻辑并不关心；

工厂方法模式（Factory Method）与简单工厂模式相比,为了解决工程类中耦合的问题，将原有的实例创建逻辑推迟到子类中。核心工厂类不再负责产品的创建，核心类成为一个抽象工厂角色，仅负责声明接口。这样做的好处是在不修改具体工厂角色的情况下引入新产品。

优点：

继承了简单工厂模式的优点，符合开闭原则。

缺点：

增加产品，需要增加对应的新的工厂类。这将会导致系统类个数成对增加，在一定程度上增加了系统的复杂性。

抽象工厂模式（Abstract Facotry Pattern）提供一个创建一系列相关或相互依赖对象的的接口，而无须指定他们的具体类。抽象工厂模式又称为Kit模式，属于对象创建模型。

模式动机：

在工厂方法模式中具体工厂负责生产具体的产品，每个具体工厂对应一种具体的产品，工厂方法也有唯一性。

简单工厂模式