C++设计模式的设计原则

设计模式都是基于设计原则衍生而来的，不要求完全掌握全部设计模式，但要求精通理解八大设计原则，从而直接掌握全部设计模式或设计出自己的设计模式

1. 依赖倒置原则(DIP)：

高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定)
抽象(稳定)不应该依赖于实现细节(变化)，实现细节应该依赖于抽象(稳定)

举例：
人有一个技能为喝水，水杯有个技能为装水，那么水杯（Cup）这个类依赖于（人）这个类，只有人才能给水杯倒水。人调用Cup中的fillWater（）方法。这里的Man类与Cup类都是对象级依赖，这样以来的缺点就是耦合度很高。假如有一天Man换了一个新水杯（newCup）那么，之后Man还需要学习怎么使用这个新水杯（newCup），所以就会很麻烦。

如果使用依赖倒置原则，例如使用依赖倒置原则的好处就是，假如有一天小李不是用原来那个水杯喝水了，假如某天小王要借用小李的水杯，只需要调用接口来就可以了。可以看见类图中的人接口（IMan）和水杯接口（ICup）。这样耦合度就很低了。

2. 开放封闭原则(OCP)：

对扩展开放，对更改封闭
类模块应该是可扩展的，但是不可修改
举例：在厂家需要生成木板的时候，前期已经生产好一批木板，但后面因更改需求需要生产防火的木板，那我们不可能把已生产好的木板全部销毁，而可以在木板外涂一层防火涂料，这样就符合OCP原则。

3. 单一职责原则(SRP)：

一个类应该仅有一个引起它变化的原因
变化的方向隐含着类的责任

4. Liskov替换原则(LSP)：

子类必须能够替换它们的基类(是is - a的关系)。如果A是B的父类，所有需要父类的地方，那么B都必须要可以传过去使用
继承表达类型抽象

5. 接口隔离原则(ISP)：

不应该强迫客户程序依赖它们不用的方法
接口应该小而完备。所谓小，尽量不要把不必要的方法都public出去，如果只是子类使用的话就protected，如果是本类使用的话就private

6. 优先使用对象组合，而不是类继承原则(FOCP)：

类继承通常为“白箱复用”，对象组合通常为“黑箱复用”
继承在某种程度上破坏了封装性，子类父类耦合度高。像父继承爷、子继承父，这些是非理想的继承，理想的继承应该是类属关系；比如说，父继承人类、人类继承生物；SUV继承汽车、汽车继承交通工具等
而对象组合原则只要求被组合的对象具有良好定义的接口，耦合度低

7. 封装变化点原则(ECP)：

使用封装来创建对象之间的分界层，让设计者可以在层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合

8. 针对接口编程，而不是针对实现原则(FIP)：

不将变量类型声明为某个特定的具体类，而是声明为某个接口，这是非绝对化的，主要针对业务
客户程序无需获知对象的具体类型，只需要知道对象所具有的接口
减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案

C++设计模式总结 - 23种合集

组件协作

现代软件专业分工之后的第一个结果是“框架与应用划分”、“组件协作”模式通过晚期绑定来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。
1. Template模式(模板模式)
2. Strategy模式(策略模式)
3. Observer模式(观察者模式)

单一职责

在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。这里并不是说其他模式无职责，只不过下面这两个模式的职责问题比较突出。
4. Decorator模式(装饰模式)
5. Bridge模式(桥模式)

对象创建

通过“对象创建”模式绕开new，来避免对象创建(new)过程中所导致的紧耦合(依赖具体类)，从而支持对象创建的稳定。它是接口抽象之后的第一步工作。
6. Factory模式(工厂模式)
7. Abstract Factory模式(抽象工厂)
8. Prototype模式(原型模式)
9. Builder模式(构建器)

对象性能

面向对象很好地解决了 “抽象” 的问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。
10. Singleton模式(单例模式)
11. Flyweight模式(享元模式)

接口隔离

在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题，甚至根本无法实现。采用添加一层间接(稳定)接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。
12. Facade模式(外观模式/门面模式)
13. Proxy模式(代理模式)
14. Mediator模式(中介者模式)
15. Adapter模式(适配器)

状态变化

在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？ “状态变化” 模式为这一问题提供了一种解决方案。
16. Memento模式(备忘录模式)
17. State模式(状态模式)

数据结构

常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件的复用。这时候，将这些特定数据结构封装在内部，在外部提供统一的接口，来实现与特定数据结构无关的访问，是一种行之有效的解决方案。
18. Composite模式(组合模式)
19. Iterator(迭代器)
20. Chain of Resposibility(职责链)