设计模式（一）
特点：可复用的面向对象软件
底层思维 设计者 抽象思维语言构造 面向对象
编译转换 组件封装
内存模型 设计模式
运行状态 架构模式
封装：隐藏内部实现
继承：复用现有代码
多态：改写对象行为
复杂性问题解决：
分解：
分而治之，将大问题转为小问题，复杂问题分解多个简单问题
抽象：
层次更高，处理复杂性有个通用的技术
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
不应该强迫客户程序依赖它们不用的方法
接口应该小而完备
优先使用对象组合，而不是类继承
组合：在一个类中定义另外一个类
继承在某种程度上破坏了封装性，子类父类耦合度高
对象组合则要求被组合的对象具有良好定义的接口，耦合性低
封装变化点
使用封装来创建对象之间的分解层，让设计者可以在分界一侧进行修改，不会对另外一侧产生不良影响
一侧变化； 一侧稳定
针对接口编程，而不是针对实现编程
不将变量类型声明为某个特定的具体类，而是声明为某个接口
客户程序无需获知对象的具体类型，只需要知道对象的接口
减少系统中各部分的依赖关系，从而实现“高内聚，低耦合”
接口标准化