上一篇总结了设计模式的八大原则，本质上是对所有具体设计模式特性的一个总结，其中最重要的是依赖倒置原则，这是设计模式的根本所在，基于这个原则我们可以将软件系统中的变化点（不稳定&底层实现）和不变点（稳定点&顶层架构）解耦，让整个软件系统更加能适应变化。这篇继续上一篇的总结，对每一个设计模式做一个概述，便于整体把握设计模式，也方便以后复习。
1. 设计模式的分类
1.1 GOF分类————根据目的分类
- 创建型：处理对象创建的问题
- 结构型：通过类继承或对象组合的方式创建灵活的结构
- 行为型：通过类继承或对象组合来划分类与对象的职责
1.2 从范围来看————根据实现手段分类
- 类模式处理类与子类的静态关系，偏继承
- 对象模式处理对象之间的动态关系，偏组合
1.3 从封装变化的角度分类
组件协作：模板方法，策略模式，观察者模式
单一职责：装饰器模式，桥模式
对象创建：工厂模式，抽象工厂模式，Prototype，建造者模式
对象性能：单例模式，享元模式
接口隔离：门面模式，Proxy，中介者模式，适配器模式
状态变化：Mement，State
数据结构：组合模式，迭代器模式，Chain Of Resposibility
行为变化：命令模式，Visitor
领域问题：Interpreter
2. 设计模式概述
这部分内容本来打算写每个模式的类图，但感觉参考这篇文章更加全面，这里只写一些自己觉得比较重要的模式的思考吧。
订阅者模式：通过在上下文类中维护一个订阅者类实例列表，在上下文出发特定状态时依次调用订阅者列表中实例的推送函数，以达到将上下文状态通知给订阅者对象的目的。
桥模式：一个上下文类对象可能包含不同维度的属性，如果每个维度的状态和方法都在这一个类中维护的话，类会变得越来越庞大。我们可以将不同属性单独创建类体系，然后再原来的类中用指针（等价于引用）来组合。这样不同属性的特定对象可以在运行时绑定，组合出很多属性不一样的上下文对象。
装饰器模式：解决两个类体系之间接口不兼容的问题，将被调类的接口进行二次封装，以适应主调类的接口。
工厂模式：按需生成对象
单例模式：是一个类只生产一个实例，为了性能或生成全局实例。
门面模式： 对复杂子系统的接口进行包装到一个类中作为接口类，适应context类调用逻辑，减少复杂度
中介者模式：减少对象之间的直接交互，从而降低对象之间的强依赖（耦合），通过一个中介类间接通讯。
代理模式：对一个目标类或子系统的接口封装到一个代理类中，以后对目标类或子系统的调用都通过代理类来调用，与门面和中介者非常相似，但代理模式的侧重点是封装的代理类中在执行目标类接口函数的上下文中再添加一些我们附加的功能。比如，我们拿到了一个已经封装好的第三方库机器接口头文件，我们可以直接调用接口，但是我们希望在调用接口之前之后执行一些检查或日志记录功能，那么如果这些检查和日志频繁使用的话，将其和第三方库接口封装到一个代理类中是一个明智之举。
访问者模式：访问者模式建议将新行为放入一个名为访问者的独立类中， 而不是试图将其整合到已有类中。 现在， 需要执行操作的原始对象将作为参数被传递给访问者中的方法， 让方法能访问对象所包含的一切必要数据。
3. 总结
以上对比较重要的一些设计模式大概写了一些总结，目前对很多设计模式的理解还是很形而上的，后续实践过程中慢慢体会吧。设计模式的学习暂时告一段落。总之，在写代码的时候要去思考如何设计才能松耦合，尽量去依赖抽象基类。
参考文献：
标签：总结,上下文,对象,模式,概述,接口,设计模式,类中 来源： https://www.cnblogs.com/lee-zq/p/16062062.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。