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

你可能感兴趣的:(设计模式)