关于设计模式:设计模式概述

设计模式（Design pattern）代表了最佳的实际，通常被有教训的面向对象的软件开发人员所采纳。设计模式是软件开发人员在软件开发过程中面临的个别问题的解决方案。这些解决方案是泛滥软件开发人员通过相当长的一段时间的试验和谬误总结进去的。

以后遇到的问题，绝大多数都是前人曾经踩过的坑，他们总结了一系列“套路”，来解决各种各样的问题。这些套路能够被重用，从而使得代码更容易被了解和拓展，并保障代码的可靠性。

就像是练武，只会一些拳脚功夫是不够的，还须要成体系的文治秘籍来死记硬背。这套文治秘籍会通知你遇到什么样的敌人应该应用什么招式，也会通知你应该如何去做才不至于走火入魔。
设计模式的重要性显而易见，懂的都懂，学就完事了。

经典的设计模式一共有 23 种 (当然还有其余一些模式)，这些设计模式 依据目标 能够被分为三大类：

这些设计模式提供了一种在创建对象的同时暗藏创立逻辑的形式，而不是应用 new 运算符间接实例化对象。这使得程序在判断针对某个给定实例须要创立哪些对象时更加灵便。

单例模式：
工厂办法模式：
形象工厂模式：
建造者模式：
原型模式：

这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象取得新性能的形式。

代理模式：
适配器模式：
桥接模式：
装璜器模式：
外观模式：
享元模式：
组合模式：

这些设计模式特地关注对象之间的通信。作用于类或对象之间相互协作共同完成单个对象无奈独自实现的工作，以及怎么调配职责。

责任链模式：
命令模式：
解释器模式：
迭代器模式：
中介者模式：
备忘录模式：
观察者模式：
状态模式：
策略模式：
模板办法模式：
访问者模式：

对于一个类而言，应该只有一个引起它变动的起因。

也就是说，一个类只负责一个性能，不能因为每次引入新性能，都要去批改这个类，除非是这个类自身产生了扭转。

一个软件实体该当对扩大凋谢，对批改敞开

也就是说，尽量通过继承抽象类或者实现接口的形式来进行性能加强，而不是间接对原有代码进行批改。

所有援用基类（父类）的中央必须能通明地应用其子类的对象。

也就是说，应该可能把应用父类的中央，间接替换成子类。
这就要求尽量把父类设计为抽象类或者接口，且不要去重写父类中的办法，使其性能在所有子类中都雷同。

高层模块不应该依赖低层模块，两者都应该依赖其形象；形象不应该依赖细节，细节应该依赖形象。

也就是说，要面向接口编程，不要面向实现编程。

应用多个专门的接口，而不应用繁多的总接口，即客户端不应该依赖那些它不须要的接口。

也就是说，接口也是须要繁多职责的，不要把不相干的办法都申明在一个接口中，否则类就得实现这些它并不关怀的办法。

一个软件实体该当尽可能少地与其余实体产生相互作用。

也就是说，通过引入一个正当的第三者来升高现有对象之间的耦合。
每个类的成员变量和办法，能不 public 就不 public，防止被随便援用。

1. 设计模式概述