2.6 KiB
设计模式笔记
简单工厂（Simple Factory）
简单工厂将对象的创建过程与使用过程解耦，客户端只需传入参数，而不需要关心创建的细节和具体的子类类型。这样，当需要添加新的产品子类时，只需在工厂中扩展创建逻辑，无需修改客户端代码，从而实现了对变化的封装，提升了系统的可扩展性与可维护性。
工厂模式（Factory Method）
简单工厂里，我们的输入参数是一样的，如何处理建造时参数不同的情况呢？例如 Circle 接受圆心和半径，而 Square 接受两个对角的点。
工厂模式给出了解决方案。对于每个新的子类，有一个专门的工厂类生成这个新的子类，进而工厂类可以使用不同的参数构建新的子类。
工厂模式相对简单工厂，通过解耦获取工厂和生成子类实例，获取了更大的灵活性。比如客户端可以在得到工厂后，进一步根据工厂类型向用户请求输入。但是对于一个新类就需要额外需要一个工厂，稍微麻烦些。通过同时使用两种方式，可以达到最大的灵活性。
抽象工厂（Abstract Factory）
抽象工厂进一步的将工厂本身也作为一种产品。它定义了一个“工厂族”的接口，规定了工厂需要生产哪些种类的产品。客户端从抽象工厂获取一个具体的工厂，再从这个工厂中制造一组相互关联的具体产品。
这可以用于创建一系列相关或相互依赖的对象，而不指定它们的具体类。也就是说，它解决了产品族一致性的问题。这在组件风格切换、平台适配、多模块协作等方面很有用。
生成器模式（Builder）
假定有一种复杂对象（比如电脑，需要有 CPU，内存，主板等），如何构建这种复杂对象呢？朴素的做法是有一个接受很多参数的构造函数，这显然不好，因为参数不总是都用上的。另一种做法是扩展电脑基类，但是这意味着给电脑增加新的外设会很复杂，因为需要添加子类。
解决方案是有一种生成器类专门负责构建复杂对象。对于每一种参数，生成器类定义了接受各个参数的函数，从而做到分步创建对象。参数输入结束后，生成器类可以基于之前输入的参数创建这一复杂对象。
对于复杂场景，比如生成器需要输入十种参数，可以添加一个指导者封装这些输入这几种参数的过程。它提供了一种简化的构建流程，客户端不需要关心构建细节，代价是牺牲了一定的灵活性，因为客户无法定制每一步。