认识过程
- 仰视
- 简单
- 第一版demo
- 第二版demo + 思考 + 使用
遇到过的模式：
- spring 的工厂模式
- spring 的bean， 单例
- spring 的过滤器，责任链
- spring 的aop， 动态代理
- jdk 的IO流， 装饰
- servlet 的http请求， 模板方法
- react 的状态机， 状态
- 项目架构， face
设计模式六大原则
- 开闭
- 依赖倒置
- 里氏替换
- 迪特米
- 接口隔离
- 单一职责
面向对象， 面向接口；具体变化， 抽象不变；扩展开放， 修改关闭。
简单与复杂
- 简单：原理简单，接口 + 实现；内蕴共享
- 复杂：正确的场景正确得使用，与经验有关
设计模式的作用
- 内在作用：扩展开放， 修改关闭
- 外在作用：交流沟通
对各设计模式的理解
- 单例模式，没什么好说的，只得一提的是多线程中如何确保单例：
- java关键字synchronized（懒汉模式中要注意了）
- 单成员枚举类
- 原型模式，提到该模式第一个想到的就是clone，java中的原型械的是靠clone来实现的，其中又分：
- 浅clone
- 深clone（对象中的引用成员变量也会被clone）
- 工厂模式，工厂模式一共有三个：简单工厂，工厂方法， 抽象工厂。它们都由前一个模式抽象而来，并且通常简单工厂被认为是不符合开闭原则的（在不用反射时），而抽象工厂被认为是最抽象，最具普遍意义的同时也是最臃肿的工厂模式。工厂模式的使用有如下几个方面：
- 对象的创建不能直接用new 如：Spring
- 对象的构建参数稳定不变
- 建造者模式，与工厂模式同为创建型模式但它们侧重点完全不同：工厂模式侧重于直接提供可用的对象，而建造者模式侧重于复杂对象的构建过程或拼装过程。个人觉得建造者模式更有一种：分而治之的想思理念。
- 适配器模式，当使用的第三方工具所提供的功能接口与要求不符合时可以考虑使用。个人觉得：更像是一个补求方案。
- 桥接模式，当一个对象在不同的维度发生不同的变化时为了不生系统的类发生爆炸，应考虑使用桥接模式。问：如果一开始就预料到了多维度多变化，为什么不把每个维度抽象成接口？个人觉得：更象是一个补求方案。
- 组合模式，说白了就是一棵树。
- 装饰者模式,主要用于动态扩充类的功能，并且扩充对象之间可以形成一个链（个人觉得这点才是与策略模式最大的区别）。
- 外观模式，更像是一架构模式。
- 享元模式，将事务不变的部分定义为内蕴状态，变化的部分定义为外蕴状态。内蕴状态可以被得复使用从而达到节省内存的作用。
- 代理模式，无论动态代理，还是静态代理。核心功能还是核心类或对象还处理，将额外的功能处理交给代理。职责单一，结构清淅。
- 责任链模式，将连续的if-else判断封装到不同的类中成为一个节点，并让每个节点持有下一节点的引用形成一个链。spring中的过滤器。
- 命令模式，使用信命令将请求者与执行者解耦，并可以自定义“宏”命令。
- 解释模式，用得少，语言中用到······
- 迭代模式，java集合中迭代器，三个方法：haveNext（）； next（）； remove（）；链式结构！
- 观察者模式，被观察者的状态的改变可以及时通知被观察者，并拥有添加/删除观察者的接口。（1：n）
- 中介者模式，与观察者模式不同的是，它是（n：n）的关系。当系统中的一个对象的状态改变时，系统中的其它对象也需要作出相应改变。定义一个中介者封装对象与对象之间的交互行为，使得系统中原本呈现网状结构的对象关系，变为星型。
- 备忘录，好象用得也不多····
- 状态模式，一个对象的行为依赖于它所处的状态，于是将不同的状态所对应的行为分离并封装。
- 策略模式,没什么好说的了，最简单的一个了
- 模板方法，父类中定义整个算法框架，而将一些具体算法移交给子类。钩子方法！
- 访问者模式，当一个事务的组成结构相对稳定，但常常要定义添加针对这些组成结构的新的操作时，可以考虑使用访问者模式。不常用，破坏封装！
