敏捷软件开发

敏捷软件开发:SRP单一职责原则

(2009-03-24 20:30:24)

转载

标签：

it

这条原则实际就是体现内聚性原则的体现，一个模块的组成元素之间的功能相关性。把内聚性概念扩展一下：把内聚性和引起一个模块或者类改变的作用力联系起来。

一个类应该只有一个发生变化的原因。若Game类有2个不同的职责，一个是记录当前轮，另一个式计算分数，最后要把这两个职责分离到两个类中。为何把这两个职责分在单独的类中呢？因为每个职责都是变化的一个轴线，当需求变化会反映为类的职责的变化。如果一个类承担了多于一个职责，那么引起它变化的原因就会有多个。

如果一个类承担的职责太多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或抑制这个类完成其他职责的能力，这种耦合或导致脆弱的设计，当变化发生时，设计会遭受到预想不到的破坏。

定义职责：如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，有时候我们很难注意到这点，我们习惯以组的形式去考虑职责。

public interface Modem{

public void Dial(String pno);

public void Handup();

public void Send(char c);

public char Recv();

}

接口包括了2个职责，第一个职责是连接管理，第二个职责是数据通信。

如果应用程序的变化方式总是导致这两个职责同时变化，那么就不要分离他们，分开他们就会有不必要的复杂性味道。仅当变化发生时，变化的轴线才有实际意义，如果没有征兆，那么应用SRP或者任何其他原则都是比明智的。

分离耦合的职责：经常会有一些和硬件或者操作系统的细节有关的原因，迫使我们把不愿意耦合在一起的东西欧和在一起了。然而，对于应用的其余部分来说，通过分离他们的接口我们已经解耦概念。

如果ModenImplementation implemet DataChannel,Conection。ModenImplementation看起来是一个混杂物，或者有缺陷的类，所有的依赖关系都是从它发出来的。谁都不需要依赖它，谁都不需要知道它的存在。因此，我们已经把丑陋的部分隐藏起来了。其丑陋性不会泄露出来，污染应用程序的其它部分。

持久化：如Emplyee:CalculatePay,Store,Emplyee类包括了业务规则和对于持久化的控制，这两个职责在大多数情况下绝不应该混合在一起。业务规则往往会频繁地变化，而持久化的方式却不会如此频繁的变化，并且变化的原因也不一样。把持久化系统和业务规则绑定在一起是自讨苦吃的做法。如果发现这种情况存在了，应该使用FACADE、dao或者proxy模式对设计进行重构，分离这两个原则。

SRP是所有原则中最简单的原则之一，也是最难正确运用的原则之一。

敏捷软件开发——开放封闭原则OCP

首先，让我们分析一下背景。什么是软件开发过程中最不稳定的因素？——答案是需求！需求在软件开发过程中时时刻刻都可能发生变化。那么，如何灵活应对变化是软件结构设计中最重要也是最困难的一个问题。好的设计带来了极大了灵活性，不好的设计则充斥着僵化的臭味。这样，也就引出了本文的主题：【开发封闭原则】。

下面，就来简单扼要的介绍一下什么是【开放封闭原则】。【开发封闭原则】包括两个特征：对于扩展是开放的；对于修改是封闭的。对于扩展开放，意味着模块的行为是可扩展的。对于修改封闭，就是说在扩展模块行为的同时不对任何既有代码或二进制代码（.jar）进行修改。当然，这里说的过于绝对。有时为了完成某些任务不得不改动既有代码。但是，我们的目标是尽量的遵守原则。

那如何才能做到对扩展开发，对修改封闭呢？关键在于抽象！那什么是抽象呢？

我个人的理解是：抽象是对事物本质的概念上的理解。面向对象的分析中应该以行为分析为主线。举一个例子说明：假如从北京到上海，我们可以坐飞机，可以坐火车，可以坐汽车，也可以骑自行车。那对于这个问题如何分析呢？这个问题的抽象又是什么呢？也许可以这样思考：飞机、火车、汽车和自行车在本质上都是交通工具。所以得到这样的分析结果：交通工具被抽象为父类，飞机、火车、汽车和自行车都是其特例化的实现，父类中定义一个抽象方法，可以将人从一个地方运送到另外一个地方，各个子类重新定义运送的方式。这个设计无可厚非！但是，注意了！如果哪天某个人心情不错，想从北京走到上海了。那他的交通工具又是什么呢？11路！如果把步行也算成交通工具那就太不符合实际了。所以，面向对象的分析角度，不应该是从事物物理方面的关联去分析，而应该是从事物的行为方面的管理区分析。对于这个问题，一个人从北京道上海，无论是怎么到达的，只不过是移动策略不同。

下面，就给出相应的示例代码来说明一下上述问题。

class Traveller {

private Car car = new Car();

public void travel(Address srcAddress,Address destAddress){

car.move(srcAddress,destAddress);

}

}

这是最开始直接使用Car的旅行者，如果想替换成AirPlane怎么办？修改代码，用new AirPlane()代替Car。面向对象的实践原则指出：面向接口编程，而不面向实现编程。当代码依赖于具体实现时，就缺失了灵活性，面对新的扩展（也就是新的实现），必须修改既有代码。

接着，给出设计灵活的代码：

class Traveller {

private TravelStrategy _strategy;

public void travel(Address srcAddress,Address destAddress){

_strategy.move(srcAddress,destAddress);

}

public void setTravelStrategy(TravelStrategy strategy){

_strategy = strategy;

}

}

public interface TravelStrategy{

void move(Address srcAddress,Address destAddress);

}

public class CarStrategy implements TravelStrategy{

public void move(Address srcAddress,Address destAddress){

...

}

}

public class AirPlaneStrategy implements TravelStrategy{

public void move(Address srcAddress,Address destAddress){

...

}

}

public class WorkStrategy implements TravelStrategy{

public void move(Address srcAddress,Address destAddress){

...

}

}

使用这种设计就能灵活的应对设计。比如说：现在需要另外一种从北京到上海的方式——爬。呵呵，也许这种行为不可思议，但它也能达到目的。那如何扩展呢？只需要扩展一个新的TravelStrategy实现即可。这样，Traveller类不需要修改任何代码！可以通过调用setter方法来切换移动策略。现在还有一个问题：如何确定实例化哪个策略？这里可以引用工厂，专门负责对象实例化。可以将需要使用的策略放在文件中，这样改变策略时就不需要修改源代码了。但当新增策略时，还是需要修改Factory。没办法，现实中没有完全符合原则的情况，我们只能尽力去遵守！

现在，我们看一下以上代码中类之间的关系。Traveller类、TravelStrategy接口及其实现类，Traveller类是TravelStrategy接口的客户代码。那Traveller和TravelStrategy的关系与TravelStrategy和它的实现类指尖的关系哪个更紧密一些呢？答案是前者。这也正是另外一个敏捷原则【依赖倒置原则】。高层代码不应该依赖低层代码，低层代码要依赖于高层代码。在这里，说白了的意思就是：一个旅行者要从北京到上海，而旅行团已经给他安排好了去的方法，他本身并不关心怎么到达，只需要知道有办法到达就可以了。这里旅行者和到达方法之间的关系就非常密切了，而具体如何到达那是低层次的问题了。

上述的问题与实现是实现【开放封闭原则】的一种常用方法——策略模式。还有一种常用的实现方法：模板方法。其实，对于这两种方法的本质所在也就是面向对象中的组合与继承。

我们已经学会了如何封装变化，那合适才封装呢？掌握了这项技能是一件好事，但滥用就出问题了~！因为遵循OCP的代价是昂贵的，创建正确的抽象是要花费时间和精力的，同时那些抽象也增加了软件设计的复杂性。通常，我们采用这种办法：只受愚弄一次。也就

是说，最初的实现不封装任何东西。当真正的变化到来了，重构代码，封装变化，以避免同类问题再次发生。

OCP是面向对象设计的核心所在。开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象与抽象本身一样重要。

最后，在简单介绍一下面向对象分析的常用方法：

寻找问题域中的各个事物或行为共性

从共性中创建抽象

从共性的变化中创建派生

看共性之间的关系如何

敏捷软件开发读书笔记（4）——OO五大原则（3.LSP——里氏替换原则）(转)

2007-05-31 09:12:06| 分类：J2EE学习 | 标签：无|字号订阅

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”这种“按接口编程”语言的优劣，两类语言都有待于改进。庄兄对DJ的设想倒是开始引入DbC的概念了。这一点还是非常值得期待的。^_^ 另外，接口的语义正被OCP、LSP、DbC这样的概念不断地强化，接口表达了对象行为之间的“契约”关系。而不是简单地作为一种实现多继承的语法糖。

敏捷软件开发读书笔记（2）——OO五大原则（1.SRP 单一职责原则）

一点说明：OO的五大原则是指SRP、OCP、LSP、DIP、ISP。这五个原则是书中所提到的。除此之外，书中还提到一些高层次的原则用于组织高层的设计元素，这些放到下次再写。当然，OO设计的原则可能不止这五个，希望大家多提宝贵意见，多多交流。

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

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

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

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

“单一职责”就是要在设计中为每种职责设计一个类，彼此保持正交，互不干涉。这个雕塑（二重奏）就是正交的一个例子，钢琴家和小提

琴家各自演奏自己的乐谱，而结果就是一个和谐的交响乐。当然，真

实世界中，演奏小提琴和弹钢琴的必须是两个人，但是在软件中，我

们往往会把两者甚至更多搅和到一起，很多时候只是为了方便或是最

初设计的时候没有想到。

这样的例子在设计中很常见，书中就给了一个很好的例子：调制

解调器。这是一个调制解调器最基本的功能。但是这个类事实上完成

了两个职责：连接的建立和中断、数据的发送和接收。显然，这违反

了SRP。这样做会有潜在的问题：当仅需要改变数据连接方式时，必

须修改Modem类，而修改Modem类的结果就是使得任何依赖Modem类的元素都需要重新编译，不管它是不是用到了数据连接功能。解决的办法，书中也已经给出：重构Modem类，从中抽出两个接口，一个专门负责连接、另一个专门负责

数据发送。依赖Modem类的元素也要做相应的细化，根据职责的不同分别依赖不同的接

口。最后由ModemImplementation类实现这两个接口。

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

敏捷软件开发读书笔记（3）——OO五大原则（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”

（下一篇就要讲LSP了，我觉得这是意义最为重要的OO设计原则，它直指当今主流OO 语言的软肋，点出了OO设计的精髓。）

posted on 2006-01-18 00:26 GHawk阅读(5759) 评论(7)编辑收藏所属分类: 软件过程、学习笔记

敏捷软件开发读书笔记（4）——OO五大原则（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”这种“按接口编程”语言的优劣，两类语言都有待于改进。庄兄对DJ的设想倒是开始引入DbC的概念了。这一点还是非常值得期待的。^_^ 另外，接口的语义正被OCP、LSP、DbC这样的概念不断地强化，接口表达了对象行为之间的“契约”关系。而不是简单地作为一种实现多继承的语法糖。

posted on 2006-01-18 18:12 GHawk阅读(2981) 评论(2)编辑收藏所属分类: 软件过程、学习笔记