具体详见我的博客：（作业的码在博客最后）
design patterns
责任是思考面向对象设计的一个观点
从概念层面，对象是某种责任的抽象
面向对象设计原则
（设计原则比模式更重要）
1.依赖倒置原则(DIP）
高层模块（稳定）不应该依赖于底层模块（变化），二者都应该依赖于抽象（稳定）
抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）
2.开放封闭原则
对扩展看房，对更改封闭
类模块应该是可扩展的，但是不可修改
3.单一职责原则（SRP）
一个类应该仅有一个引起它变化的原因
变化的方向隐含着类的责任
4.Liskov替换原则（LSP）
子类必须能狗狗替换它们的基类（is-a）
继承表达类型抽象
5.接口隔离原则
不应该强迫客户端以来它们不用的方法
接口应该小而完备
6.优先使用对象组合，而不是类继承
is-a关系，其实感觉父子关系不是很恰当
继承通常为“白箱复用”，对象组合通常为“黑箱复用”
继承在某正程度上破坏了封装性，子类父类耦合度高
7.封装变化点
使用封装类创建对象之间的分界层，让设计者可以在分阶层一侧修改，而不会对另一侧产生不良的影响，从而实现层次见的松耦合
封装更高层次的理解是封装变化点
8.针对接口编程，而不是针对实现编程
不将变量声明为某个具体类，而是声明为某个接口(比如虚基类)
客户程序无需货值对象的具体类型，只需要知道对象的所有接口
减少守系统中各部分的依赖关系，从而实现“高内聚，松耦合“的类型设计方案
接口标准化，是产业强盛的标志
通过分工合作才能实现复用性
设计模式的要点在于寻找变化点，然后再变化点处应用设计模式
一上来就使用设计模式是对设计模式的最大勿用，Refactoring to patterns 是目前普片公认的最好的使用设计模式的方法
提到延迟一般是指定义一个虚函数让子类去实现（支持子类来变化）
假定run是稳定的
设计模式最大的作用是在稳定和变化中间寻找隔离点，然后分离他们，然后管理变化
将编译时转化为运行时
当两个类由相同的字段的时候，应该将它提到基类中
主体操作和拓展操作应该分开分值继承
工厂方法：
为了解决new依赖实现，我们需要一种方法返回一个对象
