设计模式简介
设计模式简介
设计模式（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）。当然，我们还会讨论另一类设计模式：J2EE 设计模式。
| 序号 | 模式 & 描述 | 包括 |
|---|---|---|
| 1 | 创建型模式 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。 | + 工厂模式（Factory Pattern）+ 抽象工厂模式（Abstract Factory Pattern）+ 单例模式（Singleton Pattern）+ 建造者模式（Builder Pattern）+ 原型模式（Prototype Pattern） |
| 2 | 结构型模式 这些模式关注对象之间的组合和关系，旨在解决如何构建灵活且可复用的类和对象结构。 | + 适配器模式（Adapter Pattern）+ 桥接模式（Bridge Pattern）+ 过滤器模式（Filter、Criteria 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）+ 空对象模式（Null Object Pattern）+ 策略模式（Strategy Pattern）+ 模板模式（Template Pattern）+ 访问者模式（Visitor Pattern） |
| 4 | J2EE 模式 这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。 | + MVC 模式（MVC Pattern）+ 业务代表模式（Business Delegate Pattern）+ 组合实体模式（Composite Entity Pattern）+ 数据访问对象模式（Data Access Object Pattern）+ 前端控制器模式（Front Controller Pattern）+ 拦截过滤器模式（Intercepting Filter Pattern）+ 服务定位器模式（Service Locator Pattern）+ 传输对象模式（Transfer Object Pattern） |
下面用一个图片来整体描述一下设计模式之间的关系：
设计模式的优点
- 提供了一种共享的设计词汇和概念，使开发人员能够更好地沟通和理解彼此的设计意图。
- 提供了经过验证的解决方案，可以提高软件的可维护性、可复用性和灵活性。
- 促进了代码的重用，避免了重复的设计和实现。
- 通过遵循设计模式，可以减少系统中的错误和问题，提高代码质量。
设计模式的六大原则
1、开闭原则（Open Close Principle）
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭
用抽象构建框架，用实现扩展细节
优点：提高软件系统的可复用性及可维护性
核心思想：面相抽象编程而不是面对具体软件实现，应当对修改关闭，对扩展开放
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
定义：如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有对象o1都替换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型
引申意义：子类可以扩展父类的功能，但不能改变父类原有的功能
含义1：子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
含义2：子类中可以增加自己特有的方法
含义3：当子类的方法重载父类的方法时，方法的前置条件（方法的输入、入参）要比父类的方法的输入参数更为宽松
含义4：当子类的方法实现父类的方法时（重写、重载或实现抽象方法），方法的后置条件（方法的输出、返回值）要比父类更严格或相等。
优点
- 约束继承泛滥，开闭原则的一种体现
- 加强程序的健壮性，同时变更时，也可以做到非常好的兼容性。提高程序的维护性、扩展性。降低需求变更时引入的风险。
3、依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
定义：用多个专门的接口，而不是用单一的总接口，客户端不应该依赖它不需要的接口
一个类对一个类的依赖应该建立在最小的接口上
建立单一接口，不要建立庞大臃肿的接口
尽量细化接口，接口中的方法尽量少
注意适度原则，一定要适度（如果方法过少，会造成接口过多）
优点：符合 我们常说的高内聚（减少对外的交互，使接口中最少的方法完成最多的事情）低耦合的设计思想
plain text 从而使得类具有很好的可读性、可扩展性和可维护性
5、迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
定义：一个对象应该对其他对象保持最少的了解，
强调只和朋友交流，不和陌生人说话。
出现在成员变量、方法的输入、输出参数中的类成为成员朋友类
而出现在方法内部的类不属于朋友类。
6、合成复用原则（Composite Reuse Principle）
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。
定义：尽量多的使用对象组合、聚合，而不是继承关系
聚合has-A和组合contains-A
优点：可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少
组合/聚合与继承的选择
7、单一职责原则
定义：不要存在多于一个导致类变更的原因
一个类/接口/方法只负责一项职责
优点：降低类的复杂度（一个类只负责一个职责）、提高类的可读性， 提高系统的可维护性、降低变更引起的风险