设计模式：概念与设计原则

什么是设计模式

软件工程中，设计模式（design pattern）是对软件设计中普遍存在的各种问题，所提出的解决方案。

 

设计模式的目的

1、代码重用性：相同的代码不需要多次编写。

2、可读性：即编程规范性，便于其他程序员的阅读和理解。

3、可扩展性：可以很方便的增加新的功能，也称为可维护性。

4、高内聚、低耦合

 

设计模式七大原则

设计模式原则是程序员编程时，应该遵守的原则，也是各种设计模式的基础（即设计模式为什么这样设计）。

单一职责原则（Single Responsibility Principle，SRP）

定义：应该有且仅有一个原因引起类的变更。简单来说，即一个类只负责一项职责，只有一个可以引起它的变化的原因。

我们知道，在 OOP (Object Oriented Programming) 里面，高内聚、低耦合是软件设计追求的目标，而单一职责原则可以看做是高内聚、低耦合的延伸，将职责定义为引起变化的原因，以提高内聚性，以此来减少引起变化的原因。职责过多，可能引起变化的原因就越多，这将会导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。

单一职责原则是七大原则中最容易理解的原则，但要真正实现它并不容易。通常情况下，我们应该遵守单一职责原则。只有在逻辑足够简单，才可以在代码级违反单一指责原则（使用 if - else）；只有类中方法数量足够少，才可以在方法级别保持单一指责原则。

设计模式六大原则（1）：单一职责原则

小话设计模式原则之：单一职责原则SRP

接口隔离原则（Interface Segregation Principle，ISP）

定义：1、客户端不应该依赖它不需要的接口；2、类间的依赖关系应该建立在最小的接口上。

其实通俗来理解就是，不要在一个接口里面放很多的方法，这样会显得这个接口臃肿不堪。接口应该尽量细化，一个接口对应一个功能模块，同时接口里面的方法应该尽可能的少，使接口更加轻便灵活。或许看到接口隔离原则这样的定义很多人会觉得和单一职责原则很像，但是这两个原则还是有着很鲜明的区别。接口隔离原则和单一职责原则的审视角度是不同的，单一职责原则要求类和接口职责单一，注重的是职责，是业务逻辑上的划分，而接口隔离原则要求方法要尽可能的少，是在接口设计上的考虑。例如一个接口的职责包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，并规定了“不使用的方法不能访问”，这样的设计是不符合接口隔离原则的，接口隔离原则要求“尽量使用多个专门的接口”，这里专门的接口就是指提供给每个模块的都应该是单一接口(即每一个模块对应一个接口)，而不是建立一个庞大臃肿的接口来容纳所有的客户端访问。

面向对象六大原则——接口隔离原则

依赖倒置原则（Dependence Inversion Principle，DIP）

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。依赖倒置原则的核心思想是面向接口编程。

依赖关系传递常用的方式有三种：接口传递、构造方法传递、setter 方法传递。

注意事项：

• 底层模块尽量都要有抽象类或接口，增加程序稳定性。
• 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间就存在一个缓冲层，利于程序的扩展。
• 继承时遵循里氏替换原则。

设计原则之依赖倒置和接口隔离

设计模式六大原则（3）：依赖倒置原则

里氏替换原则（Liskov Substitution Principle，LSP）

定义：1、如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。2、所有引用基类的地方必须能透明地使用其子类的对象。即子类可以扩展父类的功能，但不能改变父类原有的功能。

OO（Object-Oriented）中继承性的缺点：

1. 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
2. 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所涉及到的子类的功能都可能产生故障。

通过重写父类的方法来完成新的功能写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。

如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。

需要注意，不要将里氏替换原则理解成子类应该避免 override。里氏替换原则不是不能 override，而是要按照父类所期望的那样去 override。

里氏替换原则——面向对象设计原则

Java 中的多态是不是违背了里氏替换原则？

迪米特法则（Law Of Demeter，LOD）

定义：1、一个对象应该对其他对象保持最少了解；2、只与你的直接朋友交谈，不跟“陌生人”说话。

对第一点而言，迪米特法则也称之为最少知识原则，通俗的讲就是一个类对自己依赖的类知道的越少越好，对于被依赖的类，向外公开的方法应该尽可能的少。

而第二点的含义是，如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。这里的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

迪米特法则想要表达的是降低类之间的耦合度，提高模块的相对独立性。其实现方式主要有通过以下两个方面：

• 从被依赖者的角度来说，只暴露应该暴露的方法或者属性，即在编写相关的类的时候确定方法/属性的权限；
• 从依赖者的角度来说，只依赖应该依赖的对象。

迪米特法则——面向对象设计原则

白话设计——浅谈迪米特法则

合成复用原则（Composite/Aggregate Reuse Principle，CARP）

定义：要尽量使用合成和聚合，尽量不要使用继承。

为什么尽量不要使用继承？

1. 继承复用破坏包装，它把父类的实现细节直接暴露给了子类，这违背了信息隐藏的原则；
2. 如果父类发生了改变，那么子类也要发生相应的改变，这就直接导致了类与类之间的高耦合，不利于类的扩展、复用、维护等，也带来了系统僵硬和脆弱的设计。而用合成和聚合的时候新对象和已有对象的交互往往是通过接口或者抽象类进行的，就可以很好的避免上面的不足，而且这也可以让每一个新的类专注于实现自己的任务，符合单一职责原则。

那么我们时候才能使用继承复用呢？判断标准是里氏替换原则，里氏代换原则是继承复用的基础。合成复用原则同里氏替换原则相辅相成的。

设计模式六大原则——合成/聚合复用原则(CARP)

面向对象的7种设计原则(4)-合成/聚合复用原则

开闭原则（Open Closed Principle，OCP）

定义：软件实体应当对扩展开放，对修改关闭。首先这里的软件实体，包含以下几个部分：项目中划分出的模块、类与接口、方法；其次，对扩展开放是对提供方而言，而对修改关闭是对使用方而言。

开闭原则是编程中最重要的原则，其他原则都是为了实现开闭原则。

其实开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

这 7 种设计原则是软件设计模式必须尽量遵循的原则，各种原则要求的侧重点不同。其中，开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭；单一职责原则告诉我们实现类要职责单一；接口隔离原则告诉我们在设计接口的时候要精简单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；迪米特法则告诉我们要降低耦合度；合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。

设计模式六大原则（6）：开闭原则

开闭原则——面向对象设计原则