下面是我对一些常用设计模式的理解：
模式分为：行为模式、对象模式、结构模式
- 构建者模式：为产品的创建提供了统一模板，而且可以使用创建者指挥器对产品的构建结构或顺序进行调整。
- 观察者模式：当一个事件发生，而去通知所有观察者状态改变。
- 工厂模式：简单工厂不支持开闭原则，而工厂方法不支持多产品族问题，抽象对于产品族扩展是不支持的。
- 适配器模式：把一种已有的接口适配为当前需要的接口类型，该模式是针对方法的一种设计模式。
- 单例模式：在一个系统中进存在一个实例的情况下使用单例模式。
- 桥模式：当一个事物将以多维度方向发展，为了跟好的支持不同维度的扩展而使用的，我理解桥接也是一种组合或聚合关系，也就是has-a的关系。
- 策略模式：策略模式其实就是一种面向接口编程的思想，而它不同的是面向接口方法编程的。
- 责任链模式：该模式类似于击鼓传花，如果不符合当前类的职责，那么就交给下一个处理，如果你把击鼓传花的代码写出来了，那么责任链模式也就出来了。
- 装饰模式：装饰模式个人感觉和责任链模式有点像，但他俩本质是不同的，装饰是类进行修饰（也就是添加功能），而责任链是判断是否为当前处理器的职责，如果是就处理不是就传给下个处理器。共同点都是一个链型结构的模式。
- 代理模式：可以结合现实中的代理商模式进行理解。除了替厂家卖东西，你还赚了钱可能还做了些小动作等等。代理是面向行为的，为行为进行了再次封装。
- 享元模式：理解还不透彻后续补上。
- 外观模式：外观模式讲的是为一组子系统提供更加便捷的一组接口，使子接口不去关心底层实现。
- 迭代器模式：这个没怎么看，我想应该讲的和java中的iterator迭代类似的吧。
- 状态模式：状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相应依赖。当一个对象的行为取决于他的状态，并且它必须在运行时刻根据状态来改变他的行为，这时就可以考虑使用状态模式了。-------需要继续理解
- 组合模式：需求中体现部分与整体层次结构时，希望用户可以忽略组合对象和单个对象的不同，统一使用组合对象结构中的所有对象时，就应该考虑组合模式。-------需要继续理解
- 构建者模式：为产品的创建提供了统一模板，而且可以使用创建者指挥器对产品的构建结构或顺序进行调整。
- 观察者模式：当一个事件发生，而去通知所有观察者状态改变。
- 工厂模式：简单工厂不支持开闭原则，而工厂方法不支持多产品族问题，抽象对于产品族扩展是不支持的。
- 适配器模式：把一种已有的接口适配为当前需要的接口类型，该模式是针对方法的一种设计模式。
- 单例模式：在一个系统中进存在一个实例的情况下使用单例模式。
- 桥模式：当一个事物将以多维度方向发展，为了跟好的支持不同维度的扩展而使用的，我理解桥接也是一种组合或聚合关系，也就是has-a的关系。
- 策略模式：策略模式其实就是一种面向接口编程的思想，而它不同的是面向接口方法编程的。
- 责任链模式：该模式类似于击鼓传花，如果不符合当前类的职责，那么就交给下一个处理，如果你把击鼓传花的代码写出来了，那么责任链模式也就出来了。
- 装饰模式：装饰模式个人感觉和责任链模式有点像，但他俩本质是不同的，装饰是类进行修饰（也就是添加功能），而责任链是判断是否为当前处理器的职责，如果是就处理不是就传给下个处理器。共同点都是一个链型结构的模式。
- 代理模式：可以结合现实中的代理商模式进行理解。除了替厂家卖东西，你还赚了钱可能还做了些小动作等等。代理是面向行为的，为行为进行了再次封装。
- 享元模式：理解还不透彻后续补上。
- 外观模式：外观模式讲的是为一组子系统提供更加便捷的一组接口，使子接口不去关心底层实现。
- 迭代器模式：这个没怎么看，我想应该讲的和java中的iterator迭代类似的吧。
- 状态模式：状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相应依赖。当一个对象的行为取决于他的状态，并且它必须在运行时刻根据状态来改变他的行为，这时就可以考虑使用状态模式了。-------需要继续理解
- 组合模式：需求中体现部分与整体层次结构时，希望用户可以忽略组合对象和单个对象的不同，统一使用组合对象结构中的所有对象时，就应该考虑组合模式。-------需要继续理解