设计模式系列-Builder模式,工厂方法模式和抽象工厂模式

Posted 2023-04-28

参考技术A 定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示

使用场景：
1.多个部件或零件，都可以装配到一个对象中，但产生的结果又不相同时。
2.当初始化一个对象特别复杂的时候，比如参数多，而且很多参数都有默认值。

它分为抽象建造者（Builder）角色、具体建造者（ConcreteBuilder）角色、导演者（Director）角色、产品（Product）角色四个角色。

抽象建造者（Builder）角色：给 出一个抽象接口，以规范产品对象的各个组成成分的建造。

具体建造者（ConcreteBuilder）角色：要完成的任务包括：1.实现抽象建造者Builder所声明的接口，给出一步一步地完成创建产品实例的操作。2.在建造过程完成后，提供产品的实例。

导演者（Director）角色：担任这个角色的类调用具体建造者角色以创建产品对象。

产品（Product）角色：产品便是建造中的复杂对象。

定义：定义一个用于创建对象的接口，让子类决定实例化哪个类。

任何需要生成复杂对象的地方，都可以使用工厂方法模式。用new就能创建的对象不需要使用工厂模式，因为使用工厂模式就要增加一个工厂类，增加了系统复杂度。

关于工厂方法模式的实现

当确定工厂类只有一个的时候，简单工厂模式

工厂方法模式注重的是整体对象的创建方法，而建造者模式注重的是部件构建的过程，旨在通过一步一步地精确构造创建出一个复杂的对象。
我们举个简单例子来说明两者的差异，如要制造一个超人，如果使用工厂方法模式，直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人；
而如果使用建造者模式，则需要组装手、头、脚、躯干等部分，然后再把内裤外穿，于是一个超人就诞生了。

工厂方法模式创建的产品一般都是单一性质产品，如成年超人，都是一个模样，而建造者模式创建的则是一个复合产品，它由各个部件复合而成，部件不同产品对象当然不同。
这不是说工厂方法模式创建的对象简单，而是指它们的粒度大小不同。一般来说，工厂方法模式的对象粒度比较粗，建造者模式的产品对象粒度比较细。

两者的区别有了，那在具体的应用中，我们该如何选择呢？
是用工厂方法模式来创建对象，还是用建造者模式来创建对象，这完全取决于我们在做系统设计时的意图，如果需要详细关注一个产品部件的生产、安装步骤，则选择建造者，否则选择工厂方法模式。

定义：为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类

抽象工厂模式的使用场景定义非常简单：一个对象族（或是一组没有任何关系的对象）都有相同的约束，则可以使用抽象工厂模式。

通过工厂类，只要知道工厂类是谁，我就能创建出一个需要的对象

注意事项：
在抽象工厂模式的缺点中，我们提到抽象工厂模式的产品族扩展比较困难，但是一定要清楚，是产品族扩展困难，而不是产品等级。
在该模式下，产品等级是非常容易扩展的，增加一个产品等级，只要增加一个工厂类负责新增加出来的产品生产任务即可。
也就是说横向扩展容易，纵向扩展困难。
抽象类AbstractCreator要增加一个方法createProductC()，然后两个实现类都要修改，想想看，这严重违反了开闭原则。

关于c++设计模式的总结

关于c++设计模式的总结

抽象工厂，决定产品系列的产品的组合，特点是创建同一款式的产品系列。缺点是增加产品组件，需要修改抽象工厂接口，影响抽象工厂子类。

builder，决定产品的各个部分的build的过程。替换相应的builder子类，就可以修改产品相应的各个part部件的实现；替换相应的Director子类，就可以修改builder组件的调用顺序（即控制创建过程）。

工厂方法，产品子类和creator子类一 一对应。不直接调用FactoryMethod操作，定义了何时调用FactoryMethod。扩展相关子类可以修改此调用时间

Prototype，产品自身就是自己的creator

Singleton，产生全局的单一实例

1）以上是创建型：创建型设计模式核心是通过替换直接调用new创建具体对象这种方式，从而去client代码和产品对象之间的耦合。client都是通过接口引用工厂，通过接口引用产品，所以替换更方便。

adapter，描述了client如何做到通过target接口，来使用Adaptee的操作函数。

bridge，“抽象接口定义”和“具体实现部分”分离。分离后，可以各自发展。

composite，从共同接口派生，使对单个对象和组合对象的使用具有一致性，并且支持递归组合。

Decorator，共同的父类，接口相同，可以透明的、递归的增加额外的职责。与composite区别是只有一个组件。与strategy区别是Decorator修饰component的外观，strategy提取分离component的内部策略实现。

fa?ade，分层的概念中，层与层之间提供统一、集中的接口。
使不同层的对象不会出现网状交织。这样各层可以独立发展。fa?ade对象承担上层请求转发给下层对应对象。

flyweight，分离对象的内部、外部状态，使得大量细粒度对象可以共享，节省存储空间

proxy，proxy是Realsubject接口的子集或者相同接口，从而代替Realsubject。proxy来控制Realsubject，而不是client直接控制和访问Realsubject。这样proxy可以对Realsubject进行各种额外的控制。

2）以上是结构性模式。

chain of responsibility，每个在链上的对象都有一致的处理请求和访问链上后继者的接口。链式传递请求，使得请求的发送者和接收者解耦。
直到某个处理

command，把请求封装为一个command对象，虽然抽象的接口一致，但是可以派生各种command子类。command对象中包含了对接收者的引用、和调用接收者的一系列操作，通过动态创建command子类对象以及创建时传入不同的接收者引用，可以达到动态配置（参数化）请求的目的。进而实现上下文相关的菜单。Command模式将调用操作的对象与知道如何实现该操作的对象解耦。增加新的Command变得很容易。

interpreter，解释器和文法表示分开。定义一种文法，定义一个解释器用抽象语法树辅助解释文法。同样的接口派生而来，以便递归组合，实现抽象的语法树。

iterator，将对聚合对象的“访问和遍历”从聚合对象中分离出来，并放入到一个iterator对象中。对client隐藏了composite的内部组织。

Mediator，控制和协调一组对象间的交互，对象只跟中介相连，对象间不直接相连，从而减少连接数。方便对象独立发展。

Memento，向originator请求一个保存了内部状态的Memento，后面需要恢复时，传回此Memento给Originator，从而Originator恢复回之前状态，并且不保留Originator的内部细节

observer，subject状态改变时，通知各个observer。两者独立发展，通过抽象接口调用，减少两者耦合。

state，把各个行为封装在接口一致的各个状态对象中，所以改变状态时，行为得到改变。并且把请求委托给他的状态对象来处理。state模式将与“特定状态”相关的行为局部化，并且将不同状态的行为分割开来。

strategy，物理结构和算法分离，算法封装在一个独立对象中。

template method，定义算法骨架，但一些具体实现由子类定义。把公共的操作过程，做成模板

visitor，对象中包含多个不同接口类型的子对象。访问操作封装为独立对象。结构对象和操作对象分离

3）以上是行为型模式。

对设计模式有兴趣的话，更详细的总结，可看我的ppt。

或者请参考《设计模式：可复用面向对象软件的基础》一书
英文版《Design Patterns: Elements of Reusable Object-Oriented Software》

另外我的相关培训视频请看：
欢迎观看我发布的各个课程： https://edu.51cto.com/lecturer/8896847.html