介绍
创建者模式
单例模式
工厂模式
工厂中的具体实例化
结构型模式
外观模式
尽管解决方案很大，但是客户端仍然希望使用简化的界面与子系统进行交互。
外观不会增加更多功能，而外观只是充当子系统的入口点。
适配器模式
一个系统的输出可能与另一系统的预期输入不一致。
组成模式
多态性
代理模式
能够完成相同的任务，但是将请求委派给原始对象以实现它们。
推迟创建资源密集型对象，直到需要
远程系统的本地表示
保证安全性
装饰者模式
行为组合->新类，类的数目可能会过于多
一对一聚合。
堆栈聚合，顺序很重要！
使用时，我们需要继承抽象装饰器并使用具体装饰器类实现组件接口
行为模式
模板方法模式
模板方法模式定义了一个操作中算法的执行结构，而将一些子类之间不同的行为延迟到子类中定义。
职责链模式
将问题的解决者对象连接在一起。将request 传递下去。
但是，如果其中的一个解决者没有传递对象的话，就会产生问题。这里需要使用模板方法模式规定行为的发生顺序，至于每个解决者如何解决问题，延迟到子类中进行实现。
状态模式
当系统处于不同的状态，对不同的行为需要做出不同的反应时，我们往往需要使用很多的if-else条件分支。而使用状态模式，通过维持当前上下文的一个状态，由状态对发生的行为进行处理，而具体的实现在状态子类的对应方法中。通过这种方式就可以简化代码。
指令模式
指令模式将对象对另一个对象的方法调用封装为一个Command对象，这样就可以将方法的调用保存到队列中之后再规划执行。
中介者模式
通过中介者，将相互有联系的对象的交互逻辑限制在中介者中，从而让代码更加集中，减少对象之间的耦合，但是同样地，会降低内聚性，因此需要在二者之间做好平衡。
观察者模式
主要包含一个域、三个方法，方法分别为添加订阅者，删除订阅者，通知全部订阅者，通知是通过调用所有Observer的update方法实现的，因此所有的Observer类都要实现相同的接口。
MVC and Good/Bad Design
Code smell:
- Comments
- long methods
- not just getter and setter
- long parameter is bad, introduce parameter objects
- global variables which is also bad
Part2: code smells when you make changes to the code
- 如果一开始没有做到seperation of concerns, 会导致最终的divergent change.
- change to be localized
- 如果两个类总是频繁地进行交流，他们可能本就属于一处。
- message chains: makes code harder to test independly
- Switch Statements:
- Speculative Generality
- Refused Bequest: 拒绝馈赠