关于设计模式
1. 依赖倒置原则： 面向接口（抽象）编程， 上层 ==> 接口 <== 下层
2. 单一职责原则 ： 一个类负责一件事
3. 开放-封闭原则：对扩展开放，对修改关闭
4. 迪米特法则：没必要直接通信就不要通信（最小知识原则）
5. 外观模式：将复杂子系统接口进行整合，向客户端开放简单的接口，方便调用
6. 建造者模式：把对象创建的过程抽象出来（Builder），然后子类（XXXBuilder）实现，规范了对象创建的流程
感觉与模板方法模式、工厂方法模式有些类似
当复杂对象难以通过简单构造函数初始化时，可以考虑使用建造者模式，使用 Builder 构建
7. 观察者模式：通知者维护一个观察者（对象引用）列表，当事件发生时调用其对应方法通知观察者采取一定动作
主要是用到了回调机制，因为观察者和通知者种类可能会很多，最好都进行抽象，面向抽象接口编程
8. 状态模式：当在不同状态需要采取不同的处理方式时，
定义一个状态抽象类，各个具体状态类只关注本状态下的操作，包括状态的切换
例如，不同状态（时间点）下写程序是不一样的，则工作类不直接处理写程序，而是通过调用状态的写程序方法完成
将与状态有关的操作封装到具体的状态类中，简化了工作中写程序函数的复杂度
9. 适配器模式：跟装饰器模式比较像，但适配器模式的目的不是功能增强，而是使旧实现有新调用接口，
而且适配器类实现的抽象接口不一定是被适配的对象的抽象接口，而应该是调用者需要的抽象接口（target接口）
装饰器模式下，装饰器应该能够代替被装饰对象，因此需要实现被装饰对象的抽象接口
注意，接口不同时，应该优先考虑重构接口，无法解决时才用适配器
10. 原型模式：简单理解成对象克隆，无需关注实例化细节
11. 备忘录模式：将需要保存的状态信息交给单独的备忘录类封装，对象载入状态和存储状态仅针对该备忘录类编程
客户端就无需关注状态的具体内容了，它只知道备忘录就好了
例如，游戏角色保存状态和恢复状态，不是具体操作生命力等属性，而是操作角色状态存储箱
而角色状态存储箱交给角色状态管理者管理（get/set 角色状态存储箱），封装了细节
12. 组合：汽车和轮子的关系（紧密关系）
聚合：鸽子和鸽群（松散关系）
13. 组合模式：核心思想是，处理单个（部分）和处理多个（整体）的方法是一样的（比如 word 中文字加粗）
因为基于同一个抽象接口，子类遇到不应该支持的方法的时候，可以抛出 UnSupport 异常，
从而用统一接口，屏蔽差异
组合对象可以任意增加组合的复杂度，组成层次结构，而对于客户端来说处理方法都是一样的（相同抽象）
14. 迭代器模式：很多语言已经内置，遍历集合使用
15. 组合优先于继承，继承会增加耦合程度
使用继承应该是 is-a 的关系下才考虑的
16. 桥接模式：将抽象与实现分离，抽象把实现组合进来，通过操作实现完成功能
通过组合实现，就可以按需使用不同的实现完成功能了
比如：手机具有通讯录、MP3 功能的抽象，
具体实现上可以组合 通讯录 v1 和 MP3 v2，也可以组合 通讯录 v2 和 MP3 v1，十分灵活
17. 命令模式：相当于菜单，菜单记录了要做的事，厨师解析菜单制作即可，解耦了客户和厨师
菜单命令，包含着要做的菜和接收者（厨师），实现菜单命令抽象接口
服务员不关心怎么做，按照客户需求创造命令（菜单），调用菜单命令的抽象执行方法即可
接下来的任务就交给命令接收者厨师负责了
该模式使得请求能够支持存储、排队、撤销、恢复等功能！高并发下是不是可以用这个模式把请求排队呢？
18. 职责链模式：相当于过滤器链似的，每个处理 handler 都有后继，自己处理不了的交给后继节点处理
19. 中介者模式：相当于联合国，各国不需要直接交互，通过联合国交互即可
滥用中介者模式可能造成中介者太过复杂
20. 享元模式：运用共享技术有效地支持大量细粒度的对象，单例模式其实也可以看作是享元模式的一种具体案例
21. 解释器模式：类似于开发了一门新语言，解释器解释语言的含义
MP3 播放器解释 MP3 文件的含义，播放音乐
22. 访问者模式：使用独立的 visitor 处理自己的元素，而不是自己直接处理
这样在变更操作的时候，更换 visitor 就可以了