1. 结语

写下高效率、易保护、高需用的标识符是每两个合作开发人员的崇尚，所以，到底怎样的标识符才是更易保护与扩充的好标识符呢？责任编辑，她们就来如是说软件结构设计操作过程中的六大准则，一起来窥见五二。

2. 软件结构设计的六大准则

为的是辅导合作开发人员写下杰出的标识符，宋人早已为她们归纳出了八个准则，她们侧重相同、高度关注的视角各有相同，是她们在日常生活合作开发上要关键时刻思索、尽可能遵从的杰出结构设计：

1. 单个职能准则（SRP）

2. 开合准则（OCP）

3. 矩代替准则（LSP）

4. 接口隔离准则（ISP）

5. 依赖倒置准则（DIP）

6. 迪米特法则（LoD）

7. 合成复用准则（CRP）

其中前五个准则就统称为大名鼎鼎的 SOLID 准则。

3. 开合准则

3.1 准则描述

开合准则（Open Closed Principle，OCP）是勃兰特·梅耶在他 1988 年的著作《面向对象软件构造》中首次提出的：

软件实体应当对扩充开放，对修改关闭。

Software entities should be open for extension，but closed for modification.

具体含义是：

当应用的需求改变时，在不修改软件实体的源标识符或者二进制标识符的前提下，可以扩充模块的功能，使其满足新的需求。

3.2 准则实现

这一准则的重要性是不言而喻的，谁都希望自己的标识符能够在反复迭代的需求中仅通过扩充已有功能就可以满足新的需求，而不是两个简单的新需求就让整个标识符必须发生重构。

所以，如何实现这一准则呢？抽象约束、封装变化是两个很好的方法。

简单的来说，就是通过接口或者抽象类为软件实体定义两个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。

只要抽象层能够覆盖足够多的场景，所以，即使实现层无法满足新的需求，也只需要扩充实现层即可，而不需要改变底层的抽象结构设计。

4. 矩代替准则

4.1 准则描述

矩代替准则（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.

简单的来说，这个准则是说子类在继承父类时，不要改变父类原有的功能。

具体的来说，这个准则可以被归纳为以下四点：

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

2. 子类中可以增加自己特有的方法；

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

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

如果程序违背了矩代替准则，所以在多态环境下，标识符保护者由于遇到父子类行为的不一致，很容易陷入迷惑的境地，程序运行的出错概率也就随即大幅提升。

4.2 准则实现

她们常常会结合日常生活生活中对事物的感知来进行软件架构的结构设计，但这有时会因为违背矩代替准则而埋下隐患，比如她们结构设计两个鸟类，他包含几个属性：体重、飞行速度，并且有这两个方法对应的 get、set 方法。所以，对于任何两个鸟类的对象，她们都可以通过路程/飞行速度计算出飞行所需的时间。

然而，对于保护者来说，此时他需要创建两个鸡类，由于鸡不会飞，而鸟类中没有是否会飞的属性，意即默认鸟类的实现均会飞，此时，鸡类就不能够作为鸟类的子类，否则对于 getFlySpeed() 方法来说，如果鸡类的实现返回为 0，所以，就会造成在计算飞行时间时出现除 0 异常。

5. 依赖倒置准则

5.1 准则描述

依赖倒置准则（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.

简单的归纳，这个准则就是：

要面向接口编程，不要面向实现编程。

在实际的软件结构设计中，实现是多变的，抽象层是稳定的，因此，让模块间都通过抽象的接口或是抽象类来描述依赖，可以很大程度上降低合作开发风险，提升稳定性，同时也是模块间解耦的有力方法。

5.2 准则实现

遵从以下四点，就能在项目中满足依赖倒置规则：

1. 每个类尽可能提供接口或抽象类，或者两者都具备。

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

3. 任何类都不应该从具体类派生。

4. 使用继承时尽可能遵从矩代替准则。

6. 单个职能准则

6.1 准则描述

单个职能准则是由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件结构设计：准则、模式和实践》一书中提出的：

两个类应该有且仅有两个引起它变化的原因，否则类应该被拆分。

There should never be more than one reason for a class to change.

该准则提出对象不应该承担太多职能，如果两个对象承担了太多的职能，至少存在以下两个缺点：

1. 两个职能的变化可能会削弱或者抑制这个类实现其他职能的能力；

2. 当客户端需要该对象的某两个职能时，不得不将其他不需要的职能全都包含进来，从而造成冗余标识符或标识符的浪费。

不仅是类的结构设计，单个职能同样也适用于方法。两个方法应该尽可能做好一件事情。如果两个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。

6.2 准则实现

当两个类只具有两个职能时，所以当这个职能发生变化，她们可以非常肯定地说没有其他类需要变更，这在可保护性上来说是很强的。

例如在创建合作开发人员类时，你可能会考虑到合作开发人员需要具有写标识符、测试、调试、运行保护等方法，但事实上，写标识符的职能与其他职能并不相关，测试、调试的职能也非常独立，运行保护的职能也是同样，因此，如果将合作开发人员类拆分为合作开发人员类、测试类、运维类三个类，项目的可保护性便可以大为加强。

7. 接口隔离准则

7.1 准则描述

接口隔离准则（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.

如果能够遵从这一准则，模块间的依赖粒度得以最小化，所以，如果某个模块发生变更，其他模块受到的影响就会显著变小，外来变更就不会因此扩散到过大的范围，从而让项目的可保护性提升至非常高的维度。

这个准则也很有力的保障了模块间的低耦合与模块内的高内聚。

7.2 准则实现

在具体的实现中，她们可以尽可能遵从以下四个规则：

1. 接口尽可能小，但是要有限度。两个接口只服务于两个子模块或业务逻辑。

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

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

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

如果系统中某个模块随着业务的发展越来越庞大，适时地拆分是扼杀危险的有效手段。对模块功能进行归类，从而拆分出几个高度内聚的模块，非常有利于系统的发展。

8. 迪米特法则

8.1 准则描述

迪米特法则（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.

如果两个软件实体无须直接通信，所以就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

8.2 准则实现

在实际的合作开发操作过程中，复杂的依赖关系网往往令人无比抓狂。迪米特法则就是为的是解决这一问题而诞生的。

如果你结构设计每个类的每个方法时都问问自己：我引入的依赖是该依赖的对象吗？我暴露的方法是应该暴露的吗？所以，你的结构设计一定会有显著提升。

即便是必要依赖，也要尽可能降低依赖的次数，尤其是尽可能不要在模块间传递序列化后的数据，由于过度泛化造成的类型不清晰，可能会让你的系统产生难以预想的问题。

9. 合成复用准则

9.1 准则描述

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

继承复用虽然有简单和易实现的优点，但它也存在以下缺点：

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

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

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

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

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

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

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

9.2 准则实现

当需要扩充两个类时，优先通过类属性来进行扩充，而不是通过派生新的子类。

考虑两个实现，假设有两个职员类，他有四个子类：HR类、RD类、QA类、SRE类，这时，新的需求来了，要求每个职员都要拥有性别，所以，此时你如果选择将四个子类进一步派生出男HR类、女HR类、男RD类、女RD类……，你所需要保护的类继承层次就有三层，总计九个类，而如果你仅仅在父类中增添两个 gender 属性，整个继承层次并没有发生变化，相较于增加一层类继承层次，可保护性显然要高得多。

附录 -- 参考资料

https://en.wikipedia.org/wiki/SOLID

http://c.biancheng.net/view/1320.html