设计原则

设计原则一览表

名称	作用
单一职责原则	类要职责单一
里氏替换原则	不要破坏继承体系
依赖倒置原则	要面向接口编程
接口隔离原则	在设计接口的时候要精简单一
迪米特法则	要降低耦合
开闭原则	要对扩展开放，对修改关闭
合成/聚合复用原则	尽量使用对象组合，而不是继承来达到复用

单一职责原则

1. 定义
   高内聚、低耦合：类的职责要单一，不能将太多的职责放在一个类中，即一个类只负责一项职责。

2. 原则分析

• 一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小，而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。
• 类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现。
• 单一职责原则是 实现高内聚、低耦合的 指导方针，在很多代码重构手法中都能找到它的存在，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

3. 问题由来
   类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

4. 解决方案
   遵循单一职责原则。
   分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

5. 优点

• 降低类的复杂性，类的职责清晰明确。比如数据职责和行为职责清晰明确。
• 提高类的可读性和维护性，
• 变更引起的风险减低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的类有影响，对其他接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

6. 例子 SpringMVC 中 Entity, DAO, Service, Controller, Util等的分离。

提示

单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

里氏替换原则

里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士、麻省理工学院教授BarbaraLiskov和卡内基.梅隆大学Jeannette Wing教授于1994年提出。

1. 定义
   第一种定义方式相对严格: 如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有变化，那么类型S是类型T的子类型。
   第二种更容易理解的定义方式: 所有引用基类(父类)的地方必须能透明地使用其子类的对象。即子类能够必须能够替换基类能够从出现的地方。子类也能在基类 的基础上新增行为。

2. 问题由来
   有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

3. 原则分析
   讲的是基类和子类的关系，只有这种关系存在时，里氏代换原则才存在。例如：正方形是长方形是理解里氏代换原则的经典例子。
   里氏代换原则可以通俗表述为: 在软件中如果能够使用基类对象，那么一定能够使用其子类对象。把基类都替换成它的子类，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类的话，那么它不一定能够使用基类。
   里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

4. 解决方案
   当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。

5. 优点 在面向对象的语言中，继承是必不可少的、非常优秀的语言机制，它有如下优点：

• 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
• 提高代码的重用性；
• 子类可以形似父类，但又异于父类，“龙生龙，凤生凤，老鼠生来会打洞”是说子拥有父的“种”，“世界上没有两片完全相同的叶子”是指明子与父的不同；
• 提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，君不见很多开源框架的扩展接口都是通过继承父类来完成的；
• 提高产品或项目的开放性。

6. 缺点 继承的缺点如下：

• 继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法；
• 降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束；
• 增强了耦合性。当父类的常量、变量和方法被修改时，必需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大片的代码需要重构。

提示

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：

1. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
2. 子类中可以增加自己特有的方法。
3. 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

依赖倒置原则

1. 定义
   高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。要针对接口编程，不针对实现编程。

2. 问题由来
   类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

3. 原则分析

• 如果说开闭原则是面向对象设计的目标,依赖倒转原则是到达面向设计"开闭"原则的手段..如果要达到最好的"开闭"原则,就要尽量的遵守依赖倒转原则. 可以说依赖倒转原则是对"抽象化"的最好规范!。
• 依赖倒转原则的常用实现方式之一是在代码中使用抽象类，而将具体类放在配置文件中。
• 类之间的耦合：零耦合关系，具体耦合关系，抽象耦合关系。依赖倒转原则要求客户端依赖于抽象耦合，以抽象方式耦合是依赖倒转原则的关键。

提示

依赖关系(Dependency)： 是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。（ 假设 A 类的变化引起了 B 类的变化，则说名 B 类依赖于 A 类。 ）

4. 解决方案
   将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

提示

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

5. 传递依赖关系三种方式

• 接口传递
• 构造方法传递
• setter方法传递

6. 优点
   减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

提示

在实际编程中，一般需要做到如下3点：

• 低层模块尽量都要有抽象类或接口，或者两者都有。
• 变量的声明类型尽量是抽象类或接口。
• 使用继承时遵循里氏替换原则。

接口隔离原则

1. 定义
   客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

2. 问题由来
   类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

3. 原则分析

• 接口隔离原则是指使 用多个专门的接口，而不使用单一的总接口 。每一个接口应该承担一种相对独立的角色，不多不少，不干不该干的事，该干的事都要干。
  • 一个接口就 只代表一个角色 ，每个角色都有它特定的一个接口，此时这个原则可以叫做“角色隔离原则”。
  • 接口 仅仅提供客户端需要的行为 ，即所需的方法，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。
• 使用接口隔离原则拆分接口时，首先必须满足 单一职责原则 ，将一组相关的操作定义在一个接口中，且在满足高内聚的前提下，接口中的方法越少越好。
• 可以在进行系统设计时采用 定制服务 的方式，即 为不同的客户端提供宽窄不同的接口 ，只提供用户需要的行为，而隐藏用户不需要的行为。

4. 解决方案
   将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。

提示

采用接口隔离原则对接口进行约束时，要注意以下几点：

• 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
• 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

迪米特法则

迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。

1. 定义
   一个对象应该对其他对象保持最少的了解。

2. 问题由来
   类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

3. 法则分析

• 朋友类 在迪米特法则中，对于一个对象，其朋友包括以下几类:
  • 当前对象本身(this)；
  • 以参数形式传入到当前对象方法中的对象；
  • 当前对象的成员对象；
  • 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
  • 当前对象所创建的对象。 任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。
• 狭义法则和广义法则
  在狭义的迪米特法则中，如果两个类之间不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
  • 狭义的迪米特法则
    可以降低类之间的耦合，但是会在系统中增加大量的小方法并散落在系统的各个角落，它可以使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联，但是也会造成系统的不同模块之间的通信效率降低，使得系统的不同模块之间不容易协调。
  • 广义的迪米特法则
    指对对象之间的信息流量、流向以及信息的影响的控制，主要是对信息隐藏的控制。信息的隐藏可以使各个子系统之间脱耦，从而允许它们独立地被开发、优化、使用和修改，同时可以促进软件的复用，由于每一个模块都不依赖于其他模块而存在，因此每一个模块都可以独立地在其他的地方使用。一个系统的规模越大，信息的隐藏就越重要，而信息隐藏的重要性也就越明显。
• 迪米特法则的主要用途: 在于控制信息的过载。
  • 在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；
  • 在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；
  • 在类的设计上，只要有可能，一个类型应当设计成不变类；
  • 在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

4. 解决方案
   尽量降低类与类之间的耦合。

5. 例子
   外观模式Facade(结构型) 迪米特法则与设计模式Facade模式、Mediator模式

提示

系统中的类,尽量不要与其他类互相作用,减少类之间的耦合度,因为在你的系统中,扩展的时候,你可能需要修改这些类,而类与类之间的关系,决定了修改的复杂度,相互作用越多,则修改难度就越大,反之,如果相互作用的越小,则修改起来的难度就越小..例如A类依赖B类,则B类依赖C类,当你在修改A类的时候,你要考虑B类是否会受到影响,而B类的影响是否又会影响到C类. 如果此时C类再依赖D类的话,呵呵,我想这样的修改有的受了。

开闭原则

1. 定义
   一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
   意思是,在一个系统或者模块中,对于扩展是开放的,对于修改是关闭的,一个 好的系统是在不修改源代码的情况下,可以扩展你的功能. 而实现开闭原则的关键就是抽象化。

2. 问题由来
   在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

3. 原则分析

• 当软件实体因需求要变化时, 尽量通过扩展已有软件实体，可以提供新的行为，以满足对软件的新的需求，而不是修改已有的代码，使变化中的软件有一定的适应性和灵活性 。已有软件模块，特别是最重要的抽象层模块不能再修改，这使变化中的软件系统有一定的稳定性和延续性。
• 实现开闭原则的关键就是抽象化 :在"开-闭"原则中,不允许修改的是抽象的类或者接口,允许扩展的是具体的实现类,抽象类和接口在"开-闭"原则中扮演着极其重要的角色，即要预知可能变化的需求.又预见所有可能已知的扩展，所以在这里"抽象化"是关键!
• 可变性的封闭原则:找到系统的可变因素,将它封装起来. 这是对"开-闭"原则最好的实现. 不要把你的可变因素放在多个类中,或者散落在程序的各个角落。你应该将可变的因素,封套起来，并且切忌不要把所用的可变因素封套在一起。最好的解决办法是,分块封套你的可变因素!避免超大类,超长类,超长方法的出现!!给你的程序增加艺术气息,将程序艺术化是我们的目标!

4. 解决方案
   当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

5. 例子
   设计模式中模板方法模式和观察者模式都是开闭原则的极好体现。

合成/聚合复用原则

1. 定义
   又叫做合成复用原则(Composite ReusePrinciple或CRP)，尽量使用对象组合，而不是继承来达到复用的目的。
   就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。
   简而言之，要尽量使用合成/聚合，尽量不要使用继承。

2. 原则分析

• 在面向对象设计中，可以通过两种基本方法在不同的环境中复用已有的设计和实现，即通过组合/聚合关系或通过继承。
  • 继承复用: 实现简单，易于扩展。破坏系统的封装性；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；只能在有限的环境中使用。(“白箱”复用)
  • 组合/聚合复用: 耦合度相对较低，选择性地调用成员对象的操作；可以在运行时动态进行。(“黑箱”复用)
• 组合/聚合可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少，因此一般首选使用组合/聚合来实现复用；其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
• 此原则和里氏代换原则氏相辅相成的,两者都是具体实现"开-闭"原则的规范。违反这一原则，就无法实现"开-闭"原则。

提示

• 合成(组合): 表示一个整体与部分的关系，指一个依托整体而存在的关系(整体与部分不可以分开)；比如眼睛和嘴对于头来说就是组合关系，没有了头就没有眼睛和嘴，它们是不可分割的。在UML中，组合关系用带实心菱形的直线表示。
• 聚合:聚合是比合成关系的一种更强的依赖关系,也表示整体与部分的关系(整体与部分可以分开)；比如螺丝和汽车玩具的关系，螺丝脱离玩具依然可以用在其它设备之上。在UML中，聚合关系用带空心菱形的直线表示。