1.重新认识面向对象
1）理解隔离变化：从宏观层面来看，面向对象的构建方式更能适应软件的变化，将变化所带来的影响减为最小；
2）各司其职：从微观层面来看，面向对象更强调各个类的责任；由于需求变化导致的新增类型不应该影响原来类型的实现；
3）对象是什么：从语言实现层面来看，对象封装了代码和数据；从规格层面讲，对象是一系列可被使用的公共接口；从概念层面讲，对象是某种拥有责任的抽象。
2.面向对象设计原则
1 依赖倒置原则（DIP：Dependence Inversion Principle）
1）高层模块（稳定）不应该依赖低层模块（变化），二者都应该依赖于抽象（稳定）；
2）抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象。
理解：一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。
例子：在上篇随笔中，关于Line和Rect的绘制实现上，分解方案MainForm依赖于Line和Rect，这是不符合DIP原则的，其中MainForm是高层模块，Line和Rect是低层模块；而在抽象方案中MainForm依赖于抽象类Shape，不依赖于Line和Rect，Shape比较稳定，Line和Rect也依赖于较稳定的Shape。
2 开放封闭原则（OCP：Open Closed Principle）
1）对扩展开放，对更改封闭
2）类模块应该是可扩展的，但是不可修改
理解：在 遇到变化时，尝试增加一些东西解决问题，而不是改变原有东西，这里的增加(扩展)和改变的具体意思得心领神会。
例子：在上篇随笔中，关于Line和Rect的绘制实现上，当增加圆的绘制时，分解方案要修改MainForm的代码，并且增加Circle类，没有遵循OCP原则；而在抽象方案中只增加了Circle类(扩展)，没有修改，遵循了OCP原则。
3 单一职责原则（SRP：Single Responsibility Principle）
1）一个类应该仅有一个能引起它变化的原因；
2）变化的方向隐含着类的责任
理解：一个类，只有一个引起它变化的原因，应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起，这会导致脆弱的设计。
4 Liskov替换原则（LSP：Liskov Substitution Principle）
1）子类必须能够替换它们的基类（IS-A）；
2）继承表达类型抽象；
理解：任何基类可以出现的地方，子类一定可以出现；只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用；
5 接口隔离原则（ISP：Interface Segregation Principle）
1）不应该强迫客户程序依赖它们不用的方法；
2）接口应该小而完备；
理解：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应建立在最小的接口上。
6 优先使用对象组合，而不是类继承
1）类继承通常为“白箱复用”，对象组合通常为“黑箱复用”；
2）继承某种程度上破环了封装性，子类基类耦合度高；
3）对象组合只要求被组合的对象具有良好定义的接口，耦合度低；
理解：继承和组合都能达到一个代码复用的效果，我们在使用继承的时候同时也就拥有了基类中的保护成员，增加了耦合度。而对象组合就只需要在使用的时候接口稳定，耦合度低。
7 封装变化点
1）使用封装来创建对象之间的分解层，让设计者可以在分解层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合；
理解：找到变化点，隔离稳定与变化
8 针对接口编程，而不是针对实现编程
1）不将变量类型声明为某个特定的具体类，而是声明为某个接口。
2）客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
3）减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。
理解：和依赖倒置原则是相辅相成的。接口标准化是产业强盛的标志。
例子：
vector<Shape*> shapeVector;
//用上面的代替下面的
vector<Line> shapeVector;
vector<Rect> shapeVector;
vector<Circle> shapeVector;
参考：《李建忠C++设计模式》视频
https://www.bilibili.com/video/BV1DT4y1R7sA?p=2
转载：https://www.cnblogs.com/gql-live-laugh-love/p/11568916.html
