设计模式（一）

特点：可复用的面向对象软件

底层思维							设计者						抽象思维语言构造													  面向对象
编译转换													  组件封装
内存模型													  设计模式
运行状态													  架构模式

封装：隐藏内部实现

继承：复用现有代码

多态：改写对象行为

复杂性问题解决：

分解：

​ 分而治之，将大问题转为小问题，复杂问题分解多个简单问题

抽象：

​ 层次更高，处理复杂性有个通用的技术

tips:vector<Line> shapeVector;		// 没有用到多态性，不需要使用指针，对象即可vector<Shape*> shapeVector;		// 用到了多态，需要指针

设计原则

依赖倒置

高层模块(稳定)不依赖底层模块(变化)； 二者都应该依赖于抽象

抽象(稳定)不依赖于实现细节(变化)； 实现细节应该依赖于抽象

MainForm ---- -> Line
MainForm ----- -> Rectangleline 和 Rectangle是变化的，可能后面需要各种形状；而MainForm主窗口是稳定的；
稳定的 不应该依赖于  变化的； 这种设计是不行的

MainForm -> Shape (抽象)
Line -> Shape (抽象)
Rectangle -> Shape (抽象)现在调整为MainForm依赖于稳定的Shape； Shape是稳定的；
line rectangle等变化的形状依赖于稳定的shape；这样设计是ok的

key：如果出现稳定的 依赖于 变化的； 需要将稳定的抽象出一个类；让变化的 ->依赖于抽象的；

开放封闭原则OCP

对扩展开放，对更改封闭

类模块应该是可扩展的，但是不可修改

单一职责原则SRP

一个类应该仅有一个引起变化的原则

变化的方向隐含着类的责任

里氏替换原则

子类必须能够替换它们的基类 is - A

继承表达类型抽象

接口隔离原则ISP

不应该强迫客户程序依赖它们不用的方法

接口应该小而完备

优先使用对象组合，而不是类继承

组合：在一个类中定义另外一个类

继承在某种程度上破坏了封装性，子类父类耦合度高

对象组合则要求被组合的对象具有良好定义的接口，耦合性低

封装变化点

使用封装来创建对象之间的分解层，让设计者可以在分界一侧进行修改，不会对另外一侧产生不良影响

一侧变化； 一侧稳定

针对接口编程，而不是针对实现编程

不将变量类型声明为某个特定的具体类，而是声明为某个接口

客户程序无需获知对象的具体类型，只需要知道对象的接口

减少系统中各部分的依赖关系，从而实现“高内聚，低耦合”

接口标准化