顺口溜记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接口 -> 应用程序 -->领域服务