【搞懂设计模式】设计模式与面向对象原则

本文重点在解释什么是设计模式？什么场景下可以用这种设计模式？尝试以实际的问题来驱动学习，使得我们对设计模式的理解更为深刻而具体。

本文的内容分为三部分：

• 面向对象的设计原则
• UML类图定义
• 二十四种设计模式集锦

**设计模式（Design pattern）**是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。只有精通了设计模式，才敢说真正理解了软件工程。可以说，设计模式是每一个架构师所必备的技能之一。

虽然本文代码是基于Java（不管是何种语言，甚至是非OO语言，都能从设计模式中窥探一丝代码架构的奥秘），主要学习资料及图片来源于《大话设计模式》这本书，强烈建议大家阅读原书。

前言

关于面向对象特性，在《大话设计模式》中有一段极其生动的讲解，**面向对象的使用就像活字印刷术一样便捷、高效，**见下图：

第一，要改，只需更改要改之字，此为可维护；第二，这些字并非用完这次就无用，完全可以在后来的印刷中重复使用，此乃可复用；第三，此诗若要加字，只需另刻字加入即可，这是可扩展；第四,字的排列其实可能是竖排可能是横排，此时只需将活字移动就可做到满足排列需求，此是灵活性好。

可维护、可复用、可扩展、灵活性好，就是面向对象设计所力求达到的境界。

面向对象的设计原则

设计原则是编程设计过程中需要时刻考虑的，近乎于道，这些设计原则的组合、碰撞，就产生了许多精彩绝伦、可用性极强的设计模式，是可以用的术。之所以称为模式，是因为在日常的编程开发中，我们都可以学习、借鉴它们。

想要精通设计模式，必须要先搞清楚面向对象的的几大设计原则。

**开放封闭原则——**找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起！类应该对扩展开放，对修改关闭。

什么是“变化”？——如果每次需求一来，某个部分就必须改变，那么就是不稳定变化的代码。

**依赖倒置原则——**针对接口编程，而不是针对实现编程。——也可以说要依赖抽象，不要依赖具体类，简称依赖倒置原则。

针对接口编程，其实是“面向超类型（抽象类、接口）”编程。这个原则让编程的细节被隐藏，不会因为修改具体实现而经常改动程序结构。

**接口隔离原则——**为降低依赖，系统的低耦合而努力。

设计模式的出现归根结底是为了让大型软件的升级和维护方便。

**最少知道原则/墨特尔原则——**一个类对自己依赖的类知道的越少越好，一个对象应该对其他对象有最少了解。

一旦某个类应该只与它必须知道的类去交互，而不应该知道其他的类，编程的总原则就是高聚合，低耦合。

**单一职责原则——**对于一个类，应该只有一个引起其变化的原因。

因为如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏，并且也不利于代码的移植（不同平台的代码依赖不同，一旦某些类由于职责过多造成依赖关系混乱不堪，很难进行代码重构）

至于如何确定某个类是否是单一职责，可以反过来想：那就是如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责[ASD]，就应该考虑类的职责分离，即将其拆分为更小的类。

**里氏代换原则——**子类型必须能够替换它们的父类型。

换句话说，任何基类可以出现的地方，子类一定可以出现。里氏代换原则其实是对开-闭原则的补充，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。

**组合选择原则——**多用组合，少用继承。

虽然继承接口可以让不同子类中实现方式不同，但是接口不具有复用性（每一个接口的实现代码都得重写），而组合却可以为后续的程序设计提供便利。

UML类图

为了在之后的学习中更好地理解设计模式，我们需要先学习一下如何绘制、阅读UML类图。绘制UML类图，可以使用Visio或者Drawio。以下面这幅图为例，捋清常见的关系，多看并记忆即可：

类名称若为斜体，表示该类为抽象类，即无法创建实例；

类中字段（成员变量）和方法：+ 表示public；-表示private；#表示protected；

继承关系，用空心三角加实线；

接口关系即实现接口，用空心三角加虚线；

关联关系即是某个类是另一个类的成员属性，（如上图企鹅和气候，企鹅需要了解气候）用实线箭头，用代码表示就是：

聚合关系（大雁和雁群，是一种弱拥有关系）是一种弱关联关系，用空心菱形和实线箭头；

合成（组合）关系（鸟和翅膀是强拥有，即整体和局部的关系）是一种contain-a的强关联关系，用实心菱形和实线箭头，两端的底下的数字，表示几对几的关系；

依赖关系（某个类需要基于某个类而存在）表示某个类必须基于一个类存在，一般是在一些成员函数或者构造函数构造时需要，用虚线箭头；

接下来对设计模式的介绍，我会从：定义、场景、解决的方式方便大家的理解。

设计模式集锦

常见的设计模式一共有24种，细分为创建型模式（6种）、结构型模式（7）、行为型模式（11）。我将简要介绍每种设计模式的特点，具体内容会在之后的文章中逐渐更新，敬请期待~

创建型模式，共六种：

• 简单工厂模式：静态工厂方法；
• 工厂模式：创建对象的接口；
• 抽象工厂模式：创建一系列相关或依赖的对象；
• 单例模式：限制某个类只有一个实例；
• 建造者模式：分步、渐次创建复杂对象；
• 原型模式：通过复制已有实例来创建新实例；

结构型模式，共七种：

• 适配器模式：接口转换器；
• 装饰器模式：动态地给对象增加方法；
• 代理模式：通过代理控制对象访问；
• 外观模式：提供简单接口，隐藏复杂接口；
• 桥接模式：分离抽象部分与具体方法实现；
• 组合模式：组合模式使得用户对单个对象和组合对象的使用具有一致性；
• 享元模式：通过共享细粒度对象来节省内存；

行为型模式，共十一种：

• 策略模式：将各类算法封装起来，并使其可以相互替换；
• 模板方法模式：定义算法步骤，并由子类进行具体实现；
• 观察者模式：定义了对象之间地一对多的依赖关系；
• 迭代器模式：提供一种方法来访问聚合对象中各个元素；
• 责任链模式：将请求沿着处理者链路依次传递；
• 命令模式：将请求封装为对象，在上下文中进行参数化；
• 备忘录模式：保存和回复对象的内部状态；
• 状态模式：对象状态改变时执行对应的行为；
• 访问者模式：在不改变对象接口的前提下，定义作用于对象的新方法；
• 中介者模式：将对象间的交互封装在交互类中；
• 解释器模式：给定语言定义的文法，解释相关内容；

注：设计模式有的说是23种，是因为没有把简单工厂模式单独提出来。

参考资料

**让我们一起来学习设计模式吧！项目地址：**https://github.com/white0dew/Learning-Design-pattern/tree/master

《大话设计模式》

设计模式分类