设计模式概述

港控/mmm° 2022-04-24 09:16 225阅读 0赞

## 前言 ##

我们应该都看过武侠小说吧，就算没有看过武侠小说，武侠电视剧应该也看过吧。在武侠小说或者电视剧里面存在一种争论，那就是“招式”重要还是“内功”重要。在这并不是分析张无忌的九阳神功和令狐冲的独孤九剑到底哪个更厉害，而是我想每个武林人士梦寐以求的应该是既有淋漓的招式又有深厚的内功吧。说到这，大家可能一脸问号，不是讲设计模式么？怎么扯到武功绝学上来了？别急，虽然是不同的事物，但是道理都是相通的。例如我们所熟知的`eclipse`、`idea`等开发工具，`spring`、`spring mvc`、`hibernate`、`mybatis`等开发框架，这些可以认为是“招式”，而数据结构、算法、设计模式、代码重构、性能优化等，这些可以认为是“内功”。招式可以  
很快学会，但是内功的修炼需要更长的时间和毅力，我想每一位软件开发人员肯定都希望成为一名内外兼修的高级软件工程师，而对设计模式的学习与领悟将会让你“内功”大增，再结合你熟练的“招式”，你的软件开发能力一定会上升一个台阶。

## 设计模式的前世今生 ##

我们先来认识一个人——Christopher Alexander（克里斯托弗.亚历山大），哈佛大学建筑学博士、美国加州大学伯克利分校建筑学教授、加州大学伯克利分校环境结构研究所所长、美国艺术和科学院院士……头衔真多，不过他还有一个“昵称”——模式之父(The father of patterns)。Christopher Alexander博士及其研究团队用了约20年的时间，对住宅和周边环境进行了大量的调查研究和资料收集工作，发现人们对舒适住宅和城市环境存在一些共同的认同规律，Christopher Alexander在著作A Pattern Language: Towns,Buildings, Construction中把这些认同规律归纳为253个模式，对每一个模式(Pattern)都从Context（前提条件）、Theme或Problem（目标问题）、 Solution（解决方案）三个方面进行了描述，并给出了从用户需求分析到建筑环境结构设计直至经典实例的过程模型。

在Christopher Alexander的另一部经典著作《建筑的永恒之道》中，他给出了关于模式的定义：每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地重用那些已有的成功的解决方案，无须再重复相同的工作。这个定义可以简单地用一句话表示：**模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案**。

最早将模式的思想引入软件工程方法学的是1991-1992年以“四人组(Gang of Four，简称GoF，分别是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides)”自称的四位著名软件工程学者，他们在1994年归纳发表了23种在软件开发中使用频率较高的设计模式，旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟。GoF将模式的概念引入软件工程领域，这标志着软件模式的诞生。软件模式(Software Patterns)是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件开发生命周期的每一个阶段都存在着一些被认同的模式。软件模式是在软件开发中某些可重现问题的一些有效解决方法，软件模式的基础结构主要由四部分构成，包括问题描述【待解决的问题是什么】、前提条件【在何种环境或约束条件下使用】、解法【如何解决】和效果【有哪些优缺点】。

在软件模式中，设计模式是研究最为深入的分支，设计模式用于在特定的条件下为一些重复出现的软件设计问题提供合理的、有效的解决方案，它融合了众多专家的设计经验，已经在成千上万的软件中得以应用。 1995年， GoF将收集和整理好的23种设计模式汇编成Design Patterns: Elements of Reusable Object-Oriented Software【《设计模式：可复用面向对象软件的基础》】一书。

从1995年至今，无论是在大型企业应用或软件框架（如Spring、Spring MVC、 Hibernate、mybatis等），设计模式都得到了广泛的应用。

## 什么是设计模式 ##

俗话说“站在别人的肩膀上，我们会看得更远”。设计模式的出现可以让我们站在前人的肩膀上，通过一些成熟的设计方案来指导新项目的开发和设计，以便于我们开发出具有更好的灵活性和可扩展性，也更易于复用的软件系统。

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

GOF设计模式分为23个，每个都各具特色，每个设计模式都是为了一个可重复的设计问题提供一套解决方案。

## 设计模式的分类 ##

设计模式主要分为三大类：

1.  创建型模式(Creational)：总共5种，用于描述如何创建对象  
    1.1. 单例模式(Singleton Pattern)  
    1.2. 简单工厂模式(Simple Factory Pattern)  
    1.3. 工厂方法模式(Factory Method Pattern)  
    1.4. 抽象工厂模式(Abstract Factory Pattern)  
    1.5. 原型模式(Prototype Pattern)  
    1.6. 建造者模式(Builder Pattern)
2.  结构型模式(Structural)：总共7种，用于描述如何实现类或对象的组合  
    2.1. 适配器模式(Adapter Pattern)  
    2.2. 桥接模式(Bridge Pattern)  
    2.3. 组合模式(Composite Pattern)  
    2.4. 装饰模式(Decorator Pattern)  
    2.5. 外观模式(Façade Pattern)  
    2.6. 享元模式(Flyweight Pattern)  
    2.7. 代理模式(Proxy Pattern)
3.  行为型模式(Behavioral)：总共11种，用于描述类或对象怎样交互以及怎样分配职责  
    3.1. 职责链模式(Chain of Responsibility Pattern)  
    3.2. 命令模式(Command Pattern)  
    3.3. 解释器模式(Interpreter Pattern)  
    3.4. 迭代器模式(Iterator Pattern)  
    3.5. 中介者模式(Mediator Pattern)  
    3.6. 备忘录模式(Memento Pattern)  
    3.7. 观察者模式(Observer Pattern)  
    3.8. 状态模式(State Pattern)  
    3.9. 策略模式(Strategy Pattern)  
    3.10. 模板方法模式(Template Method Pattern)  
    3.11. 访问者模式(Visitor Pattern)

## 设计模式的作用 ##

1.  设计模式来源众多专家的经验和智慧，它们是从许多优秀的软件系统中总结出的成功的、能够实现可维护性复用的设计方案，使用这些方案将可以让我们避免做一些重复性的工作，也许我们冥思苦想得到的一个“自以为很了不起”的设计方案其实就是某一个设计模式。在时间就是金钱的今天，设计模式无疑会为有助于我们提高开发和设计效率。
2.  设计模式提供了一套通用的设计词汇和一种通用的形式来方便开发人员之间沟通和交流，使得设计方案更加通俗易懂。无论你使用哪种编程语言，做什么类型的项目，甚至你处于一个国际化的开发团队，当面对同一个设计模式时，你和别人的理解并无二异，因为设计模式是跨语言、跨平台、跨应用、跨国界的。
3.  大部分设计模式都兼顾了系统的可重用性和可扩展性，这使得我们可以更好地重用一些已有的设计方案、功能模块甚至一个完整的软件系统，避免我们经常做一些重复的设计、编写一些重复的代码。此外，随着软件规模的日益增大，软件寿命的日益变长，系统的可维护性和可扩展性也越来越重要，许多设计模式将有助于提高系统的灵活性和可扩展性，让我们在不修改或者少修改现有系统的基础上增加、删除或者替换功能模块。
4.  合理使用设计模式并对设计模式的使用情况进行文档化，将有助于别人或自己更快地理解系统。

## 面向对象设计七大原则 ##

对于面向对象软件系统的设计而言，在支持可维护性的同时，提高系统的可复用性是一个至关重要的问题，如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一。在面向对象设计中，可维护性的复用是以设计原则为基础的。每一个原则都蕴含一些面向对象设计的思想，可以从不同的角度提升一个软件结构的设计水平。面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则。

我们最常见的面向对象设计原则有如下七种：

1.  单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责
2.  开闭原则(Open-Closed Principle, OCP)：软件实体应对扩展开放，而对修改关闭
3.  里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类对象的地方能够透明地使用其子类的对象
4.  依赖倒转原则(Dependence Inversion Principle, DIP)：抽象不应该依赖于细节，细节应该依赖于抽象
5.  接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总的接口
6.  合成复用原则 (Composite Reuse Principle, CRP)：尽量使用对象组合，而不是继承来达到复用的目的
7.  迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用