顺口溜记23种设计模式
在学习设计模式的时候，发现有23种之多。记忆起来十分困难，所以编一个顺口溜是不错的方法。当然死记还是不够的，但是要记死，重在理解和灵活运用。
迪厅里开口赖单
三厂建造单原型
组装适代享外桥
迭代策略告命状
观模忘访责中解
原则：迪米特法则，里氏替换法则，开放封闭法则，接口隔离法则，依赖倒置法则，单一职责法则
三厂:简单工厂，工厂方法，抽象工厂模式。建造者模式。单例模式，原型模式。5个 简单工厂不算
组合模式；装饰器模式；适配器模式；代理模式；享元模式；外观模式；桥接模式。7个
迭代器模式；策略模式；命令模式；状态模式。4个
观察者模式；模板方法模式；备忘录模式；访问者模式；责任链模式；中介者模式；解释器模式。7个
观察这些模式，其实是引入接口后，在处理对象，或者说类之间的关系。
1.构建型 是在看如何构造对象，在哪里构造对象，如何缓存对象，比如对象池。
2.结构型可以看作是如何组织对象形成数据结构。
3.行为型主要封装了一些逻辑处理流程，可以看作是算法封装。
对象与对象之间的关系：
A继承B.
A中包含1个B.
A中包含多个B.
A引用B. A和B相互引用。
A的构建器方法参数中包含了B.
A的普通成员方法参数中包含了B.
还能找到其他的两个对象交互的方法吗？以上本质都是对象之间的耦合。
A可以能过消息队列C访问B. 这种A和B不是紧耦合。但是此处涉及到了A,B,C的三元关系。我们拆分成A与C,C与B两个二元关系看待。
C++与设计模式
构建型
建造者模式builder 构建复杂对象的细节
流式接口(builder().set_name().set_age().....), 类里定义个static create,返回builder. Groovy-style 可以用C++initializer初始化列表语法来实现。一个builder中可以返回子builder.
工厂模式：factory，一行代码创建复杂对象，解耦对象使用与创建
工厂方法(在类里添加个静态Create(), New来创建对象，或者使用std::function调用来创建对象）、单独一个工厂类来创建(好处，可以实现单例，cache,对象池). 抽象工厂，Create是个纯虚函数，由子类具体实现，有产品族才会用到。
原型模式：proto 一个原型，复制后修改
copy constructor, 序列化(boost::serialization::access,boost::archive::text_oarchive)
与工厂模式结合，隐藏细节。
单例模式
静态全局变量
静态成员变量，私有构造函数，删除copy constructor和operator=
静态方法中的静态变量new或者不new
线程安全C++11. double check
IoC容器： boost.DI
成员变量全静态，不同对象其他用了同一份数据
缺点：到处用单例，单元测试的时候想mock比较困难。单例还是传入吧
结构型设计模式
继承，组合，聚合
聚合，组合，继承的区别_OnlyGky的博客-CSDN博客_组合 继承 聚合
- 继承：is a
- 组合：contain a.整体与部分生命周期相同
- 聚合：has a 部分可以脱离整体有独立的生命周期
适配器模式
把一个接口转成另一种接口。可以继承老接口的实现。也可以持有老接口的对象
桥接模式
pimpl idom
class Person {
public:
void greet();
private:
class PersonImpl;
PersonImpl *impl;
};优点：
- 隐藏了Person的实现细节
- 升级更新PersonImpl,接口不变。在Impl里添加数据成员，二进制兼容
- Person这个.h文件中不用包含过多的其他头文件
- 加快编译速度
桥接模式解决继承类数据爆炸问题
比如奶茶有大杯，小杯，中杯。同时还有多糖，少糖，无糖。如果用继承解决得3*3=9个类。
桥接可以把杯子大小这个维度抽象成接口，糖多少抽象成接口。定义个奶茶类，构造函数里传入这两个类接口。
以后不管新加杯子大小类型或者糖多少类型，都可以独立变化。
组合模式
类似文件系统的目录，目录下可以有文件也有目录。非常游戏中GameObject上挂载各种组件，技术，buff等等
领域驱动设计DDD
消除领域专家+软件开发人员之间的沟通障碍，歧义
由限界上下文中的一些特定概念词汇构成的语言叫通用语言。
绝不在限界上下文中使用基础概念。
不同限界上下文中可能使用相同的词表示不同的含义。
领域，子域，核心域，支撑子域，通用子域
实体：有唯一ID,进行添加，删除，修改操作
领域服务：处理多个实体+值对象
领域事件
目录结构 领域模型：com.company.限界上下文.domain.model.XXX 相关抽象接口也要放在这里
目录结构 领域服务：com.company.限界上下文.domain.Service.XXXService 相关抽象接口也要放在这里
目录结构 应用层：com.company.限界上下文.application.xxx 相关抽象接口也要放在这里
聚合中包含了一个事务中所有且最小的数据。 自已有ID,通过id引用其他实体。而不是直接通过对象指针
事务放在业务层去保证
不同界限上下文之间最好通过消息，事件，发布，订阅关联或者RESTFult接口。少用rpc直接访问。
不要在一个界限上下文直接使用另一个界限上下文中对象。最好有防腐层隔离+对象转换(端口适配，转为内部领域对象)
防腐层接口定义在领域模型内部，实现定义在基础设施层
端口适配器：ResttulHTTP接口 -> 应用程序 -->领域服务