设计模式(Design Patterns)的简单讲解
- 模式的诞生与定义
- 模式(Pattern)起源于建筑业而非软件业(小本本记下来～～)
- 模式之父--美国加利佛尼亚大学环境结构中心研究所所长Christopher Alexander博士;
- 模式 ：
-Context（模式可适用的前提条件）
-Theme或Problem（在特定条件下要解决的目标问题）
-Solution（对目标问题求解过程中各种物理关系的记述） - 模式是在特定环境下人们解决某类重复出现问题的一套成功有效的解决方案（简单来说就是为了减少工作量）。
- 程序设计的最大的特点： 变化 因为环境、设备、用户的需求等原因， 导致程序经常发生变化
- 基本结构
- 设计模式的定义：一套被反复使用的，多数人知晓的，经过分类遍目的、代码设计经验的总结，使用设计模式是为了可重复使用代码，让代码更容易被他人理解并且提高代码的可靠性(目的)。设计模式是一种对软件系统中不断重复出现的设计问题的解决方案进行文档化的技术，也是一种共享专家设计经验的技术。
- 基本要素 ：模式名称(Pattern Name)、问题(Problem) 、解决方案(Solution)、效果(Consequences)
- 设计模式的分类
- 根据目的（模式是用来做什么的）：可分为创建型(Creational)，结构型(Structural)和行为型(Behavioral)三类
- 根据范围，即模式主要是处理类之间的关系还是处理对象之间的关系，可分为类模式和对象模式两种：
- 类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是一种静态关系
- 对象模式处理对象间的关系，这些关系在运行时变化，更具动态性
- GoF设计模式
- “四人组(Gang of Four，GoF，分别是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides)”于1994年归纳发表了23种在软件开发中使用频率较高的设计模式，旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟。
创建型模式（关注对象的创建过程，对类的实例化过程进行抽象，描述如何将对象的创建和使用分离）
抽象工厂模式(Abstract Factory) ★★★★★
建造者模式(Builder) ★★☆☆☆
工厂方法模式(Factory Method) ★★★★★(GoF 之外：简单工厂模式)
原型模式(Prototype) ★★★☆☆
单例模式(Singleton) ★★★★☆结构型模式(关注如何将现有类或对象组织在一起形成更加强大的结构)
适配器模式(Adapter) ★★★★☆
桥接模式(Bridge) ★★★☆☆
组合模式(Composite) ★★★★☆
装饰模式(Decorator) ★★★☆☆
外观模式(Facade) ★★★★★
享元模式(Flyweight) ★☆☆☆☆
代理模式(Proxy) ★★★★☆行为型模式(关注系统中对象间的交互，研究系统在运行时对象之间的相互通信与协作进一步明确对象的职责)
职责链模式(Chain of Responsibility) ★★☆☆☆
命令模式(Command) ★★★★☆
解释器模式(Interpreter) ★☆☆☆☆
迭代器模式(Iterator) ★★★★★
中介者模式(Mediator) ★★☆☆☆
备忘录模式(Memento) ★★☆☆☆
观察者模式(Observer) ★★★★★
状态模式(State) ★★★☆☆
策略模式(Strategy) ★★★★☆
模板方法模式(Template Method) ★★★☆☆
访问者模式(Visitor) ★☆☆☆☆
- 常用面向对象设计的原则
- 单一职责原则(Single Responsibility Principle, SRP)| ★★★★☆ : 一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中
- 另一种定义方式：就一个类而言，应该仅有一个引起它变化的原因。简单而言，就是一个类如果职责越多，那么它被复用的可能性就越低。即这个类中一个职责变化，可能会影响到其他的职责的运作。因此，单一职责原则就是实现高内聚，低耦合，将一个类的职责降低到最小，即类的数目很多，类中职责很少，因而类被复用的可能性被提高。
- 开闭原则(Open-Closed Principle,OCP) | ★★★★★ : 软件实体应当对扩展开放，对修改关闭
- 开闭原则是复用设计的第一块基石。在软件实体中应在尽量不修改原有代码的情况下进行扩展
- 里氏代换原则(Liskov Substitution Principle,LSP)| ★★★★★ : 所有引用基类的地方必须能透明地使用其子类的对象
- 在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何的错误和异常，反之不成立。例如：我喜欢动物，那么我一定喜欢狗，因为狗是动物的子类，反之不成立
- 依赖倒转原则(Dependence Inversion Principle,DIP) | ★★★★★ : 高层模块不应该依赖低层模块，它们应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象
- 要针对接口编程，不针对实现编程。一个具体类应当只实现接口或抽象类中声明过的方法，而不给出多余的方法，否在无调用到在子类中增加的新方法
- 接口隔离原则(Interface Segregation Principle,ISP)| ★★☆☆☆ : 客户端不应该依赖那些它不需要的接口
- 当一个接口太大时，将它分割成一些更细小的接口，使用该接口的客户端只要知道与之相关的方法即可
- 合成复用原则(Composite Reuse Principle,CRP)| ★★★☆☆:优先使用对象组合，而不是继承来达到复用的目的
- 在一个新的对象里通过关联关系(包括组合和聚合关系)来使用一些已有的对象，使之成为新对象的一部分，新对象通过委派调用已有对象的方法达到复用功能的目的
- 迪米特法则(Law of Demeter,LoD)| ★★★☆☆ : 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位
- 又称最少知识原则，一个软件实体应尽可能少地与其他类发生相互作用
- 设计模式的优点
- 融合了众多专家的经验，并以一种标准的形式供广大开发人员所用
- 提供了一套通用的设计词汇和一种通用的语言，以方便开发人员之间进行沟通和交流，使得设计方案更加通俗易懂
- 让人们可以更加简单方便地复用成功的设计和体系结构
- 使得设计方案更加灵活，且易于修改
- 将提高软件系统的开发效率和软件质量，且在一定程度上节约设计成本
- 有助于初学者更深入地理解面向对象思想，方便阅读和学习现有类库与其他系统中的源代码，还可以提高软件的设计水平和代码质量
- 设计模式的缺点
- 要说缺点的话，每一种都有它适用的地方和不适用之处，若使用不当，缺点往往会暴露的很明显。因此，学习到位，理解透彻，运用的多了，自然懂得如何扬长避短了，因而模式的缺点就尽可能的最小化了