设计模式
1概述
设计模式：设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
本教程将通过 Java 实例，一步一步向您讲解设计模式的概念。
设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。
什么是 GOF（四人帮，全拼 Gang of Four）？
在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书，该书首次提到了软件开发中设计模式的概念。
四位作者合称 GOF（四人帮，全拼 Gang of Four）。他们所提出的设计模式主要是基于以下的面向对象设计原则。
- 对接口编程而不是对实现编程。
- 优先使用对象组合而不是继承。
设计模式的使用
设计模式在软件开发中的两个主要用途。
开发人员的共同平台
设计模式提供了一个标准的术语系统，且具体到特定的情景。例如，单例设计模式意味着使用单个对象，这样所有熟悉单例设计模式的开发人员都能使用单个对象，并且可以通过这种方式告诉对方，程序使用的是单例模式。
最佳的实践
设计模式已经经历了很长一段时间的发展，它们提供了软件开发过程中面临的一般问题的最佳解决方案。学习这些模式有助于经验不足的开发人员通过一种简单快捷的方式来学习软件设计。
设计模式的类型
根据设计模式的参考书 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 中所提到的，总共有 23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。
| 序号 | 模式 & 描述 | 包括 |
| 1 | 创建型模式 | 工厂方法模式（Factory Method Pattern） 抽象工厂模式（Abstract Factory Pattern） 单例模式（Singleton Pattern） 建造者模式（Builder Pattern） 原型模式（Prototype Pattern） |
| 2 | 结构型模式 | 适配器模式（Adapter Pattern） 桥接模式（Bridge Pattern） 组合模式（Composite Pattern） 装饰器模式（Decorator Pattern） 外观模式（Facade Pattern） 享元模式（Flyweight Pattern） 代理模式（Proxy Pattern） |
| 3 | 行为型模式 | 责任链模式（Chain of Responsibility Pattern） 命令模式（Command Pattern） 解释器模式（Interpreter Pattern） 迭代器模式（Iterator Pattern） 中介者模式（Mediator Pattern） 备忘录模式（Memento Pattern） 观察者模式（Observer Pattern） 状态模式（State Pattern） 策略模式（Strategy Pattern） 模板方法模式（Template Method Pattern） 访问者模式（Visitor Pattern） |
抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
建造者：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
工厂方法：定义一个用于创建对象的接口，让子类决定将哪一个类实例化，工厂方法使一个类的实例化延迟到其子类。
原型：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
单例：保证一个类仅有有一个实例，并提供一个访问它的全局访问点。
适配器：将一个接口转换成为客户希望的另一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
桥接：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
组成：将对象组合成树形结构以表示“部分-整体”的层次结构，组合模式使得客户对单个对象和复合对象的使用具有一致性。
装饰：动态地给一个对象添加一些额外的职责。就扩展功能而言，装饰模式必生成子类方式更为灵活。
外观：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
享元：运用共享技术有效地支持大量细粒度的对象。
代理：为其他对象提供一个代理以控制对这个对象的访问。
下面用一个图片来整体描述一下设计模式之间的关系：
设计模式的六大原则
1、开闭原则（Open Close Principle）
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
应该在不修改现有代码的基础上，引入新功能。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即修改原有的代码对外部的使用是透明的。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
只要父类能出现的地方子类就能出现，并且将父类替换为子类时不会产生任何错误或异常。反过来就不行，有子类出现的地方，父类不一定能适应。
里氏替换原则的目的：规范继承时子类的书写规则，保持父类方法不被覆盖
从上面可以看出以下几点
里氏替换原则是针对继承而言的，
1.若子类继承父类是为了实现代码重用，那么父类的方法不能被子类重写，也就是父类方法应该保持不变。
2.若子类继承父类是为了实现多态，那么子类就会覆盖并重写父类的方法。在这个时候，我们应该将父类定义为抽象类，并定义抽象方法，这样做的目的是：抽象类是不能实例化的，因此不存在父类实例化的情况，也就不存在子类实例替换父类实例的情况。
总结：尽量不要从可实例化的父类中继承，而是要使用基于抽象类和接口的继承。这样就可以实现：对扩展（基于抽象）是开放的，对变更（基于具体）是禁止的
里氏替换原则包含了4层含义
- 子类必须完全实现父类的抽象类方法，但不能覆盖父类的非抽象类方法
- 子类可以有自己的个性
- 覆盖或实现父类的方法时，子类输入参数范围要相同或更宽松
- 覆写或实现父类的方法时，子类输出结果（返回值）范围要比父类相同或更严格
3、依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。这个原则的意思就是，代码要依赖于抽象，而不依赖于实现。
依赖倒置原则在程序编码中经常运用，其核心思想就是面向接口编程，高层模块不应该依赖低层模块(原子操作的模块)，两者都应该依赖于抽象。我们平时常说的“针对接口编程，不要针对实现编程”就是依赖倒转原则的最好体现：接口（也可以是抽象类）就是一种抽象，只要不修改接口声明，大家可以放心大胆调用，至于接口的内部实现则无需关心，可以随便重构。这里，接口就是抽象，而接口的实现就是细节。
如果不管高层模块还是底层模块，它们都依赖于抽象，具体一点就是接口或者抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他受到影响，这就使得无论高层模块还是低层模块都可以很容易地被复用。
依赖倒转原则其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计(说这句话可能不怎么好理解，再加上一句话就好理解了：面向对象的设计，出发点就是应对变化的问题)。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
包含三层含义：
一个类对另一个类的依赖应该建立在最小的接口上；
一个接口代表一个角色，不应该将不同的角色都交给一个接口，因为这样可能会形成一个臃肿的大接口；
不应该强迫客户依赖它们从来不用的方法。
接口隔离原则有点像单一职责原则，但是也有区别，在单一职责原则中，一个接口可能有多个方法，提供给多种不同的调用者所调用，但是它们始终完成同一种功能，因此它们符合单一职责原则，却不符合接口隔离原则，因为这个接口存在着多种角色，因此可以拆分成更多的子接口，以供不同的调用者所调用。比如说，项目中我们通常有一个Web服务管理的类，接口定义中，我们可能会将所有模块的数据调用方法都在接口中进行定义，因为它们都完成的是同一种功能：和服务器进行数据交互；但是对于具体的业务功能模块来说，其他模块的数据调用方法它们从来不会使用，因此不符合接口隔离原则。
5、迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
迪米特法则可以简单说成：talk only to your immediate friends。 又被解释为下面几种方式：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。
6、合成复用原则（Composite Reuse Principle）
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。
第一，继承复用破坏包装，它把父类的实现细节直接暴露给了子类，这违背了信息隐藏的原则；
第二：如果父类发生了改变，那么子类也要发生相应的改变，这就直接导致了类与类之间的高耦合，不利于类的扩展、复用、维护等，也带来了系统僵硬和脆弱的设计。而用合成和聚合的时候新对象和已有对象的交互往往是通过接口或者抽象类进行的，就可以很好的避免上面的不足，而且这也可以让每一个新的类专注于实现自己的任务，符合单一职责原则。
扫一扫
2561
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
