本文详细介绍了工厂模式的目的，包括封装和管理对象创建过程，降低用户使用的复杂性。讨论了三种工厂模式：简单工厂模式、工厂方法模式和抽象工厂模式，分析了它们的UML类图和适用场景。简单工厂模式因违背OCP原则而不利于扩展，而工厂方法模式通过子类化解决扩展问题，抽象工厂模式则在多个产品族之间提供更大的灵活性。
参考链接：https://www.cnblogs.com/yssjun/p/11102162.html
一、目的
总的来说，工厂模式的主要目的就是用于封装和管理对象的创建过程，对上层的使用者隔离对象创建的过程，之所以要隔离封装这个创建过程，主要是因为：
- 对象创建的过程复杂，使用者不容易掌握（比如对象创建要满足某种条件，但用户无需知晓），从而降低了用户使用代码的重复性以及复杂性——方便Client
- 对象本身有很多子类，并且经常性发生变化，但是对于用户是无法预料的，所以为了应对这种变化，也可以采取工厂模式，这样只需要变化的子类实现工厂方法接口即可。（比如spring容器（用户）无法知晓每一个开发人员定义的实例类，但是spring需要负责这些实例对象的创建和管理，所以spring需要使用工厂方法模式，也可以说是模板方法模式，对这些对象的创建施加一定约束条件，然后框架这边可以用一个统一的抽象工厂接口进行实例的创建）。——用于框架开发（比如spring的beanFactory、线程池的TheadFactory）
二、工厂模式的三种形式
- 简单工厂模式
该模式对对象创建管理方式最为简单，因为其仅仅简单的对不同类对象的创建进行了一层薄薄的封装。该模式通过向工厂传递类型来指定要创建的对象，其UML类图如下：
可以看出来，其创建职责交给了工厂接口来实现，这样不利于代码扩展，因为如果需要新增产品，就需要修改工厂接口，这样违背了OCP原则（对扩展开放，对修改封闭）。
2、工厂方法模式
和简单工厂模式中工厂负责生产所有产品相比，工厂方法模式将生成具体产品的任务分发给具体的产品工厂，其UML类图如下：
从上面可以知道，我们将工厂进一步进行了抽象，工厂接口不负责具体实现，而是交给下面具体的工厂子类来完成，这样如果需要新增产品，只需要新增一个具体的工厂实现类即可，无需修改工厂接口的代码。
工厂方法模式对简单工厂模式进行了抽象。有一个抽象的Factory类（可以是抽象类和接口），这个类将不再负责具体的产品生产，而是只制定一些规范，具体的生产工作由其子类去完成。
这样就满足了OCP原则，可以扩展，不要修改。
3、抽象工厂模式
最简单的方式是把2中介绍的工厂方法模式完全复制一份，不过这次生产的是PC。但同时也就意味着我们要完全复制和修改Phone生产管理的所有代码，显然这是一个笨办法，并不利于扩展和维护。
抽象工厂模式在工厂模式的基础上，通过在AbstarctFactory中增加创建产品的接口，并在具体子工厂中实现新加产品的创建来完成。
扫一扫
939
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
