敏捷软件开发 OO原则

1.SRP 单一职责原则

 

      一点说明：OO的五大原则是指SRP、OCP、LSP、DIP、ISP。这五个原则是书中所提到的。除此之外，书中还提到一些高层次的原则用于组织高层的设计元素。

      在学习和使用OO设计的时候，我们应该明白：OO的出现使得软件工程师们能够用更接近真实世界的方法描述软件系统。然而，软件毕竟是建立在抽象层次上的东西，再怎么接近真实，也不能替代真实或被真实替代。

      OO设计的五大原则之间并不是相互孤立的。彼此间存在着一定关联，一个可以是另一个原则的加强或是基础。违反其中的某一个，可能同时违反了其余的原则。因此应该把这些原则融会贯通，牢记在心！

1. SRP（Single Responsibility Principle 单一职责原则）
      单一职责很容易理解，也很容 易实现。所谓单一职责，就是一个设计元素只做一件事。什么是“只做一件事”？简单说就是少管闲事。现实中就是如此，如果要你专心做一件事情，任何人都有信 心可以做得很出色。但如果，你整天被乱七八糟的事所累，还有心思和精力把每件事都作好么？

     “ 单一职责”就是要在设计中为每种职责设计一个类，彼此保持正交，互不干涉。这个雕塑（二重奏）就是正交的一个例子，钢琴家和小提琴家各自演奏自己的乐谱， 而结果就是一个和谐的交响乐。当然，真实世界中，演奏小提琴和弹钢琴的必须是两个人，但是在软件中，我们往往会把两者甚至更多搅和到一起，很多时候只是为 了方便或是最初设计的时候没有想到。 

      这样的例子在设计中很常见，书中就给了一个很好的例子：调制解调器。这是一个调制解调 器最基本的功能。但是这个类事实上完成了两个职责：连接的建立和中断、数据的发送和接收。显然，这违反了SRP。这样做会有潜在的问题：当仅需要改变数据 连接方式时，必须修改Modem类，而修改Modem类的结果就是使得任何依赖Modem类的元素都需要重新编译，不管它是不是用到了数据连接功能。解决 的办法，书中也已经给出：重构Modem类，从中抽出两个接口，一个专门负责连接、另一个专门负责数据发送。依赖Modem类的元素也要做相应的细化，根 据职责的不同分别依赖不同的接口。最后由ModemImplementation类实现这两个接口。

      从这个例子中，我们不难发现，违反SRP通常是由于过于“真实”地设计了一个类所造成的。因此，解决办法是往更高一层进行抽象 化提取，将对某个具体类的依赖改变为对一组接口或抽象类的依赖。当然，这个抽象化的提取应该根据需要设计，而不是盲目提取。比如刚才这个Modem的例子 中，如果有必要，还可以把DataChannel抽象为DataSender和DataReceiver两个接口。

 

 

 

2.OCP——开闭原则

开闭原则很简单，一句话：“Closed for Modification; Open for Extension”——“对变更关闭；对扩展开放”。开闭原则其实没什么好讲的，我将其归结为一个高层次的设计总则。就这一点来讲，OCP的地位应该比SRP优先。

OCP的动机很简单：软件是变化的。不论是优质的设计还是低劣的设计都无法回避这一问题。OCP说明了软件设计应该尽可能地使架构稳定而又容易满足不同的需求。

为什么要OCP？答案也很简单——重用。

“重用”，并不是什么软件工程的专业词汇，它是工程界所共用的词汇。早在软件出现前，工程师们就在实践“重用”了。比如机械产品，通过零部 件的组装得到最终的能够使用的工具。由于机械部件的设计和制造过程是极其复杂的，所以互换性是一个重要的特性。一辆车可以用不同的发动机、不同的变速箱、 不同的轮胎……很多东西我们直接买来装上就可以了。这也是一个OCP的例子。

如何在OO中引入OCP原则？把对实体的依赖改为对抽象的依赖就行了。下面的例子说明了这个过程：

05赛季的时候，一辆F1赛车有一台V10引擎。但是到了06赛季，国际汽联修改了规则，一辆F1赛车只能安装一台V8引擎。车队很快投入了新赛车 的研发，不幸的是，从工程师那里得到消息，旧车身的设计不能够装进新研发的引擎。我们不得不为新的引擎重新打造车身，于是一辆新的赛车诞生了。但是，麻烦 的事接踵而来，国际汽联频频修改规则，搞得设计师在“赛车”上改了又改，最终变得不成样子，只能把它废弃。

为了能够重用这辆昂贵的赛车，工程师们提出了解决方案：首先，在车身的设计上预留出安装引擎的位置和管线。然后，根据这些设计好的规范设计引擎（或是引擎的适配器）。于是，新的赛车设计方案就这样诞生了。

 

显然，通过重构，这里应用的是一个典型的Bridge模式。这个实现的关键之处在于我们预先给引擎留出了位置！我们不必因为对引擎的规则的频频变更而制造相当多的车身，而是尽可能地沿用和改良现有的车身。
说到这里，想说一说OO设计的一个误区。
学 习OO语言的时候，为了能够说明“继承”（或者说“is-a”）这个概念，教科书上经常用实际生活中的例子来解释。比如汽车是车，电车是车，F1赛车是汽 车，所以车是汽车、电车、F1赛车的上层抽象。这个例子并没有错。问题是，这样的例子过于“形象”了！如果OO设计直接就可以将现实生活中的概念引用过 来，那也就不需要什么软件工程师了！OO设计的关键概念是抽象。如果没有抽象，那所有的软件工程师的努力都是徒劳的。因为如果没有抽象，我们只能去构造世 界中每一个对象。上面这个例子中，我们应该看到“引擎”这个抽象的存在，因为车队的工程师们为它预留了位置，为它制定了设计规范。
上面这个设计也 实现了后面要说的DIP（依赖倒置原则）。但是请记住，OCP是OO设计原则中高层次的原则，其余的原则对OCP提供了不同程度的支持。为了实现OCP， 我们会自觉或者不自觉地用到其它原则或是诸如Bridge、Decorator等设计模式。然而，对于一个应用系统而言，实现OCP并不是设计目的，我们 所希望的只是一个稳定的架构。所以对OCP的追求也应该适可而止，不要陷入过渡设计。正如Martin本人所说：“No significant program can be 100% closed.”“Closure not complete but strategic”

 

 

 

3.LSP——里氏替换原则

OCP作为OO的高层原则，主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构，维持设计的封闭性。

“抽象”是语言提供的功能。“多态”由继承语义实现。

如此，问题产生了：“我们如何去度量继承关系的质量？”

Liskov于1987年提出了一个关于继承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。”也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有 is-A关系。

该原则称为Liskov Substitution Principle——里氏替换原则。林先生在上课时风趣地称之为“老鼠的儿子会打洞”。^_^

我们来研究一下LSP的实质。学习OO的时候，我们知道，一个对象是一组状态和一系列行为的组合体。状态是对象的内在特性，行为是对象的外在特性。LSP所表述的就是在同一个继承体系中的对象应该有共同的行为特征。

这一点上，表明了OO的继承与日常生活中的继承的本质区别。举一个例子：生物学的分类体系中把企鹅归属为鸟类。我们模仿这个体系，设计出这样的类和关系。

 

类“鸟”中有个方法fly，企鹅自然也继承了这个方法，可是企鹅不能飞阿，于是，我们在企鹅的类中覆盖了fly方法，告诉方法的调用者：企 鹅是不会飞的。这完全符合常理。但是，这违反了LSP，企鹅是鸟的子类，可是企鹅却不能飞！需要注意的是，此处的“鸟”已经不再是生物学中的鸟了，它是软 件中的一个类、一个抽象。

有人会说，企鹅不能飞很正常啊，而且这样编写代码也能正常编译，只要在使用这个类的客户代码中加一句判断就行了。但是，这就是问题所 在！首先，客户代码和“企鹅”的代码很有可能不是同时设计的，在当今软件外包一层又一层的开发模式下，你甚至根本不知道两个模块的原产地是哪里，也就谈不 上去修改客户代码了。客户程序很可能是遗留系统的一部分，很可能已经不再维护，如果因为设计出这么一个“企鹅”而导致必须修改客户代码，谁应该承担这部分 责任呢？（大概是上帝吧，谁叫他让“企鹅”不能飞的。^_^）“修改客户代码”直接违反了OCP，这就是OCP的重要性。违反LSP将使既有的设计不能封 闭！

修正后的设计如下：

 

但是，这就是LSP的全部了么？书中给了一个经典的例子，这又是一个不符合常理的例子：正方形不是一个长方形。这个悖论的详细内容能在网上找到，我就不多废话了。

LSP并没有提供解决这个问题的方案，而只是提出了这么一个问题。

于是，工程师们开始关注如何确保对象的行为。1988年，B. Meyer提出了Design by Contract（契约式设计）理论。DbC从形式化方法中借鉴了一套确保对象行为和自身状态的方法，其基本概念很简单：

1. 每个方法调用之前，该方法应该校验传入参数的正确性，只有正确才能执行该方法，否则认为调用方违反契约，不予执行。这称为前置条件(Pre-condition)。
2. 一旦通过前置条件的校验，方法必须执行，并且必须确保执行结果符合契约，这称之为后置条件(Post-condition)。
3. 对象本身有一套对自身状态进行校验的检查条件，以确保该对象的本质不发生改变，这称之为不变式(Invariant)。

以上是单个对象的约束条件。为了满足LSP，当存在继承关系时，子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松；而子类中方法的后置条件必须与超类中被覆盖的方法的后置条件相同或者更为严格。

一些OO语言中的特性能够说明这一问题：

• 继承并且覆盖超类方法的时候，子类中的方法的可见性必须等于或者大于超类中的方法的可见性，子类中的方法所抛出的受检异常只能是超类中对应方法所抛出的受检异常的子类。
  public   class  SuperClass {
       public   void  methodA()  throws  IOException {}
  }
  
  public   class  SubClassA  extends  SuperClass {
       // this overriding is illegal.
       private   void  methodA()  throws  Exception {}
  }
  
  public   class  SubClassB  extends  SuperClass {
       // this overriding is OK.
       public   void  methodA()  throws  FileNotFoundException {}
  }
  
  
• 从Java5开始，子类中的方法的返回值也可以是对应的超类方法的返回值的子类。这叫做“协变”(Covariant)
  
  public   class  SuperClass  {
       public  Number caculate() {
           return   null ;
      }
  }
  
  public   class  SubClass  extends  SuperClass {
       // only compiles in Java 5 or later.
       public  Integer caculate() {
           return   null ;
      }
  }

可以看出，以上这些特性都非常好地遵循了LSP。但是DbC呢？很遗憾，主流的面向对象语言（不论是动态语言还是静态语言）还没有加入对DbC的支持。但是随着AOP概念的产生，相信不久DbC也将成为OO语言的一个重要特性之一。

一些题外话：

前一阵子《敲响OO时代的丧钟》和《丧钟为谁而鸣》 两 篇文章引来了无数议论。其中提到了不少OO语言的不足。事实上，遵从LSP和OCP，不管是静态类型还是动态类型系统，只要是OO的设计，就应该对对象的 行为有严格的约束。这个约束并不仅仅体现在方法签名上，而是这个具体行为的本身。这才是LSP和DbC的真谛。从这一点来说并不能说明“万事万物皆对象” 的动态语言和“C++，Java”这种“按接口编程”语言的优劣，两类语言都有待于改进。
另外，接口的语义正被OCP、LSP、DbC这样的概念不断地强化，接口表达了对象行为之间的“契约”关系。而不是简单地作为一种实现多继承的语法糖。