一文搞懂设计模式--外传之为什么要使用设计模式

WHY？为什么要使用设计模式

在思考为什么要使用设计模式之前，让我们先来思考如何设计一款优秀的软件？当然这里的软件指的是软件的实现架构。让我们思考一下软件架构设计所需要达成的目标，以及设计模式如何在这其中发挥作用

代码复用

对于软件开发而言，成本和时间永远是最重要的。代码复用是减少开发成本最常用的方式之一，这个想法看起来非常自然，但是实际在开发过程中，要让已有代码能够适配新的场景往往还是需要付出额外的代价。例如，不同的模块之间存在紧密的耦合关系，这使得复用这些代码变得更加困难。

对于代码复用来说，最底层的复用通常会涉及到类、类库、容器等等可以独立存在的个体。最高层的复用则是通过各种具体的框架，使用框架定义好的各种接口，精简你的设计，通过框架定义好的抽象概念来设计具体的业务流程，最后通过类来表示这些概念并且描述它们的关系。框架通常会具有比单个类更大的颗粒度，想要修改框架是一个困难且复杂的工作。因此，我们可以插入一个中间层，这即是设计模式所处的位置。设计模式比框架更加小巧，实际上设计模式描述的是一组类之间的关系及其互动方式，设计模式向下连接了最底层的类，向上为框架提供可以更灵活、更易用的接口。

拓展性

想要遇到完全不变的需求就是在做梦。需求的变化是无法避免的，有经验的程序员能够在程序设计的阶段就为未来程序可能的变更留下足够的灵活空间。设计模式的存在即是帮助程序员们更好的面对未来需求的变化，在设计时就为将来的变化做好准备，来降低未来面对变更的开销。

HOW？怎样正确使用设计模式

许多设计模式功能相似，并没有清晰的界限。但是我们并不需要为此感到困惑，设计模式是为了更好的实现功能及其拓展，并不是为了某个特定场景而出现的。

诚然设计模式是一系列通用的技术性解决方案，然而我们需要明白，技术是为了业务服务的。我们需要掌握设计模式的应用场景、优缺点，以满足日常业务的需要即可。

在实际开发过程中，我们不应规定必须使用设计模式，不能为了使用设计模式而做架构，而是在架构的设计过程中，发现其可以与某些设计模式向匹配再将两者结合。

设计模式要活学活用，不要生搬硬套。使用设计模式的目的都是让程序低耦合、高复用、高内聚、易拓展、易维护，务必记住这些初心，不要为设计模式而设计，这只会对开发有害。设计模式只是实现了七大设计原则的具体方式，太多的设计模式只会导致代码凌乱不堪。

所以怎样才能用好设计模式，我觉得需要遵守一下几个原则：

需求驱动

需求包括功能需求、性能需求、运行时需求等等。设计模式是针对软件设计的，而软件设计是针对需求的。开发的最终目的是需求的实现，因此设计模式需要为需求服务。

避免设计过度

设计模式解决的设计不足的问题，但是同时也要避免过度设计。奥卡姆剃刀原则告诉我们“如无必要，勿增实体”。引入设计模式是为了简化问题，当我们觉得问题变得更加复杂的时候，说明简单的问题已经被复杂化，需要评估问题本身是否需要设计模式。

在软件设计过程中，开发者需要区分出需求的稳定部分和固化部分。一个软件必然存在其稳定部分，这部分功能如果发生变更，这个软件本身就将毫无意义，核心业务逻辑是需要被固化的。同时对于可变部分，需要开发者仔细评估可能变化的程度来指定设计策略。设计不足与设计过度同样有害。

充分了解所使用的的开发工具

设计模式针对的是面向对象的开发语言，在理论上他应该适合任何面向对象语言，但是不同的语言本身带有其不同的特性，因此设计模式的具体是实现会有很大的区别。

在编程中领悟模式

软件开发是一项实践性工作，没有不会下棋的围棋大师，也没有不会编程的架构师。掌握设计模式需要理论积累以及实践积累，在实践过程中进行“渐悟”

WHAT？怎样设计一个优秀的模式

在前面提到了设计模式是实现了七大设计原则的具体方式，只要满足七大设计原则，我们就可以认为这是一个好的模式，那么这七大原则分别是什么

开闭原则

开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出：软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。

如何理解对扩展开放，对修改关闭。难道我们在开发过程中可以不编写代码就实现新功能吗？事实上，开闭原则是希望我们在需要修改代码时尽量不修改原有代码，而是通过拓展新的类来实现功能的增强。

开闭原则的实现方法

可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中，这既是接口定义规范的具体应用。

因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

里氏替换原则

里氏替换原则（Liskov Substitution Principle，LSP）由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立（Inheritance should ensure that any property proved about supertype objects also holds for subtype objects），可以简单理解为里氏替换原则希望在使用继承时，其子类应该能够完全代替其父类，且系统仍能稳定运行。

里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。

里氏替换原则的实现方法

里氏替换原则通俗来讲就是：**子类可以扩展父类的功能，但不能改变父类原有的功能。**也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

因此我们可以总结一下里氏替换原则的实现方法：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法

• 子类中可以增加自己特有的方法

• 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松

• 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等

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

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

合成复用原则

合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

合成复用原则的实现方法

合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

合成复用原则的重要性

通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。

1. 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。

2. 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。

3. 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。

1. 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。

2. 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。

3. 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

依赖倒置原则

依赖倒置原则（Dependence Inversion Principle，DIP）是 Object Mentor 公司总裁罗伯特·马丁（Robert C.Martin）于 1996 年在 C++ Report 上发表的文章。

依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程。

依赖倒置原则是实现开闭原则的重要途径，遵循依赖倒置原则可以极大降低模块与模块之间的耦合程度。

在软件设计中，细节是多变的，而其抽象则相对稳定的多。因此我们应该用抽象搭建起如软件的框架，这比以细节为基础搭建起的框架稳定的多。这里的抽象可以理解为接口或抽象类，而细节是具体的实现类。

使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。

依赖倒置原则的实现方法

依赖倒置原则的目的是通过面向接口变成来降低模块之间的耦合度，所以我们可以通过遵循一下几个要点来满足这个原则

1. 每个类都需要提供其抽象类或接口，或者同时提供两者

2. 变量声明的类型尽量是接口或者抽象类

3. 类不应该从具体类派生

4. 使用继承时尽量遵循里氏替换原则

单一职责原则

单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。

这个原则要求一个类不应该承担太多的职责（也可以理解为功能），否则将会出现以下问题：

1. 该对象的一个职责发生变化时可能会影响其他的职责

2. 当使用者需要这个类的某一个职责时，不得不将其他不需要的职责全部包含进去，从而造成代码的冗余

单一职责原则的实现方法

单一职责原则是最简单但又最难运用的原则，需要开发者发现类的不同职责并将其分离，再封装到不同的类或模块中。事实上，这个原则很难被完全遵守，如果对职责拆分的过细同样会带来更大的维护成本，在实际过程中通常要根据开发者的经验，在设计和维护中进行一个取舍。

单一职责原则的优点

• 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。

• 提高类的可读性。复杂性降低，自然其可读性会提高。

• 提高系统的可维护性。可读性提高，那自然更容易维护了。

• 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

接口隔离原则

接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。

2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use）。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。

这两个定义要求开发者为各个类建立他们需要的专属接口，而不是尝试使用一个庞大的接口提供所有需要的定义。

接口隔离原则与单一职责原则在核心思想上是一致的，都是为了为了提高类的内聚性、降低类间的耦合，体现了封装的思想

但是二者在关注点上又有所不同：

• 单一职责原则注重的是职责，而接口隔离原则注重的则是对接口依赖的隔离。

• 单一职责原则约束的是类，针对的是程序中的实现和细节，而接口隔离原则约束的是接口，针对的是程序中的抽象和整体框架。

接口隔离原则的实现方法

在应用接口隔离原则的时候，有一下几个规则可以参考

• 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。

• 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。

• 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。

• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

接口隔离原则的优点

• 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

• 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。

• 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。

• 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。

• 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

迪米特法则的

迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。

迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体（类）无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

迪米特法则的实现方法

迪米特法则强调以下两点：

1. 从依赖者的角度来说，只依赖应该依赖的对象。

2. 从被依赖者的角度说，只暴露应该暴露的方法。

对于迪米特法则来说，应该注意一下几点

1. 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。

2. 在类的结构设计上，尽量降低类成员的访问权限。

3. 在类的设计上，优先考虑将一个类设置成不变类。

4. 在对其他类的引用上，将引用其他对象的次数降到最低。

5. 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。

6. 谨慎使用序列化（Serializable）功能。

迪米特法则的优点

• 降低了类之间的耦合度，提高了模块的相对独立性。

• 由于耦合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。