我很满意

接口与设计原则

11种设计原则

类原则

1.单一职责原则 - Single Responsibility Principle(SRP)

就一个类而言，应该仅有一个引起它变化的原因。职责即为“变化的原因”。

2.开放-封闭原则 - Open Close Principle(OCP)

软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。对于扩展是开放的,对于更改是封闭的. 关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来。开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象. 拒绝不成熟的抽象和抽象本身一样重要 )

3.里氏替换原则 - Liskov Substitution Principle(LSP)

子类型(subclass)必须能够替换掉它们的基类型(superclass)。

4.依赖倒置原则(IoCP) 或依赖注入原则 - Dependence Inversion Principle(DIP)

抽象不应该依赖于细节。细节应该依赖于抽象。Hollywood原则: "Don't call us, we'll call you". 程序中所有的依赖关系都应该终止于抽象类和接口。针对接口而非实现编程。任何变量都不应该持有一个指向具体类的指针或引用。任何类都不应该从具体类派生。任何方法都不应该覆写他的任何基类中的已经实现了的方法。

5.接口隔离原则(ISP)

不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。多个面向特定用户的接口胜于一个通用接口。

包(类库、DLL)内聚原则

6.重用发布等价原则(REP)

重用的粒度就是发布的粒度。

7.共同封闭原则(CCP)

包(类库、DLL)中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。

8.共同重用原则(CRP)

一个包(类库、DLL)中的所有类应该是共同重用的。

如果重用了包(类库、DLL)中的一个类，

那么就要重用包(类库、DLL)中的所有类。

(相互之间没有紧密联系的类不应该在同一个包(类库、DLL)中。)

包(类库、DLL)耦合原则

9.无环依赖原则(ADP)

在包的依赖关系图中不允许存在环。

10.稳定依赖原则(SDP)

朝着稳定的方向进行依赖。

应该把封装系统高层设计的软件（比如抽象类）放进稳定的包中，不稳定的包中应该只包含那些很可能会改变的软件（比如具体类）。

11.稳定抽象原则(SAP)

包的抽象程度应该和其稳定程度一致。一个稳定的包应该也是抽象的，一个不稳定的包应该是抽象的. )

其它扩展原则

12.BBP(Black Box Principle)黑盒原则

多用类的聚合，少用类的继承。

13.DAP(Default Abstraction Principle)缺省抽象原则

在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作.

14.IDP(Interface Design Principle)接口设计原则

规划一个接口而不是实现一个接口。

15.DCSP(Don't Concrete Supperclass Principle)

不要构造具体的超类原则，避免维护具体的超类。

16.迪米特法则

一个类只依赖其触手可得的类。

Open-Closed Principle 软件设计中的“开-闭原则”

　　这个原则最早是由Bertrand Meyer提出,英文的原文是:Software entities should be open for extension,but closed for modification.意思是说,一个软件实体应当对扩展开放,对修改关闭.也就是说,我们在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,换句话说就是,应当可以在不必修改源代码的情况下改变这个模块的行为.

　　满足OCP的设计给系统带来两个无可比拟的优越性.

　　1.通过扩展已有的软件系统,可以提供新的行为,以满足对软件的新需求,使变化中的软件系统有一定的适应性和灵活性.

　　2.已有的软件模块,特别是最重要的抽象层模块不能再修改,这就使变化中的软件系统有一定的稳定性和延续性

接口隔离原则isp

一个类对另一个类的依赖应该表现成依赖尽可能小的接口。

这个原则是用来处理胖接口的缺陷，避免接口承担太多的责任。比如说一个接口内的方法可以被分成好几组，分别为不同的客户程序服务，说明这个接口太胖了。当然，确实也有一些类不需要内聚的接口，但这些类不应该做为单独的类被客户程序直接看到，而应该通过抽象基类或接口来关联访问。

接口污染
所谓接口污染就是为接口添加了不必要的职责。在接口中加一个新方法只是为了给实现类带来好处，以减少类的数目。持续这样做，接口就被不断污染，变胖。实际上，类的数目根本不是什么问题，接口污染会带来维护和重用方面的问题。最常见的问题是我们为了重用被污染的接口，被迫实现并维护不必要的方法。

分离客户程序就是分离接口。如果客户程序是分离的，那么相应的接口也应该是分离的，因为客户程序对它们使用的接口有反作用力。通常接口发生了变化，我们就要考虑所有使用接口的客户程序该如何变化以适应接口的变化。如果客户程序发生了变化呢？这时也要考虑接口是否需要发生变化，这就是反作用力。有时业务规则的变化不是那么直接的，而是通过客户程序的变化引发的，这时我们就需要改变接口以满足客户程序的需要。

分离接口的方式一般分为两种，委托和多继承。前者把请求委托给别的接口的实现类来完成需要的职责，后者则是通过实现多个接口来完成需要的职责。两种方式各有优缺点，通常我们应该先考虑后一个方案，如果涉及到类型转换时则选择前一个方案。

胖接口会导致客户程序之间产生不必要的耦合关系，牵一发而动全身。分解胖接口，使客户程序只依赖它需要的方法，从设计上讲，简单易维护，重用度也高。

写出漂亮代码的七种方法

首先我想说明我本文阐述的是纯粹从美学的角度来写出代码，而非技术、逻辑等。以下为写出漂亮代码的七种方法：

1，尽快结束 if语句

例如下面这个JavaScript语句，看起来就很恐怖：

1 function findShape(flags, point, attribute, list) {
2    if(!findShapePoints(flags, point, attribute)) {
3        if(!doFindShapePoints(flags, point, attribute)) {
4            if(!findInShape(flags, point, attribute)) {
5                if(!findFromGuide(flags,point) {
6                    if(list.count() > 0 && flags == 1) {
7                          doSomething();
8                    }
9                }
10            }
11       }
12    }
13 }

但如果这么写就好看得多：
1 function findShape(flags, point, attribute, list) {
2    if(findShapePoints(flags, point, attribute)) {
3        return;
4    }
5
6    if(doFindShapePoints(flags, point, attribute)) {
7        return;
8    }
9
10    if(findInShape(flags, point, attribute)) {
11        return;
12    }
13
14    if(findFromGuide(flags,point) {
15        return;
16    }
17
18    if (!(list.count() > 0 && flags == 1)) {
19        return;
20    }
21
22    doSomething();
23
24 }

你可能会很不喜欢第二种的表述方式，但反映出了迅速返回if值的思想，也可以理解为：避免不必要的else陈述。

2，如果只是简单的布尔运算（逻辑运算），不要使用if语句

例如：
1 function isStringEmpty(str){
2    if(str === "") {
3        return true;
4    }
5    else {
6        return false;
7    }
8 }

可以写为：
1 function isStringEmpty(str){
2 return (str === "");
3 }

3，使用空白，这是免费的
例如：
1 function getSomeAngle() {
2    // Some code here then
3    radAngle1 = Math.atan(slope(center, point1));
4    radAngle2 = Math.atan(slope(center, point2));
5    firstAngle = getStartAngle(radAngle1, point1, center);
6    secondAngle = getStartAngle(radAngle2, point2, center);
7    radAngle1 = degreesToRadians(firstAngle);
8    radAngle2 = degreesToRadians(secondAngle);
9    baseRadius = distance(point, center);
10    radius = baseRadius + (lines * y);
11    p1["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]);
12    p1["y"] = roundValue(radius * Math.sin(radAngle1) + center["y"]);
13    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
14    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
15    // Now some more code
16 }

很多开发者不愿意使用空白，就好像这要收费一样。我在此并非刻意地添加空白，粗鲁地打断代码的连贯性。在实际编写代码的过程中，会很容易地发现在什么地方加入空白，这不但美观而且让读者易懂，如下：
1 function getSomeAngle() {
2    // Some code here then
3    radAngle1 = Math.atan(slope(center, point1));
4    radAngle2 = Math.atan(slope(center, point2));
5
6    firstAngle = getStartAngle(radAngle1, point1, center);
7    secondAngle = getStartAngle(radAngle2, point2, center);
8
9    radAngle1 = degreesToRadians(firstAngle);
10    radAngle2 = degreesToRadians(secondAngle);
11
12    baseRadius = distance(point, center);
13    radius = baseRadius + (lines * y);
14
15    p1["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]);
16    p1["y"] = roundValue(radius * Math.sin(radAngle1) + center["y"]);
17
18    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
19    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
20    // Now some more code
21 }

4，不要使用无谓的注释
无谓的注释让人费神，这实在很讨厌。不要标出很明显的注释。在以下的例子中，每个人都知道代码表达的是“students id”，因而没必要标出。
1 function existsStudent(id, list) {
2    for(i = 0; i < list.length; i++) {
3       student = list[i];
4
5       // Get the student's id
6       thisId = student.getId();
7
8       if(thisId === id) {
9           return true;
10       }
11    }
12    return false;
13 }

5，不要在源文件中留下已经删除的代码，哪怕你标注了
如果你使用了版本控制，那么你就可以轻松地找回前一个版本的代码。如果别人大费周折地读了你的代码,却发现是要删除的代码，这实在太恨人了。

//function thisReallyHandyFunction() {
//      someMagic();
//      someMoreMagic();
//      magicNumber = evenMoreMagic();
//      return magicNumber;
//}

6，不要有太长的代码

看太长的代码实在太费劲，尤其是代码本身的功能又很小。如下：

1 public static EnumMap getGroupCategoryDistribution(EnumMap sizes, int groups) {
2        EnumMap categoryGroupCounts = new EnumMap(Category.class);
3
4        for(Category cat : Category.values()) {
5            categoryGroupCounts.put(cat, getCategoryDistribution(sizes.get(cat), groups));
6        }

我并不是说非要坚持70个字符以内，但是一个比较理想的长度是控制在120个字符内。如果你把代码发布在互联网上，用户读起来就很困难。
7，不要在一个功能（或者函数内）有太多代码行
我的一个老同事曾经说Visual C++很臭，因为它不允许你在一个函数内拥有超过10，000行代码。我记不清代码行数的上限，不知道他说的是否正确，但我很不赞成他的观点。如果一个函数超过了50行，看起来有多费劲你知道么，还有没完没了的if循环，而且你还的滚动鼠标前后对照这段代码。对我而言，超过35行的代码理解起来就很困难了。我的建议是超过这个数字就把一个函数代码分割成两个。

类的设计原则

2009-12-23 来源：lifevv.com

开闭原则

Software entities (classes, modules, function, etc.) should be open for extension, but closed for modification.

软件实体（模块，类，方法等）应该对扩展开放，对修改关闭。

开闭原则（OCP：Open-Closed Principle）是指在进行面向对象设计（OOD：Object Oriented Design）中，设计类或其他程序单位时，应该遵循：
- 对扩展开放（open）
- 对修改关闭（closed）
的设计原则。

开闭原则是判断面向对象设计是否正确的最基本的原理之一。

根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。

- 扩展开放：某模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。

- 修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。软件系统的功能上的稳定性，持续性要求是修改关闭的。

这也是系统设计需要遵循开闭原则的原因：

1）稳定性。开闭原则要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。

2）扩展性。开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。

遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。

开闭原则的实现方法

为了满足开闭原则的对修改关闭（closed for modification）原则以及扩展开放（open for extension）原则，应该对软件系统中的不变的部分加以抽象，在面向对象的设计中，

- 可以把这些不变的部分加以抽象成不变的接口，这些不变的接口可以应对未来的扩展；

- 接口的最小功能设计原则。根据这个原则，原有的接口要么可以应对未来的扩展；不足的部分可以通过定义新的接口来实现；

- 模块之间的调用通过抽象接口进行，这样即使实现层发生变化，也无需修改调用方的代码。

接口可以被复用，但接口的实现却不一定能被复用。接口是稳定的，关闭的，但接口的实现是可变的，开放的。可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能，实现软件系统的柔软扩展。

简单地说，软件系统是否有良好的接口（抽象）设计是判断软件系统是否满足开闭原则的一种重要的判断基准。现在多把开闭原则等同于面向接口的软件设计。

开闭原则的相对性

软件系统的构建是一个需要不断重构的过程，在这个过程中，模块的功能抽象，模块与模块间的关系，都不会从一开始就非常清晰明了，所以构建100%满足开闭原则的软件系统是相当困难的，这就是开闭原则的相对性。但在设计过程中，通过对模块功能的抽象（接口定义），模块之间的关系的抽象（通过接口调用），抽象与实现的分离（面向接口的程序设计）等，可以尽量接近满足开闭原则。

单一职责原则

前言

Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Menter得到。

本文介绍“Principles of OOD”中的单一职责原则：Single Responsibility Principle (SRP)。

可以从这里查看Single Responsibility Principle (SRP)的原文。

概要

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

永远不要让一个类存在多个改变的理由。

换句话说，如果一个类需要改变，改变它的理由永远只有一个。如果存在多个改变它的理由，就需要重新设计该类。

SRP（Single Responsibility Principle）原则的核心含意是：只能让一个类有且仅有一个职责。这也是单一职责原则的命名含义。

为什么一个类不能有多于一个以上的职责呢？

如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，而这种变化将影响到该类不同职责的使用者（不同用户）：

1，一方面，如果一个职责使用了外部类库，则使用另外一个职责的用户却也不得不包含这个未被使用的外部类库。

2，另一方面，某个用户由于某个原因需要修改其中一个职责，另外一个职责的用户也将受到影响，他将不得不重新编译和配置。

这违反了设计的开闭原则，也不是我们所期望的。

职责的划分

既然一个类不能有多个职责，那么怎么划分职责呢？

Robert.C Martin给出了一个著名的定义：所谓一个类的一个职责是指引起该类变化的一个原因。

If you can think of more than one motive for changing a class, then that class has more than one responsibility.

如果你能想到一个类存在多个使其改变的原因，那么这个类就存在多个职责。

Single Responsibility Principle (SRP)的原文里举了一个Modem的例子来说明怎么样进行职责的划分，这里我们也沿用这个例子来说明一下：

SRP违反例：

public interface Modem {
    public void dial(String pno);    //拨号
    public void hangup();        //挂断
    public void send(char c);    //发送数据
    public char recv();        //接收数据
}

咋一看，这是一个没有任何问题的接口设计。但事实上，这个接口包含了2个职责：第一个是连接管理（dial, hangup）；另一个是数据通信（send, recv）。很多情况下，这2个职责没有任何共通的部分，它们因为不同的理由而改变，被不同部分的程序调用。

所以它违反了SRP原则。

下面的类图将它的2个不同职责分成2个不同的接口，这样至少可以让客户端应用程序使用具有单一职责的接口：

让ModemImplementation实现这两个接口。我们注意到，ModemImplementation又组合了2个职责，这不是我们希望的，但有时这又是必须的。通常由于某些原因，迫使我们不得不绑定多个职责到一个类中，但我们至少可以通过接口的分割来分离应用程序关心的概念。

事实上，这个例子一个更好的设计应该是这样的，如图：

小结

Single Responsibility Principle (SRP)从职责（改变理由）的侧面上为我们对类（接口）的抽象的颗粒度建立了判断基准：在为系统设计类（接口）的时候应该保证它们的单一职责性。

接口分隔原则

前言

Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于““Principles of OOD”的相关文章可以从Object Menter得到。

本文介绍“Principles of OOD”中的接口分隔原则：Interface Segregation Principle (ISP)。

可以从这里查看Interface Segregation Principle (ISP)的原文。

概要

Clients should not be forced to depend upon interfaces that they do not use.

不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。

它包含了2层意思：

- 接口的设计原则：接口的设计应该遵循最小接口原则，不要把用户不使用的方法塞进同一个接口里。

如果一个接口的方法没有被使用到，则说明该接口过胖，应该将其分割成几个功能专一的接口。

- 接口的依赖（继承）原则：如果一个接口a依赖（继承）另一个接口b，则接口a相当于继承了接口b的方法，那么继承了接口b后的接口a也应该遵循上述原则：不应该包含用户不使用的方法。

反之，则说明接口a被b给污染了，应该重新设计它们的关系。

如果用户被迫依赖他们不使用的接口，当接口发生改变时，他们也不得不跟着改变。换而言之，一个用户依赖了未使用但被其他用户使用的接口，当其他用户修改该接口时，依赖该接口的所有用户都将受到影响。这显然违反了开闭原则，也不是我们所期望的。

下面我们举例说明怎么设计接口或类之间的关系，使其不违反ISP原则。

假如有一个Door，有lock，unlock功能，另外，可以在Door上安装一个Alarm而使其具有报警功能。用户可以选择一般的Door，也可以选择具有报警功能的Door。

有以下几种设计方法：

ISP原则的违反例：

方法一：

在Door接口里定义所有的方法。图：

但这样一来，依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。

方法二：

在Alarm接口定义alarm方法，在Door接口定义lock，unlock方法，Door接口继承Alarm接口。

跟方法一一样，依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。

遵循ISP原则的例：

方法三：通过多重继承实现

在Alarm接口定义alarm方法，在Door接口定义lock，unlock方法。接口之间无继承关系。CommonDoor实现Door接口，

AlarmDoor有2种实现方案：

1），同时实现Door和Alarm接口。

2），继承CommonDoor，并实现Alarm接口。该方案是继承方式的Adapter设计模式的实现。

第2）种方案更具有实用性。

这种设计遵循了ISP设计原则。

方法四：通过委让实现

这种方法其实是委让方式的Adapter设计模式的实现。

在这种方法里，AlarmDoor实现了Alarm接口，同时把功能lock和unlock委让给CommonDoor对象完成。

这种设计遵循了ISP设计原则。

小结

Interface Segregation Principle (ISP)从对接口的使用上为我们对接口抽象的颗粒度建立了判断基准：在为系统设计接口的时候，使用多个专门的接口代替单一的胖接口。

依赖倒置原则

Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Menter得到。

本文介绍DIP：Dependency Inversion Principle - 依赖倒置原则。

有关Dependency Inversion Principle (DIP) 原文可以从这里得到。

该文提出了依赖倒置原则的2个重要方针：

A. High level modules should not depend upon low level modules. Both should depend upon abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

中文意思为：

A. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象

B. 抽象不应该依赖于细节，细节应该依赖于抽象

概念解说：

依赖：在程序设计中，如果一个模块a使用/调用了另一个模块b，我们称模块a依赖模块b。

高层模块与低层模块：往往在一个应用程序中，我们有一些低层次的类，这些类实现了一些基本的或初级的操作，我们称之为低层模块；另外有一些高层次的类，这些类封装了某些复杂的逻辑，并且依赖于低层次的类，这些类我们称之为高层模块。

为什么叫做依赖倒置（Dependency Inversion）呢？

面向对象程序设计相对于面向过程（结构化）程序设计而言，依赖关系被倒置了。因为传统的结构化程序设计中，高层模块总是依赖于低层模块。

问题的提出：

Robert C. Martin氏在原文中给出了“Bad Design”的定义：

1. It is hard to change because every change affects too many other parts of the system.

(Rigidity)

系统很难改变，因为每个改变都会影响其他很多部分。

2. When you make a change, unexpected parts of the system break. (Fragility)

当你对某地方做一修改，系统的看似无关的其他部分都不工作了。

3. It is hard to reuse in another application because it cannot be disentangled from

the current application. (Immobility)

系统很难被另外一个应用重用，因为你很难将要重用的部分从系统中分离开来。

导致“Bad Design”的很大原因是“高层模块”过分依赖“低层模块”。

一个良好的设计应该是系统的每一部分都是可替换的。

如果“高层模块”过分依赖“低层模块”，一方面一旦“低层模块”需要替换或者修改，“高层模块”将受到影响；另一方面，高层模块很难可以重用。

比如，一个Copy模块，需要把来自Keyboard的输入复制到Print，即使对Keyboard和Print的封装已经做得非常好，但如果Copy模块里直接使用Keyboard与Print，Copy任很难被其他应用环境（比如需要输出到磁盘时）重用。

问题的解决：

为了解决上述问题，Robert C. Martin氏提出了OO设计的Dependency Inversion Principle (DIP) 原则。

DIP给出了一个解决方案：在高层模块与低层模块之间，引入一个抽象接口层。

High Level Classes（高层模块） --> Abstraction Layer（抽象接口层） --> Low Level Classes（低层模块）

抽象接口是对低层模块的抽象，低层模块继承或实现该抽象接口。

这样，高层模块不直接依赖低层模块，高层模块与低层模块都依赖抽象接口层。

当然，抽象也不依赖低层模块的实现细节，低层模块依赖（继承或实现）抽象定义。

Robert C. Martin氏给出的DIP方案的类的结构图：

PolicyLayer-->MechanismInterface(abstract)--MechanismLayer-->UtilityInterface(abstract)--UtilityLayer

类与类之间都通过Abstract Layer来组合关系。

里氏替换原则

Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Menter得到。

本文介绍“Principles of OOD”中的里氏替换原则：Liskov Substitution Principle (LSP)。

可以从这里查看Liskov Substitution Principle (LSP)的原文。

里氏替换原则LSP的概念解说

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

所有引用基类的地方必须能透明地使用其子类的对象。也就是说，只有满足以下2个条件的OO设计才可被认为是满足了LSP原则：

- 不应该在代码中出现if/else之类对子类类型进行判断的条件。以下代码就违反了LSP定义。

if (obj typeof Class1) {
do something
} else if (obj typeof Class2) {
do something else
}

- 子类应当可以替换父类并出现在父类能够出现的任何地方，或者说如果我们把代码中使用基类的地方用它的子类所代替，代码还能正常工作。

里氏替换原则LSP是使代码符合开闭原则的一个重要保证。同时LSP体现了：

- 类的继承原则：如果一个继承类的对象可能会在基类出现的地方出现运行错误，则该子类不应该从该基类继承，或者说，应该重新设计它们之间的关系。

- 动作正确性保证：从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。

类的继承原则：

Robert C. Martin氏在介绍Liskov Substitution Principle (LSP)的原文里，举了Rectangle和Square的例子。这里沿用这个例子，但用Java语言对其加以重写，并忽略了某些细节只列出下面的精要部分来说明里氏替换原则对类的继承上的约束。

代码：

这里Rectangle是基类，Square从Rectangle继承。

这种继承关系有什么问题吗？

假如已有的系统中存在以下既有的业务逻辑代码：

void g(Rectangle r) {
r.setWidth(5);
r.setHeight(4);
if (r.getWidth() * r.getHeight() != 20) {
throw new RuntimeException();
}
}

则对应于扩展类Square，在调用既有业务逻辑时：

Rectangle square = new Square();
g(square);

时会抛出一个RuntimeException异常。这显然违反了LSP原则。

动作正确性保证：

因为LSP对子类的约束，所以为已存在的类做扩展构造一个新的子类时，根据LSP的定义，不会给已有的系统引入新的错误。

Design by Contract

根据Bertrand Meyer氏提出的Design by Contract（DBC：基于合同的设计）概念的描述，对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等，只有前提条件得到满足时，这个方法才能被调用；同时后续条件用来说明这个方法完成时的状态，如果一个方法的执行会导致这个方法的后续条件不成立，那么这个方法也不应该正常返回。

现在把前提条件以及后续条件应用到继承子类中，子类方法应该满足：

1）前提条件不强于基类．

2）后续条件不弱于基类．

换句话说，通过基类的接口调用一个对象时，用户只知道基类前提条件以及后续条件。因此继承类不得要求用户提供比基类方法要求的更强的前提条件，亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。同样，继承类必须顺从基类的所有后续条件，亦即，继承类方法的行为和输出不得违反由基类建立起来的任何约束，不能让用户对继承类方法的输出感到困惑。

这样，我们就有了基于合同的LSP，基于合同的LSP是LSP的一种强化。

在很多情况下，在设计初期我们类之间的关系不是很明确，LSP则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。

针对接口编程，而不是针对实现编程

在面向对象设计方法中有很多值得提倡的方法，这些方法可以为我们的设计带来很大的灵活性，可复用性。其中一个原则就是“针对接口编程，而不是针对实现编程”
这个原则带来的好处有以下几点：
Client不必知道其使用对象的具体所属类。
Client无需知道特定类，只需知道他们所期望的接口。
一个对象可以很容易地被（实现了相同接口的）的另一个对象所替换。
对象间的连接不必硬绑定（hardwire）到一个具体类的对象上，因此增加了灵活性。
松散藕合（loosens coupling）。
增加了重用的可能性。提高了（对象）组合的机率，因为被包含对象可以是任何实现了一个指定接口的类。

但从辩证法的角度看，事物总有利有弊。“针对接口编程”有如上诸多好处，却不可避免的带来设计的复杂性。特别对于没有丰富经验的设计人员。
其中令我比较困惑的地方是：
要想针对接口编程，就必然要最大化接口类，使包括所有子类的方法，这样我们才能利用多态性用接口类来实现操作子类。但这会带来以下几点不足。
违反面向对象的另一个原则，这个原则是：一个类只能定义那些对它的子类有意义的操作。
接口类包括了并不是对每一个子类都有意义的方法，使接口类臃肿，难以理解。
从父类继承的无用方法，如何处理。

5 Principles for OOD/OOP

2008-10-21 12:50

http://hi.baidu.com/hyk2008/blog/item/148ae781de7cead19023d925.html

1.SRP----单一责任原则

2.OCP----开闭原则

3.LSP----Liskov替换原则

4.DIP----依赖倒置原则

5.ISP----接口分离原则

　　敏捷开发提倡简单设计的实践，“并在实现新需求时抓住机会改进设计”以对同类性质的改动封闭，做到由需求的变化驱动设计的进化（我们不能因为设计的退化而责怪需求的变化），同时经验在此起到十分重要的作用，如有经验的设计人员可以凭经验在初始设计时做出必要的抽象来满足ocp原则等，或是在需求变动时确定系统所需的抽象（所需的封闭），当然应及早的刺激这种变化的出现（如测试驱动的开发方法）。

　　OOD承诺了一系列的好处（灵活性可重用性可维护性），用OO语言设计开发，若要方便的得到这些所谓的好处，有一系列的原则是要遵循的，如SRP，OCP，LSP，ISP等。

　　 SRP（单一职责原则）维护类的简单性，类不应承担一个以上令其变化的原因，否则应考虑分离并重新构造类，但如果的应用的变化方式总是导致类中的职责同时变化，却没必要分离他们

　　Ocp（开闭原则）使OO系统做到对扩展开放，对修改封闭。OCP的遵循关键在于抽象，其主要实现方式有：定义接口描绘所需的操作，client只需关注接口的调用，子类型可以以任何其选择的方式实现接口，即所谓的stategy模式，或者定义抽象类并于其中实现公共操作，个性操作定义为abstract或virtual，由子类型负责个性化实现，通过此两法，将功能的通用部分和实现细节分离出来。当然，设计人员应该确定（猜测或凭经验）系统对哪种变化做到封闭，因为不可能对所有变化做到封闭，如《敏捷模式实践》中提到shape类型排序处理问题，为做到对排序安排（或变动）的封闭（使得各子类型间无需相互知晓，也可以做到自由安排排序顺序），选择使用“数据驱动”的方式（即单独构造结构表示排序安排—其中以子类类型在结构中的排列位置表先后），于shape基类中实现一次Precedes操作即可，子类型无需分别实现。OCP作为OOD核心所在依赖抽象来实现，但敏捷设计（或者说好的设计）拒绝不成熟的抽象，程序仅应对频繁变化的部分做出抽象。

　　Liskov替换原则是使得ocp成为可能的原则之一，强调“子类型subtype必须能够替换掉它们的基类型basetype”，控制OO的继承关系安排，在OOD用is-a来确定类间的继承关系，LSP指出这种is-a关系是就行为方式（即类的各操作）而言的，而行为方式是可以合理假设的，是客户程序所依赖的。为遵循LSP，可借用DBC（design by contract）的操作前置条件和后置条件，“要使操作得以执行，前置条件必须为真，执行完毕后，该操作要确保后置条件为真”（为每个方法注明其前置和后置条件十分有帮助），如此，则“在重新声明派生类中操作时，只能使用相等或更弱的前置条件来替换原始的前置条件，只能用相等或更强的后置条件来替换原始的后置条件”（interface和其实现类间抽象方法和其实现此二者一定满足前述条件）。同时亦可用前述ocp遵循所用的二模式使设计符合LSP，另外子类型中的异常抛出应考虑在遵循LSP的范围内。

　　关于提取公共部分的设计工具：“提取公共职责放入超类中，稍后添加的新的子类型可能会以新的方式支持同样的职责，此时原来的超类可能会是一个抽象类”。

DIP（依赖倒置原则），作为framework的设计核心，其相对于传统软件设计而言，通常（传统）软件设计中采用结构化设计用高层模块直接调用底层模块，这样高层模块将严重依赖于底层模块的变动，在OOD中通过为高层模块定义所需使用的服务接口，底层模块现实这样的接口，高层模块通过抽象接口使用下一层（strategy模式所声明的），如此看来接口的拥有者一般是其使用者而非其实现者。通常为了满足DIP-良好OOD的基本底层机制，我么需要找出系统中潜在的抽象，而抽象通常是那些不随具体细节变化而变化的东东。

ISP接口隔离原则，如SRP维护类的简单性一样，ISP用于维护接口的简单和必要性，因为接口是为客户调用的，因此其应该是“大小尺寸合适的”，“胖”接口显然对调用者造成累赘，ISP则用于将“胖”接口分离成多个合适的接口。

当然，在系统设计实现中要做到这些并非容易，单单知道其存在未必做得到将其实现到系统中，开发经验的积累同样重要，但早些知道存在个意识并在做时将其考虑进去，也是积累，慢慢来吧，n多事要做呐。

架构师之路(5)---面向对象的设计原则王泽宾

1 OO的设计原则

采用面向对象的分析和设计思想，为我们分析和解决问题提供了一种全新的思维方式。我们在拿到需求之后(略去OOA，以后补全)，接下来的问题就是：如何对系统进行面向对象的设计呢？

按照软件工程的理论，面向对象的设计要解决的核心问题就是可维护性和可复用性。尤其是可维护性，它是影响软件生命周期重要因素，通常情况下，软件的维护成本远远大于初期开发成本。

一个可维护性很差的软件设计，人们通常称之为“臭味”的，形成的原因主要有这么几个：过于僵硬、过于脆弱、复用率低或者黏度过高。相反，一个好的系统设计应该是灵活的、可扩展的、可复用的、可插拔的。在20世纪80到90年代，很多业内专家不断探索面向对象的软件设计方法，陆续提出了一些设计原则。这些设计原则能够显著地提高系统的可维护性和可复用性，成为了我们进行面向对象设计的指导原则：

1、单一职责原则SRP

每一个类应该只专注于做一件事。

2、 “开-闭”原则OCP

每一个类应该是对扩展开放，对修改关闭。

3、里氏代换原则LSP

避免造成派生类的方法非法或退化，一个基类的用户应当不需要知道这个派生类。

4、依赖倒转原则DIP

用依赖于接口和抽象类来替代依赖容易变化的具体类。

5、接口隔离原则ISP

应当为客户提供尽可能小的接口，而不是提供大的接口。

其中，“开-闭”原则是面向对象的可复用设计的基石，其他设计原则是实现“开-闭”原则的手段和工具。

我会为大家一一进行讲解。

2 单一职责原则SRP(Single-Responsibility Principle)

2.1 什么是单一职责

单一职责就是指一个类应该专注于做一件事。现实生活中也存在诸如此类的问题：“一个人可能身兼数职，甚至于这些职责彼此关系不大，那么他可能无法做好所有职责内的事情，所以，还是专人专管比较好。”我们在设计类的时候，就应该遵循这个原则：单一职责。

我们以计算器编程为例：

在有些人眼里，计算器就是一件东西，是一个整体，所以它把这个需求进行了抽象，最终设计为一个Calculator类，代码如下：

class Calculator{

public String calculate() {

Console.Write("Please input the first number:");

String strNum1 = Console.ReadLine();

Console.Write(Please input the operator:");

String strOpr= Console.ReadLine();

Console.Write("Please input the second number:");

String strNum2 = Console.ReadLine();

String strResult = "";

if (strOpr == "+"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) + Convert.ToDouble(strNum2));

}

else if (strOpr == "-"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) - Convert.ToDouble(strNum2));

}

else if (strOpr == "*"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) * Convert.ToDouble(strNum2));

}

else if (strOpr == "/"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) / Convert.ToDouble(strNum2));

}

Console.WriteLine("The result is " + strResult);

}

另外，还有一部分人认为：计算器是一个外壳和一个处理器的组合。

class Appearance{

public int displayInput(String &strNum1,String &strOpr, String &strNum2) {

Console.Write("Please input the first number:");

strNum1 = Console.ReadLine();

Console.Write(Please input the operator:");

strOpr= Console.ReadLine();

Console.Write("Please input the second number:");

strNum2 = Console.ReadLine();

return 0;

}

public String displayOutput(String strResult) {

Console.WriteLine("The result is " + strResult);

}

class Processor{

public String calculate(String strNum1,String strOpr, String strNum2){

String strResult = "";

if (strOpr == "+"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) + Convert.ToDouble(strNum2));

}

else if (strOpr == "-"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) - Convert.ToDouble(strNum2));

}

else if (strOpr == "*"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) * Convert.ToDouble(strNum2));

}

else if (strOpr == "/"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) / Convert.ToDouble(strNum2));

}

return strResult;

}

为什么这么做呢？因为外壳和处理器是两个职责，都是很容易发生需求变动的因素，所以把他们放到一个类中，违背了单一职责原则。

比如，用户可能对计算器提出以下要求：

第一，目前已经实现了“加法”、“减法”、“乘法”和“除法”，以后还可能出现“乘方”、“开方”等很多运算。

第二，现在人机界面太简单了，还可能做个Windows计算器风格的界面或者Mac计算器风格的界面。

所以，把一个类Calculator 拆分为两个类Appearance和Processor，更容易应对需求变化。如果界面需要修改，那么就去修改Appearance类；如果处理器需要修改，那么就去修改Processor类。

我们再举一个邮件的例子。我们平常收到的邮件内容，看起来是一封信，实际上内部有两部分组成：邮件头和邮件体。电子邮件的编码要求符合RFC822标准。

第一种设计方式是这样：

interface IEmail {

public void setSender(String sender);

public void setReceiver(String receiver);

public void setContent(String content);

}

class Email implements IEmail {

public void setSender(String sender) {// set sender; }

public void setReceiver(String receiver) {// set receiver; }

public void setContent(String content) {// set content; }

}

这个设计是有问题的，因为邮件头和邮件体都有变化的可能性。

1、邮件头的每一个域的编码，可能是BASE64，也可能是QP，而且域的数量也不固定。

2、邮件体中封装的邮件内容可能是PlainText类型,也可能是HTML类型，甚至于流媒体。

所谓第一种设计方式违背了单一职责原则，里面封装了两种可能引起变化的原因。

我们依照单一职责原则，对其进行改进后，变为第二种设计方式：

interface IEmail {

public void setSender(String sender);

public void setReceiver(String receiver);

public void setContent(IContent content);

}

interface IContent {

public String getAsString();

}

class Email implements IEmail {

public void setSender(String sender) {// set sender; }

public void setReceiver(String receiver) {// set receiver; }

public void setContent(IContent content) {// set content; }

}

有的资料把单一职责解释为：“仅有一个引起它变化的原因”。这个解释跟“专注于做一件事”是等价的。如果一个类同时做两件事情，那么这两件事情都有可能引起它的变化。同样的道理，如果仅有一个引起它变化的原因，那么这个类也就只能做一件事情。

2.2 单一职责原则的使用

单一职责原则的尺度如何掌握呢？我怎么能知道该拆分还是不应该拆分呢？原则很简单：需求决定。如果你所需要的计算器，永远都没有外观和处理器变动的可能性，那么就应该把它抽象为一个整体的计算器；如果你所需要的计算器，外壳和处理器都有可能发生变动，那么就必须把它拆离为外壳和处理器。只能有一个原因可能引起计算器的变化。

单一职责原则把相同的职责进行聚合，避免把相同的职责分散到不同的类之中，这样就可以控制变化，把变化限制在一个地方，防止因为一个地方的变动，引起更多地方的变动的“涟漪效应”。单一职责原则实际上消除了对象之间的耦合，避免一个类承担过多的职责。单一职责不是说一个类就只有一个方法，而是单一功能。

我们在使用单一职责原则的时候，牢记以下几点：

A、一个设计合理的类，应该仅有一个可以引起它变化的原因，即单一职责，如果有多个原因可以引起它的变化，就必须进行分离；

B、在没有需求变化征兆的情况下，应用SRP或其他原则是不明智的，因为这样会使系统变得很复杂，系统由一堆细小的颗粒组成，这纯属于没事找抽；

C、在需求能够预计或实际发生变化时，就应该使用SRP原则来重构代码，有经验的设计师、架构师对可能出现的需求变化很敏感，设计上就会具有前瞻性。

-------------------------------------------------------------

后记：最近看了一个“现场说法”的电视节目，着实有意思。说是最近有两个偷车大盗被我警方抓获。这俩大盗都是贼中高手，非常了得，不过，他们却有着不同的成长路线。
其中一个大盗，苦心钻研开锁技术，专门去香港学习先进技术，前后花了一百多万，非常舍得投资，回来后屡屡得手。另一个大盗，就比较狡猾，整天到商场的停车场，跟随着宝马、奔驰的车主，在车主购物的时候，伺机偷去车钥匙，然后从停车场把车开走，案发的时候案值达到了千万。呵呵，看来干什么事，都得找到关键所在。

3 什么是依赖注入(DI)
我们先看一些生活中的例子，帮助你理解依赖注入(DI)：

3.1 主机和内置硬盘
我们平时所用的电脑，它的硬盘安装在主机里面，从电脑的外部，我们是看不见硬盘的。所以，我们通常认为，电脑的所有部件是融为一体的。

图5：主机和内置硬盘

对于一体机而言，一旦出现了问题，我们可能无法准确地判断到底是什么零部件出现了问题，有可能是CPU坏了，也有可能是主板烧了，还有可能是内存松动了。还有的时候，比如，电脑硬盘出现了问题，可能导致整台电脑都无法使用。从这个例子，我们可以看到部件之间“紧密耦合”的产生的问题：无法准确的定位和诊断故障所在。这种情形，在软件工程的理论中，称之为可理解性和可测试性差。

如果你想修理电脑的硬盘，那么在修理过程中就必须小心翼翼，不要把其它的部件再搞坏了，比如不慎把内存给碰松动了，硬盘固然是修好了，但整台电脑仍然无法使用。这种情形，在软件工程的理论中，称之为可修改性差。
可理解性、可测试性、可修改性组成了系统的可维护性，一体机的可维护性就表现得比较差。

3.2 主机和USB设备
大家对USB接口和设备应该都很熟悉。自从有了USB接口，给我们使用电脑带来了很大的方便，现在有很多的外部设备都支持USB接口。

图6：主机和USB设备

从软件工程角度，我们分析一下USB带来的好处：
1、USB设备作为主机的外部设备，在插入主机之前，与主机没有任何的关系，两者都可独立进行测试，无论两者中的任何一方出现什么的问题，都不会影响另一方的运行，所以可维护性比较好。
2、同一个USB设备可以插接到不同的支持USB的任何主机，也就是USB设备可以被重复利用，所以可复用性比较好。
3、支持热插拔，只要是支持USB接口的设备都可以接入，所以可扩展性比较好，非常灵活。

3.3 依赖注入
2004年，Martin Fowler从另一个角度来思考这个问题，提出了“哪些方面的控制被反转了？”这样一个问题，并给出了答案：“依赖对象的获得被反转”。于是，他给“控制反转”取了一个他认为更合适的名字叫做“依赖注入（Dependency Injection）”。他的这个答案，实际上点明了实现IoC理论的解决方法。所谓依赖注入，就是由IoC容器在运行期间，动态地将某种依赖关系注入到对象之中。

依赖注入(DI)和控制反转(IoC)是从不同的角度的描述的同一件事情，都是指通过引入第三方，即IoC容器，实现软件系统中对象之间的解耦。

控制反转能够带给系统开发的好处，与USB机制带来的好处基本类似，而且依赖注入的实现跟USB机制也完全一样。USB机制是现实中依赖注入的很好的案例。我们用一个实际的例子，分析一下USB机制：

任务：主机通过USB接口读取一个文件。
思路：首先，必须制定一个USB接口标准，主机对USB设备的访问严格按照USB接口标准，USB设备提供的功能也必须符合USB接口标准。
当主机需要获取一个文件的时候，它直接去读取USB接口，根本不会关心USB接口上连接的是什么设备。
如果我给主机连接上一个U盘，那么主机就从U盘上读取文件；如果我给主机连接上一个外接硬盘，那么主机就从外接硬盘上读取文件。选取何种外部设备的权力由我说了算，也就是控制权归我。
至此,依赖注入的思路已经非常清楚：当主机需要读取文件的时候，我就把它所要依赖的外部设备，挑出来一个，帮他挂接上。这个过程就是一个被依赖的对象在系统运行时被注入另外一个对象内部的过程。在这个过程中，我就起到了IoC容器的作用。

我们再把依赖注入应用到软件工程中：
Class A依赖于Class B,当Class A需要用到Class B的时候，IoC容器就会立刻创建一个Class B送给Class A使用。IoC容器就是一个类制造工厂，你需要什么，直接来拿，直接用就可以了，而不需要去关心你所用的东西是如何制成的，也不用关心最后是怎么被销毁的，这一切全由IoC容器包办。

4 实现IoC容器

----------------------------------------------------

后记：之所以突然跳跃到39，是因为有的同学基础比较好，已经没有必要阅读有关面向对象、设计模式以及软件工程的基本理论，那么可以从这里开始阅读。基础需要继续补全的同学，可以从4继续看，我会定期在两个方向进行更新。框架理论，是架构师知识体系中非常重要的部分，我会逐步结合实例，把常见的一些框架方面的知识与大家共享。

读书笔记--面向对象设计原则

2007年05月26日上午 07:56

“开—闭”原则
面向对象设计的基石是“开—闭”原则。
“开一闭”原则讲的是：一个软件实体应当对扩展开放，对修改关闭。
这个规则说的是，在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。
从另外一个角度讲，就是所谓的“对可变性封装原则”。

“对可变性封装原则”意味着两点：
1 .一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。同一种可变性的不同表象意味着同一个继承等级结构中的具体子类。
2.一种可变性不应当与另一种可变性混合在一起。即类图的继承结构一般不应超过两层。

做到“开—闭”原则不是一件容易的事，但是也有很多规律可循，这些规律同样也是设计原则，它们是实现开—闭原则的工具。

里氏代换原则

里氏代换原则：
即如果一个软件实体使用的是基类的话那么也一定适用于子类。但反过来的代换不成立。

如果有两个具体类A和B之间的关系违反了里氏代换原则，可以在以下两种重构方案中选择一种：
1 创建一个新的抽象类C,作为两个具体类的超类，将A和B共同的行为移动到C中，从而解决A和B行为不完全一致的问题。
2 从B到A的继承关系改写为委派关系。

咋一看觉得这个怎么还是面向对象设计的原则呢？这个明明就是Java的语法规则。对，Java是提供了对里氏代换原则在语法上的支持。但是仅仅是语法上，在和现实世界的相符合程度上根本没有提供。所有常常会有不符合里氏代换原则的情况出现。

依赖倒转原则

依赖倒转原则讲的是：要依赖于抽象，不要依赖于具体。即针对接口编程，不要针对实现编程。针对接口编程的意思是，应当使用接口和抽象类进行变量的类型声明、参量的类型声明，方法的返还类型声明，以及数据类型的转换等。不要针对实现编程的意思就是说，不应当使用具体类进行变量的类型声明、参量的类型声明，方法的返还类型声明，以及数据类型的转换等。

依赖倒转原则虽然强大，但却不易实现，因为依赖倒转的缘故，对象的创建很可能要使用对象工厂，以避免对具体类的直接引用，此原则的使用还会导致大量的类。维护这样的系统需要较好的面向对象的设计知识。

此外，依赖倒转原则假定所有的具体类都是变化的，这也不总是正确的。有一些具体类可能是相当稳定、不会发生变化的，消费这个具体类实例的客户端完全可以依赖于这个具体类。

接口隔离原则

接口隔离原则讲的是：使用多个专门的接口比使用单一的接口要好。从客户的角度来说：一个类对另外一个类的依赖性应当是建立在最小的接口上的。如果客户端只需要某一些方法的话，那么就应当向客户端提供这些需要的方法，而不要提供不需要的方法。提供接口意味着向客户端作出承诺，过多的承诺会给系统的维护造成不必要的负担。

合成、聚合复用原则

合成、聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部份，新的对象通过向这些对象的委派达到复用已有功能的目的。这个原则有一个简短的描述：要尽量使用合成、聚合，尽量不要使用继承。

合成、聚合有如下好处：

新对象存取成分对象的唯一方法是通过成分对象的接口。
这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不到的。
这种复用可以在运行时间内动态进行，新对象可以动态的引用与成分对象类型相同的对象。
合成、聚合可以应用到任何环境中去，而继承只能应用到一些有限环境中去。
导致错误的使用合成、聚合与继承的一个常见原因是错误的把“Has-a”关系当作“Is-a”关系。如果两个类是“Has-a”关系那么应使用合成、聚合，如果是“Is-a”关系那么可使用继承。

迪米特法则

迪米特法则说的是一个对象应该对其它对象有尽可能少的了解。即只与你直接的朋友通信，不要跟陌生人说话。如果需要和陌生人通话，而你的朋友与陌生人是朋友，那么可以将你对陌生人的调用由你的朋友转发，使得某人只知道朋友，不知道陌生人。换言之，某人会认为他所调用的是朋友的方法。

以下条件称为朋友的条件：
当前对象本身。以参量的形式传入到当前对象方法中的对象。当前对象的实例变量直接引用的对象。当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友。
当前对象所创建的对象。
任何一个对象，如果满足上面的条件之一，就是当前对象的朋友，否则就是陌生人。

迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意以下几点：
在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。
在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。在类的设计上，只要有可能，一个类应当设计成不变类。在对其它对象的引用上，一个类对其它对象的引用应该降到最低。

[转载]面向对象的设计原则与目标[总结篇] – 成长的足迹.NET – 博客园.

一、面向对象技术基本概念
面向对象技术基于对象概念，以对象为中心，以类和继承为构造机制，充分利用接口和多态提供灵活性，来认识、理解、刻划客观世界和设计、构建相应的软件系统.

面向对象的特征

– 抽象，先不考虑细节
– 封装，隐藏内部实现
– 继承，复用现有代码
– 多态，改写对象行为

二、面向对象的设计目标
1、可扩展性Extensibility
–容易添加新的功能
2、灵活性Flexibility
–容易添加新的功能代码修改平稳地发生
3、可插入性Pluggability
–容易将一个类抽出去，同时将另一个有同样接口的类加入进来

三、面向对象设计基本的设计原则:
1、针对接口编程，而不是针对实现编程
– 客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。
2、优先使用对象组合，而不是类继承
– 继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。
3、封装变化点
– 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

四、面向对象的设计原则：

1、“开-闭”原则（Open-Closed Principle,OCP）封装的问题 – 对可变性封装
一个软件实体应当对扩展开放，对修改关闭。你添加新功能的时候应该只是向代码集中添加新的代码不应该修改原来的代码。

2、里氏代换原则（Liskov Substitution Principle, LSP）职责的问题 – 如何进行继承
LSP原则要求子类可以无条件的替代父类，子类不能对父类没有暴露的接口进行扩展，客户要调用功能只能通过父类暴露的接口来调用用不能擅自向子类调用。

3、依赖倒转原则（dependence inversion principle, DIP）耦合度问题 – 针对接口编程
依赖倒转原则就是要实现依赖于抽象，抽象不要依赖于实现。要针对接口编程，不要针对实现编程。

4、合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）复用问题 – 尽量使用组合/聚合、尽量不使用继承
在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用这些对象的目的。

5、迪米特法则（Law of Demeter，LoD）耦合度问题 – 不要和陌生人说话
一个软件实体应当尽可能少的与其他实体发生相互作用。迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

6、接口隔离原则（interface separate principle, ISP）职责单一 – 恰当的划分角色和接口
使用多个专门的接口比使用单一的总接口要好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上。
五、目标与原则的关系

可扩展性Extensibility
开/闭原则、里氏替换原则、依赖倒转原则、合成/聚合复用原则

灵活性Flexibility
开/闭原则、Demeter 法则、接口隔离原

可插入性Pluggability
开/闭原则、里氏代换原则、依赖倒转原则、合成/聚合复用原则

.NET平台下分层架构的面向接口思想

(2008-12-16 17:17:13)

转载

标签：

分类：ASP.NET和数据库编程学习

..NET平台下分层架构的面向接口思想
      我们知道，在做大一点的系统应用时（特别是B/S架构），比较好的方法是分层架构。所谓分层架构，是指将系统从职责上分成若干层，每层各司其职，上层依赖下层完成操作。
      在.NET平台上，比较经典的分层架构是三层架构，从下到上依次是：数据访问层、业务逻辑层、表示层。各层职责如下：
      数据访问层：负责与数据源交互，完成数据访问等一系列操作。
      业务逻辑层：完成与系统业务有关的逻辑操作。
      表示层：负责与用户交互、呈现数据等一切与系统表示有关的操作。

      刚才我们说过，分层架构下是向下依赖的（不考虑依赖倒置），也就是业务逻辑层要调用数据访问层完成与数据源有关的操作，而表示层调用业务逻辑层完成业务逻辑工作。但是，表示层对数据访问层是没有依赖的。
      在这个架构中，每一层都不是一个类，而是一个类族，例如，在一个CMS系统中，数据访问层可能会有一系列的类，分别负责用户、文章、评论等业务实体的数据访问操作，而业务逻辑层也一样。如果我们直接依赖，即业务逻辑层实例化数据访问层的类，表示层再实例化业务逻辑层的类，会造成强耦合。如果我想把数据库从SQLServer换成MySQL，则要改变整个业务逻辑层代码，这是个不好的设计。（还记得“开放-关闭”原则吗）所以，一般的做法是，为数据访问层和业务逻辑层分别定义一族接口，业务逻辑层不依赖具体的数据访问层，而是仅依赖数据访问层的接口族，表示层也一样，依赖业务逻辑层的接口族。如此一来，当要更换数据库时，我们就不必改写整个业务逻辑层，因为业务逻辑层里根本没有任何数据访问层中的具体类，而全是通过接口实现的。在.NET中，只要配合配置文件和反射机制，再运用Abstract Factory设计模式，就可以实现“依赖注入”，即在不改动代码的情况下根据配置选择相应的层次组件。这样，我们就可以为不通数据库分别实现数据访问层，也可以编写ORM的数据访问层，甚至是基于XML的，只要实现了数据访问层接口族，就可以和业务逻辑层无缝连接，从而极大提高了软件的灵活性和可维护性。当然要更改业务逻辑层也是一样。
      如果说，前面的例子都是从微观视角讨论接口，那么，这个例子则从宏观视角展现了面向接口编程的内涵和优势。很抱歉在这里不能对这个架构深入讲解，有兴趣的朋友可以参考微软的官方示例.NET PetShop4。（但是请注意，这个示例中业务逻辑层没有定义接口族，而是强耦合于表示层中，这可能是因为考虑到在这个系统中业务逻辑没有更改的可能。另外由于是个示例，不是真正的B2C系统，所以业务逻辑层很简单。）

面向接口编程详解

(2008-12-16 16:33:45)

1.面向接口编程和面向对象编程是什么关系
首先，面向接口编程和面向对象编程并不是平级的，它并不是比面向对象编程更先进的一种独立的编程思想，而是附属于面向对象思想体系，属于其一部分。或者说，它是面向对象编程体系中的思想精髓之一。

2.接口的本质
接口，在表面上是由几个没有主体代码的方法定义组成的集合体，有唯一的名称，可以被类或其他接口所实现（或者也可以说继承）。它在形式上可能是如下的样子：

interface InterfaceName
{
    void Method1();
    void Method2(int para1);
    void Method3(string para2,string para3);
}

3.面向接口编程综述
      通过上文，我想大家对接口和接口的思想内涵有了一个了解，那么什么是面向接口编程呢？我个人的定义是：在系统分析和架构中，分清层次和依赖关系，每个层次不是直接向其上层提供服务（即不是直接实例化在上层中），而是通过定义一组接口，仅向上层暴露其接口功能，上层对于下层仅仅是接口依赖，而不依赖具体类。
      这样做的好处是显而易见的，首先对系统灵活性大有好处。当下层需要改变时，只要接口及接口功能不变，则上层不用做任何修改。甚至可以在不改动上层代码时将下层整个替换掉，就像我们将一个WD的60G硬盘换成一个希捷的160G的硬盘，计算机其他地方不用做任何改动，而是把原硬盘拔下来、新硬盘插上就行了，因为计算机其他部分不依赖具体硬盘，而只依赖一个IDE接口，只要硬盘实现了这个接口，就可以替换上去。从这里看，程序中的接口和现实中的接口极为相似，所以我一直认为，接口（interface）这个词用的真是神似！
      使用接口的另一个好处就是不同部件或层次的开发人员可以并行开工，就像造硬盘的不用等造CPU的，也不用等造显示器的，只要接口一致，设计合理，完全可以并行进行开发，从而提高效率。

      本篇文章先到这里。最后我想再啰嗦一句：面向对象的精髓是模拟现实，这也可以说是我这篇文章的灵魂。所以，多从现实中思考面向对象的东西，对提高系统分析设计能力大有脾益。
      下篇文章，我将用一个实例来展示接口编程的基本方法。
      而第三篇，我将解析经典设计模式中的一些面向接口编程思想，并解析一下.NET分层架构中的面向接口思想。

对本文的补充：
仔细看了各位的回复，非常高兴能和大家一起讨论技术问题。感谢给出肯定的朋友，也要感谢提出意见和质疑的朋友，这促使我更深入思考一些东西，希望能借此进步。在这里我想补充一些东西，以讨论一些回复中比较集中的问题。

1.关于“面向接口编程”中的“接口”与具体面向对象语言中“接口”两个词
看到有朋友提出“面向接口编程”中的“接口”二字应该比单纯编程语言中的interface范围更大。我经过思考，觉得很有道理。这里我写的确实不太合理。我想，面向对象语言中的“接口”是指具体的一种代码结构，例如C#中用interface关键字定义的接口。而“面向接口编程”中的“接口”可以说是一种从软件架构的角度、从一个更抽象的层面上指那种用于隐藏具体底层类和实现多态性的结构部件。从这个意义上说，如果定义一个抽象类，并且目的是为了实现多态，那么我认为把这个抽象类也称为“接口”是合理的。但是用抽象类实现多态合理不合理？在下面第二条讨论。
概括来说，我觉得两个“接口”的概念既相互区别又相互联系。“面向接口编程”中的接口是一种思想层面的用于实现多态性、提高软件灵活性和可维护性的架构部件，而具体语言中的“接口”是将这种思想中的部件具体实施到代码里的手段。

2.关于抽象类与接口
      看到回复中这是讨论的比较激烈的一个问题。很抱歉我考虑不周没有在文章中讨论这个问题。我个人对这个问题的理解如下：
      如果单从具体代码来看，对这两个概念很容易模糊，甚至觉得接口就是多余的，因为单从具体功能来看，除多重继承外（C#，Java中），抽象类似乎完全能取代接口。但是，难道接口的存在是为了实现多重继承？当然不是。我认为，抽象类和接口的区别在于使用动机。使用抽象类是为了代码的复用，而使用接口的动机是为了实现多态性。所以，如果你在为某个地方该使用接口还是抽象类而犹豫不决时，那么可以想想你的动机是什么。
      看到有朋友对IPerson这个接口的质疑，我个人的理解是，IPerson这个接口该不该定义，关键看具体应用中是怎么个情况。如果我们的项目中有Women和Man，都继承Person，而且Women和Man绝大多数方法都相同，只有一个方法DoSomethingInWC（）不同（例子比较粗俗，各位见谅），那么当然定义一个AbstractPerson抽象类比较合理，因为它可以把其他所有方法都包含进去，子类只定义DoSomethingInWC（），大大减少了重复代码量。
      但是，如果我们程序中的Women和Man两个类基本没有共同代码，而且有一个PersonHandle类需要实例化他们，并且不希望知道他们是男是女，而只需把他们当作人看待，并实现多态，那么定义成接口就有必要了。
      总而言之，接口与抽象类的区别主要在于使用的动机，而不在于其本身。而一个东西该定义成抽象类还是接口，要根据具体环境的上下文决定。
      再者，我认为接口和抽象类的另一个区别在于，抽象类和它的子类之间应该是一般和特殊的关系，而接口仅仅是它的子类应该实现的一组规则。（当然，有时也可能存在一般与特殊的关系，但我们使用接口的目的不在这里）如，交通工具定义成抽象类，汽车、飞机、轮船定义成子类，是可以接受的，因为汽车、飞机、轮船都是一种特殊的交通工具。再譬如Icomparable接口，它只是说，实现这个接口的类必须要可以进行比较，这是一条规则。如果Car这个类实现了Icomparable，只是说，我们的Car中有一个方法可以对两个Car的实例进行比较，可能是比哪辆车更贵，也可能比哪辆车更大，这都无所谓，但我们不能说“汽车是一种特殊的可以比较”，这在文法上都不通。

问题的提出

--------------------------------------------------------------------------------
        定义：现在我们要开发一个应用，模拟移动存储设备的读写，即计算机与U盘、MP3、移动硬盘等设备进行数据交换。
      上下文（环境）：已知要实现U盘、MP3播放器、移动硬盘三种移动存储设备，要求计算机能同这三种设备进行数据交换，并且以后可能会有新的第三方的移动存储设备，所以计算机必须有扩展性，能与目前未知而以后可能会出现的存储设备进行数据交换。
      各个存储设备间读、写的实现方法不同，U盘和移动硬盘只有这两个方法，MP3Player还有一个PlayMusic方法。
      名词定义：数据交换={读，写}

看到上面的问题，我想各位脑子中一定有了不少想法，这是个很好解决的问题，很多方案都能达到效果。下面，我列举几个典型的方案。

解决方案列举

--------------------------------------------------------------------------------
方案一：分别定义FlashDisk、MP3Player、MobileHardDisk三个类，

实现各自的Read和Write方法。然后在Computer类中实例化上述三个类，为每个类分别写读、写方法。例如，为FlashDisk写ReadFromFlashDisk、WriteToFlashDisk两个方法。总共六个方法。
      方案二：定义抽象类MobileStorage，在里面写虚方法Read和Write，三个存储设备继承此抽象类，并重写Read和Write方法。Computer类中包含一个类型为MobileStorage的成员变量，并为其编写get/set器，这样Computer中只需要两个方法：ReadData和WriteData，并通过多态性实现不同移动设备的读写。
      方案三：与方案二基本相同，只是不定义抽象类，而是定义接口IMobileStorage，移动存储器类实现此接口。Computer中通过依赖接口IMobileStorage实现多态性。
      方案四：定义接口IReadable和IWritable，两个接口分别只包含Read和Write，然后定义接口IMobileStorage接口继承自IReadable和IWritable，剩下的实现与方案三相同。

      下面，我们来分析一下以上四种方案：
      首先，方案一最直白，实现起来最简单，但是它有一个致命的弱点：可扩展性差。或者说，不符合“开放-关闭原则”（注：意为对扩展开放，对修改关闭）。当将来有了第三方扩展移动存储设备时，必须对Computer进行修改。这就如在一个真实的计算机上，为每一种移动存储设备实现一个不同的插口、并分别有各自的驱动程序。当有了一种新的移动存储设备后，我们就要将计算机大卸八块，然后增加一个新的插口，在编写一套针对此新设备的驱动程序。这种设计显然不可取。
      此方案的另一个缺点在于，冗余代码多。如果有100种移动存储，那我们的Computer中岂不是要至少写200个方法，这是不能接受的！

      我们再来看方案二和方案三，之所以将这两个方案放在一起讨论，是因为他们基本是一个方案（从思想层面上来说），只不过实现手段不同，一个是使用了抽象类，一个是使用了接口，而且最终达到的目的应该是一样的。
      我们先来评价这种方案：首先它解决了代码冗余的问题，因为可以动态替换移动设备，并且都实现了共同的接口，所以不管有多少种移动设备，只要一个Read方法和一个Write方法，多态性就帮我们解决问题了。而对第一个问题，由于可以运行时动态替换，而不必将移动存储类硬编码在Computer中，所以有了新的第三方设备，完全可以替换进去运行。这就是所谓的“依赖接口，而不是依赖与具体类”，不信你看看，Computer类只有一个MobileStorage类型或IMobileStorage类型的成员变量，至于这个变量具体是什么类型，它并不知道，这取决于我们在运行时给这个变量的赋值。如此一来，Computer和移动存储器类的耦合度大大下降。
      那么这里该选抽象类还是接口呢？还记得第一篇文章我对抽象类和接口选择的建议吗？看动机。这里，我们的动机显然是实现多态性而不是为了代码复用，所以当然要用接口。

最后我们再来看一看方案四，它和方案三很类似，只是将“可读”和“可写”两个规则分别抽象成了接口，然后让IMobileStorage再继承它们。这样做，显然进一步提高了灵活性，但是，这有没有设计过度的嫌疑呢？我的观点是：这要看具体情况。如果我们的应用中可能会出现一些类，这些类只实现读方法或只实现写方法，如只读光盘，那么这样做也是可以的。如果我们知道以后出现的东西都是能读又能写的，那这两个接口就没有必要了。其实如果将只读设备的Write方法留空或抛出异常，也可以不要这两个接口。总之一句话：理论是死的，人是活的，一切从现实需要来，防止设计不足，也要防止设计过度。
在这里，我们姑且认为以后的移动存储都是能读又能写的，所以我们选方案三。

实现

--------------------------------------------------------------------------------
下面，我们要将解决方案加以实现。我选择的语言是C#，但是在代码中不会用到C#特有的性质，所以使用其他语言的朋友一样可以参考。

首先编写IMobileStorage接口：
namespace InterfaceExample
{
    public interface IMobileStorage
   {
       void Read();//从自身读数据
       void Write();//将数据写入自身
   }
}
比较简单，只有两个方法，没什么好说的，接下来是三个移动存储设备的具体实现代码：
U盘
namespace InterfaceExample
{
    public class FlashDisk : IMobileStorage
    {
        public void Read()
        {
            Console.WriteLine("Reading from FlashDisk……");
            Console.WriteLine("Read finished!");
        }

        public void Write()
        {
            Console.WriteLine("Writing to FlashDisk……");
            Console.WriteLine("Write finished!");
        }
    }
}
MP3
namespace InterfaceExample
{
    public class MP3Player : IMobileStorage
    {
        public void Read()
        {
            Console.WriteLine("Reading from MP3Player……");
            Console.WriteLine("Read finished!");
        }

        public void Write()
        {
            Console.WriteLine("Writing to MP3Player……");
            Console.WriteLine("Write finished!");
        }

        public void PlayMusic()
        {
            Console.WriteLine("Music is playing……");
        }
    }
}
移动硬盘
namespace InterfaceExample
{
    public class MobileHardDisk : IMobileStorage
    {
        public void Read()
        {
            Console.WriteLine("Reading from MobileHardDisk……");
            Console.WriteLine("Read finished!");
        }

        public void Write()
        {
            Console.WriteLine("Writing to MobileHardDisk……");
            Console.WriteLine("Write finished!");
        }
    }
}

可以看到，它们都实现了IMobileStorage接口，并重写了各自不同的Read和Write方法。下面，我们来写Computer：
namespace InterfaceExample
{
    public class Computer
    {
        private IMobileStorage _usbDrive;

        public IMobileStorage UsbDrive
        {
            get
            {
                return this._usbDrive;
            }
            set
            {
                this._usbDrive = value;
            }
        }

        public Computer()
        {
        }

        public Computer(IMobileStorage usbDrive)
        {
            this.UsbDrive = usbDrive;
        }

        public void ReadData()
        {
            this._usbDrive.Read();
        }

        public void WriteData()
        {
            this._usbDrive.Write();
        }
    }
}
      其中的UsbDrive就是可替换的移动存储设备，之所以用这个名字，是为了让大家觉得直观，就像我们平常使用电脑上的USB插口插拔设备一样。
      OK！下面我们来测试我们的“电脑”和“移动存储设备”是否工作正常。我是用的C#控制台程序，具体代码如下：
namespace InterfaceExample
{
    class Program
    {
        static void Main(string[] args)
        {
            Computer computer = new Computer();
            IMobileStorage mp3Player = new MP3Player();
            IMobileStorage flashDisk = new FlashDisk();
            IMobileStorage mobileHardDisk = new MobileHardDisk();

            Console.WriteLine("I inserted my MP3 Player into my computer and copy some music to it:");
            computer.UsbDrive = mp3Player;
            computer.WriteData();
            Console.WriteLine();

            Console.WriteLine("Well,I also want to copy a great movie to my computer from a mobile hard disk:");
            computer.UsbDrive = mobileHardDisk;
            computer.ReadData();
            Console.WriteLine();

            Console.WriteLine("OK!I have to read some files from my flash disk and copy another file to it:");
            computer.UsbDrive = flashDisk;
            computer.ReadData();
            computer.WriteData();
            Console.ReadLine();
        }
    }
}
      现在编译、运行程序，如果没有问题，将看到如下运行结果：

好的，看来我们的系统工作良好。

后来……

--------------------------------------------------------------------------------
      刚过了一个星期，就有人送来了新的移动存储设备NewMobileStorage，让我测试能不能用，我微微一笑，心想这不是小菜一碟，让我们看看面向接口编程的威力吧！将测试程序修改成如下：
namespace InterfaceExample
{
    class Program
    {
        static void Main(string[] args)
        {
            Computer computer = new Computer();
            IMobileStorage newMobileStorage = new NewMobileStorage();

            Console.WriteLine("Now,I am testing the new mobile storage:");
            computer.UsbDrive = newMobileStorage;
        &nbs

p;   computer.ReadData();
            computer.WriteData();
            Console.ReadLine();
        }
    }
}
编译、运行、看结果：

哈哈，神奇吧，Computer一点都不用改动，就可以使新的设备正常运行。这就是所谓“对扩展开放，对修改关闭”。

      又过了几天，有人通知我说又有一个叫SuperStorage的移动设备要接到我们的Computer上，我心想来吧，管你是“超级存储”还是“特级存储”，我的“面向接口编程大法”把你们统统搞定。
      但是，当设备真的送来，我傻眼了，开发这个新设备的团队没有拿到我们的IMobileStorage接口，自然也没有遵照这个约定。这个设备的读、写方法不叫Read和Write，而是叫rd和wt，这下完了……不符合接口啊，插不上。但是，不要着急，我们回到现实来找找解决的办法。我们一起想想：如果你的Computer上只有USB接口，而有人拿来一个PS/2的鼠标要插上用，你该怎么办？想起来了吧，是不是有一种叫“PS/2-USB”转换器的东西？也叫适配器，可以进行不同接口的转换。对了！程序中也有转换器。
      这里，我要引入一个设计模式，叫“Adapter”。它的作用就如现实中的适配器一样，把接口不一致的两个插件接合起来。由于本篇不是讲设计模式的，而且Adapter设计模式很好理解，所以我就不细讲了，先来看我设计的类图吧：

     如图所示，虽然SuperStorage没有实现IMobileStorage，但我们定义了一个实现IMobileStorage的SuperStorageAdapter，它聚合了一个SuperStorage，并将rd和wt适配为Read和Write，SuperStorageAdapter的具体代码如下：
namespace InterfaceExample
{
    public class SuperStorageAdapter : IMobileStorage
    {
        private SuperStorage _superStorage;

        public SuperStorage SuperStorage
        {
            get
            {
                return this._superStorage;
            }
            set
            {
                this._superStorage = value;
            }
        }

        public void Read()
        {
            this._superStorage.rd();
        }

        public void Write()
        {
            this._superStorage.wt();
        }
    }
}
好，现在我们来测试适配过的新设备，测试代码如下：
namespace InterfaceExample
{
    class Program
    {
        static void Main(string[] args)
        {
            Computer computer = new Computer();
            SuperStorageAdapter superStorageAdapter = new SuperStorageAdapter();
            SuperStorage superStorage = new SuperStorage();
            superStorageAdapter.SuperStorage = superStorage;

            Console.WriteLine("Now,I am testing the new super storage with adapter:");
            computer.UsbDrive = superStorageAdapter;
            computer.ReadData();
            computer.WriteData();
            Console.ReadLine();
        }
    }
}
运行后会得到如下结果：

OK！虽然遇到了一些困难，不过在设计模式的帮助下，我们还是在没有修改Computer任何代码的情况下实现了新设备的运行。

1.从MVC开始
MVC简介：
本文不打算详细解释MVC架构，而是把重点放在其中的面向接口思想上。所以在这里，只对MVC做一个简略的介绍。

MVC是一种用于表示层设计的复合设计模式。M、V、C分别表示模型（Model）、View（视图）、Controller（控制器）。它们的职责如下：
      模型：用于存储应用中的数据及运行逻辑，是应用的实体。
      视图：负责可视部分，用于与用户交互及呈现数据。视图只负责显示，不负责将用户的操作行为解释给模型。
      控制器：负责将用户的行为解释给模型。根据指定的策略和用户的操作，调用模型的逻辑。

关于三者的关系，我画了一张图，大家请看：

      MVC介绍完了，那么可能会有人问，我们的主题呢？面向接口思想呢？其实，MVC中处处都存在面向接口的影子。下面，我对其中几个侧面进行解释。
      1.首先我们可以看到，视图和模型是有直接交互的，也就是上面的4、5两点。但是有一点可能会让你吃惊：它们两个谁也不“认识”谁，即它们相互并不知道对方是做什么的、有什么属性、有什么方法，但是它们能交互。这是怎么做到的呢？因为它们个各知道对方实现了某一个接口。
      此乃面向接口思想一大作用：使相互不认识的类进行交互。这样做是很有好处的，首先它们之间的耦合度大大降低，其次双方都可以进行替换，只要实现了相同的接口，就没有问题。
      打个不太恰当的比喻。我们都知道120这个电话号码，是急救电话。其实120就是个接口，因为当你拨打这个电话时，你不知道那边是哪所医院，甚至不知道那边是不是医院，你只知道电话那头的地方可以救人，也可以说实现了IHelp接口。这样，你通过一个号码可以说同全部的救人机构联系起来了，当有紧急事件，接线控制那边会将你的请求接到最近可用的机构，你就可以最快的得到帮助。
      现在我们假设没有使用面向接口思想，来看看会发生什么恐怖的事情：首先，我家的120号码是绑定在本市第一人民医院的，即当我拨打120时，只能拨通第一人民医院。如果有一天我食物中毒了，急忙拨通了120，但是电话那边告诉我他们医院的救护车都派出去了，我问那怎么接通别家医院的电话，那边的MM很温柔的告诉我，让我打电话给网通公司，然后重新为我布线。于是我吐血而亡……
      言归正传。这里，我要引入一个设计模式，叫观察着（Observer）模式。这个模式大约是这样的：整个模式中有两种实体：观察者和被观察者，它们分别实现一个接口，这里我们姑且叫做IObserver与IObserverSubject。IObserver只有一个方法，例如叫Update，当被观察者状态改变时，调用这个方法，用来通知观察者。IObserverSubject接口有两个方法，都是供观察者调用。一个用来将观察者注册为此被观察者的观察对象，另一个用于将观察者移除。
      一般情况下，一个被观察者对应多个观察者。
      在MVC中，视图是观察者，模型是被观察者，当模型状态改变时，调用所有观察者的Update方法，通知视图模型有变，视图在Update方法里写下响应代码，完成操作。通过这个方法，视图和模型就可以在仅依赖接口的情形下进行交互，而不必强耦合，而且在模型不变的情况下，视图可以随意替换。（只要实现了IObserver）

2. 在MVC中另一个使用接口的地方就是控制器，这里我要首先引入一个设计模式：策略模式（Strategy）。在MVC中，控制器就使用了这个模式。
刚才我说过，视图负责与用户交互，但是，它只负责界面显示部分，至于当用户做了某个操作（如单击某个按钮）后系统应该怎么反应，视图并不负责，它只是将这个动作交给控制器，控制器根据内置的策略，将用户操作翻译成模型的逻辑。这就是说，同一个视图、同一种操作，模型可以做出不同的反应，这取决与控制器的内置策略。所以，我们的系统中可以有很多控制器，它们有不同的策略，当视图希望改变策略时，它可以更换控制器。怎么实现呢？这就需要视图不能和具体控制器耦合，而是要仅依赖一个控制器接口（如IController），并聚合一个IController的实例。当希望更改策略时，可以在系统运行时动态更换Controller，这就是策略模式的实现。

关于MVC的接口思想就先介绍到这里。其实MVC中还有很多地方用到面向接口，由于本文不是专门介绍MVC或设计模式的，所以对用到的模式没有做详解，而是把重点放在其中的面向接口思想上。如果没有设计模式的基础，读上文可能会有些困难，希望各位见谅！我打算在以后专门写文章来解析MVC。

2..NET平台下分层架构的面向接口思想
      我们知道，在做大一点的系统应用时（特别是B/S架构），比较好的方法是分层架构。所谓分层架构，是指将系统从职责上分成若干层，每层各司其职，上层依赖下层完成操作。
      在.NET平台上，比较经典的分层架构是三层架构，从下到上依次是：数据访问层、业务逻辑层、表示层。各层职责如下：
      数据访问层：负责与数据源交互，完成数据访问等一系列操作。
      业务逻辑层：完成与系统业务有关的逻辑操作。
      表示层：负责与用户交互、呈现数据等一切与系统表示有关的操作。

接口在数据访问层的通常用法

(2008-12-16 16:27:41)

我声明一个IUser这样的接口，只有一个方法就是获取用户名称

public interface IUser
{
string getUserName();
}

业务逻辑在使用时只对接口进行操作string UserName=user.getUserName();(user是IUser类型）
好，假设我当前要实现的是对SqlServer进行操作读取用户名称

public class SqlUser:IUser
{
public string getUserName(){.}
}

如果有一天要换成Oracle的话怎么办呢？如果是你的业务逻辑在调用用户名称都是针对接口编程的话，那么很简单，你只要加一个实现类和更改你的配置即可

public class OracleUser:IUser
{
public string getUserName(){.}
}

你的业务逻辑一字也不用动。

**说明一下,通常是这样创建IUser类型:

建立一个具有实际操作的类的实例,然后把该实例显式转换成对应的接口类型,如下:

SqlUser sqluser = new SqlUser();

IUser user = (IUser)sqlUser;

照这样思考,如果改成了Oracle数据库,除了修改实现的类,还要修改以上两行代码,通常的做法是建立一个Factory类,作为中间加工厂,里面是代码较少的静态方法,里面主要实现上面两句.

面向接口编程详解（一）——思想基础

      我想，对于各位使用面向对象编程语言的程序员来说，“接口”这个名词一定不陌生，但是不知各位有没有这样的疑惑：接口有什么用途？它和抽象类有什么区别？能不能用抽象类代替接口呢？而且，作为程序员，一定经常听到“面向接口编程”这个短语，那么它是什么意思？有什么思想内涵？和面向对象编程是什么关系？本文将一一解答这些疑问。

1.面向接口编程和面向对象编程是什么关系
      首先，面向接口编程和面向对象编程并不是平级的，它并不是比面向对象编程更先进的一种独立的编程思想，而是附属于面向对象思想体系，属于其一部分。或者说，它是面向对象编程体系中的思想精髓之一。

2.接口的本质
      接口，在表面上是由几个没有主体代码的方法定义组成的集合体，有唯一的名称，可以被类或其他接口所实现（或者也可以说继承）。它在形式上可能是如下的样子：

interface InterfaceName
{
    void Method1();
    void Method2(int para1);
    void Method3(string para2,string para3);
}

      那么，接口的本质是什么呢？或者说接口存在的意义是什么。我认为可以从以下两个视角考虑：
      1）接口是一组规则的集合，它规定了实现本接口的类或接口必须拥有的一组规则。体现了自然界“如果你是……则必须能……”的理念。
      例如，在自然界中，人都能吃饭，即“如果你是人，则必须能吃饭”。那么模拟到计算机程序中，就应该有一个IPerson（习惯上，接口名由“I”开头）接口，并有一个方法叫Eat（），然后我们规定，每一个表示“人”的类，必须实现IPerson接口，这就模拟了自然界“如果你是人，则必须能吃饭”这条规则。
      从这里，我想各位也能看到些许面向对象思想的东西。面向对象思想的核心之一，就是模拟真实世界，把真实世界中的事物抽象成类，整个程序靠各个类的实例互相通信、互相协作完成系统功能，这非常符合真实世界的运行状况，也是面向对象思想的精髓。
      2）接口是在一定粒度视图上同类事物的抽象表示。注意这里我强调了在一定粒度视图上，因为“同类事物”这个概念是相对的，它因为粒度视图不同而不同。
      例如，在我的眼里，我是一个人，和一头猪有本质区别，我可以接受我和我同学是同类这个说法，但绝不能接受我和一头猪是同类。但是，如果在一个动物学家眼里，我和猪应该是同类，因为我们都是动物，他可以认为“人”和“猪”都实现了IAnimal这个接口，而他在研究动物行为时，不会把我和猪分开对待，而会从“动物”这个较大的粒度上研究，但他会认为我和一棵树有本质区别。
      现在换了一个遗传学家，情况又不同了，因为生物都能遗传，所以在他眼里，我不仅和猪没区别，和一只蚊子、一个细菌、一颗树、一个蘑菇乃至一个SARS病毒都没什么区别，因为他会认为我们都实现了IDescendable这个接口（注：descend vi. 遗传），即我们都是可遗传的东西，他不会分别研究我们，而会将所有生物作为同类进行研究，在他眼里没有人和病毒之分，只有可遗传的物质和不可遗传的物质。但至少，我和一块石头还是有区别的。
      可不幸的事情发生了，某日，地球上出现了一位伟大的人，他叫列宁，他在熟读马克思、恩格斯的辩证唯物主义思想巨著后，颇有心得，于是他下了一个著名的定义：所谓物质，就是能被意识所反映的客观实在。至此，我和一块石头、一丝空气、一条成语和传输手机信号的电磁场已经没什么区别了，因为在列宁的眼里，我们都是可以被意识所反映的客观实在。如果列宁是一名程序员，他会这么说：所谓物质，就是所有同时实现了“IReflectabe”和“IEsse”两个接口的类所生成的实例。（注：reflect v. 反映 esse n. 客观实在）
      也许你会觉得我上面的例子像在瞎掰，但是，这正是接口得以存在的意义。面向对象思想和核心之一叫做多态性，什么叫多态性？说白了就是在某个粒度视图层面上对同类事物不加区别的对待而统一处理。而之所以敢这样做，就是因为有接口的存在。像那个遗传学家，他明白所有生物都实现了IDescendable接口，那只要是生物，一定有Descend（）这个方法，于是他就可以统一研究，而不至于分别研究每一种生物而最终累死。
      可能这里还不能给你一个关于接口本质和作用的直观印象。那么在后文的例子和对几个设计模式的解析中，你将会更直观体验到接口的内涵。

3.面向接口编程综述
      通过上文，我想大家对接口和接口的思想内涵有了一个了解，那么什么是面向接口编程呢？我个人的定义是：在系统分析和架构中，分清层次和依赖关系，每个层次不是直接向其上层提供服务（即不是直接实例化在上层中），而是通过定义一组接口，仅向上层暴露其接口功能，上层对于下层仅仅是接口依赖，而不依赖具体类。
      这样做的好处是显而易见的，首先对系统灵活性大有好处。当下层需要改变时，只要接口及接口功能不变，则上层不用做任何修改。甚至可以在不改动上层代码时将下层整个替换掉，就像我们将一个WD的60G硬盘换成一个希捷的160G的硬盘，计算机其他地方不用做任何改动，而是把原硬盘拔下来、新硬盘插上就行了，因为计算机其他部分不依赖具体硬盘，而只依赖一个IDE接口，只要硬盘实现了这个接口，就可以替换上去。从这里看，程序中的接口和现实中的接口极为相似，所以我一直认为，接口（interface）这个词用的真是神似！
      使用接口的另一个好处就是不同部件或层次的开发人员可以并行开工，就像造硬盘的不用等造CPU的，也不用等造显示器的，只要接口一致，设计合理，完全可以并行进行开发，从而提高效率。

      本篇文章先到这里。最后我想再啰嗦一句：面向对象的精髓是模拟现实，这也可以说是我这篇文章的灵魂。所以，多从现实中思考面向对象的东西，对提高系统分析设计能力大有脾益。
      下篇文章，我将用一个实例来展示接口编程的基本方法。
      而第三篇，我将解析经典设计模式中的一些面向接口编程思想，并解析一下.NET分层架构中的面向接口思想。

对本文的补充：
      仔细看了各位的回复，非常高兴能和大家一起讨论技术问题。感谢给出肯定的朋友，也要感谢提出意见和质疑的朋友，这促使我更深入思考一些东西，希望能借此进步。在这里我想补充一些东西，以讨论一些回复中比较集中的问题。

1.关于“面向接口编程”中的“接口”与具体面向对象语言中“接口”两个词
      看到有朋友提出“面向接口编程”中的“接口”二字应该比单纯编程语言中的interface范围更大。我经过思考，觉得很有道理。这里我写的确实不太合理。我想，面向对象语言中的“接口”是指具体的一种代码结构，例如C#中用interface关键字定义的接口。而“面向接口编程”中的“接口”可以说是一种从软件架构的角度、从一个更抽象的层面上指那种用于隐藏具体底层类和实现多态性的结构部件。从这个意义上说，如果定义一个抽象类，并且目的是为了实现多态，那么我认为把这个抽象类也称为“接口”是合理的。但是用抽象类实现多态合理不合理？在下面第二条讨论。
      概括来说，我觉得两个“接口”的概念既相互区别又相互联系。“面向接口编程”中的接口是一种思想层面的用于实现多态性、提高软件灵活性和可维护性的架构部件，而具体语言中的“接口”是将这种思想中的部件具体实施到代码里的手段。

2.关于抽象类与接口
      看到回复中这是讨论的比较激烈的一个问题。很抱歉我考虑不周没有在文章中讨论这个问题。我个人对这个问题的理解如下：
      如果单从具体代码来看，对这两个概念很容易模糊，甚至觉得接口就是多余的，因为单从具体功能来看，除多重继承外（C#，Java中），抽象类似乎完全能取代接口。但是，难道接口的存在是为了实现多重继承？当然不是。我认为，抽象类和接口的区别在于使用动机。使用抽象类是为了代码的复用，而使用接口的动机是为了实现多态性。所以，如果你在为某个地方该使用接口还是抽象类而犹豫不决时，那么可以想想你的动机是什么。
      看到有朋友对IPerson这个接口的质疑，我个人的理解是，IPerson这个接口该不该定义，关键看具体应用中是怎么个情况。如果我们的项目中有Women和Man，都继承Person，而且Women和Man绝大多数方法都相同，只有一个方法DoSomethingInWC（）不同（例子比较粗俗，各位见谅），那么当然定义一个AbstractPerson抽象类比较合理，因为它可以把其他所有方法都包含进去，子类只定义DoSomethingInWC（），大大减少了重复代码量。
      但是，如果我们程序中的Women和Man两个类基本没有共同代码，而且有一个PersonHandle类需要实例化他们，并且不希望知道他们是男是女，而只需把他们当作人看待，并实现多态，那么定义成接口就有必要了。
      总而言之，接口与抽象类的区别主要在于使用的动机，而不在于其本身。而一个东西该定义成抽象类还是接口，要根据具体环境的上下文决定。
      再者，我认为接口和抽象类的另一个区别在于，抽象类和它的子类之间应该是一般和特殊的关系，而接口仅仅是它的子类应该实现的一组规则。（当然，有时也可能存在一般与特殊的关系，但我们使用接口的目的不在这里）如，交通工具定义成抽象类，汽车、飞机、轮船定义成子类，是可以接受的，因为汽车、飞机、轮船都是一种特殊的交通工具。再譬如Icomparable接口，它只是说，实现这个接口的类必须要可以进行比较，这是一条规则。如果Car这个类实现了Icomparable，只是说，我们的Car中有一个方法可以对两个Car的实例进行比较，可能是比哪辆车更贵，也可能比哪辆车更大，这都无所谓，但我们不能说“汽车是一种特殊的可以比较”，这在文法上都不通。

面向接口编程详解（二）——编程实例

问题的提出

       定义：现在我们要开发一个应用，模拟移动存储设备的读写，即计算机与U盘、MP3、移动硬盘等设备进行数据交换。
      上下文（环境）：已知要实现U盘、MP3播放器、移动硬盘三种移动存储设备，要求计算机能同这三种设备进行数据交换，并且以后可能会有新的第三方的移动存储设备，所以计算机必须有扩展性，能与目前未知而以后可能会出现的存储设备进行数据交换。
      各个存储设备间读、写的实现方法不同，U盘和移动硬盘只有这两个方法，MP3Player还有一个PlayMusic方法。
      名词定义：数据交换={读，写}

      看到上面的问题，我想各位脑子中一定有了不少想法，这是个很好解决的问题，很多方案都能达到效果。下面，我列举几个典型的方案。

解决方案列举

      方案一：分别定义FlashDisk、MP3Player、MobileHardDisk三个类，实现各自的Read和Write方法。然后在Computer类中实例化上述三个类，为每个类分别写读、写方法。例如，为FlashDisk写ReadFromFlashDisk、WriteToFlashDisk两个方法。总共六个方法。
      方案二：定义抽象类MobileStorage，在里面写虚方法Read和Write，三个存储设备继承此抽象类，并重写Read和Write方法。Computer类中包含一个类型为MobileStorage的成员变量，并为其编写get/set器，这样Computer中只需要两个方法：ReadData和WriteData，并通过多态性实现不同移动设备的读写。
      方案三：与方案二基本相同，只是不定义抽象类，而是定义接口IMobileStorage，移动存储器类实现此接口。Computer中通过依赖接口IMobileStorage实现多态性。
      方案四：定义接口IReadable和IWritable，两个接口分别只包含Read和Write，然后定义接口IMobileStorage接口继承自IReadable和IWritable，剩下的实现与方案三相同。

      下面，我们来分析一下以上四种方案：
      首先，方案一最直白，实现起来最简单，但是它有一个致命的弱点：可扩展性差。或者说，不符合“开放-关闭原则”（注：意为对扩展开放，对修改关闭）。当将来有了第三方扩展移动存储设备时，必须对Computer进行修改。这就如在一个真实的计算机上，为每一种移动存储设备实现一个不同的插口、并分别有各自的驱动程序。当有了一种新的移动存储设备后，我们就要将计算机大卸八块，然后增加一个新的插口，在编写一套针对此新设备的驱动程序。这种设计显然不可取。
      此方案的另一个缺点在于，冗余代码多。如果有100种移动存储，那我们的Computer中岂不是要至少写200个方法，这是不能接受的！

      我们再来看方案二和方案三，之所以将这两个方案放在一起讨论，是因为他们基本是一个方案（从思想层面上来说），只不过实现手段不同，一个是使用了抽象类，一个是使用了接口，而且最终达到的目的应该是一样的。
      我们先来评价这种方案：首先它解决了代码冗余的问题，因为可以动态替换移动设备，并且都实现了共同的接口，所以不管有多少种移动设备，只要一个Read方法和一个Write方法，多态性就帮我们解决问题了。而对第一个问题，由于可以运行时动态替换，而不必将移动存储类硬编码在Computer中，所以有了新的第三方设备，完全可以替换进去运行。这就是所谓的“依赖接口，而不是依赖与具体类”，不信你看看，Computer类只有一个MobileStorage类型或IMobileStorage类型的成员变量，至于这个变量具体是什么类型，它并不知道，这取决于我们在运行时给这个变量的赋值。如此一来，Computer和移动存储器类的耦合度大大下降。
      那么这里该选抽象类还是接口呢？还记得第一篇文章我对抽象类和接口选择的建议吗？看动机。这里，我们的动机显然是实现多态性而不是为了代码复用，所以当然要用接口。

      最后我们再来看一看方案四，它和方案三很类似，只是将“可读”和“可写”两个规则分别抽象成了接口，然后让IMobileStorage再继承它们。这样做，显然进一步提高了灵活性，但是，这有没有设计过度的嫌疑呢？我的观点是：这要看具体情况。如果我们的应用中可能会出现一些类，这些类只实现读方法或只实现写方法，如只读光盘，那么这样做也是可以的。如果我们知道以后出现的东西都是能读又能写的，那这两个接口就没有必要了。其实如果将只读设备的Write方法留空或抛出异常，也可以不要这两个接口。总之一句话：理论是死的，人是活的，一切从现实需要来，防止设计不足，也要防止设计过度。
      在这里，我们姑且认为以后的移动存储都是能读又能写的，所以我们选方案三。

实现

下面，我们要将解决方案加以实现。我选择的语言是C#，但是在代码中不会用到C#特有的性质，所以使用其他语言的朋友一样可以参考。

首先编写IMobileStorage接口：

1namespace InterfaceExample
2{
3    public interface IMobileStorage
4    {
5        void Read();//从自身读数据
6        void Write();//将数据写入自身
7    }
8}

比较简单，只有两个方法，没什么好说的，接下来是三个移动存储设备的具体实现代码：
U盘

1namespace InterfaceExample
2{
3    public class FlashDisk : IMobileStorage
4    {
5        public void Read()
6        {
7            Console.WriteLine("Reading from FlashDisk……");
8            Console.WriteLine("Read finished!");
9        }
10
11        public void Write()
12        {
13            Console.WriteLine("Writing to FlashDisk……");
14            Console.WriteLine("Write finished!");
15        }
16    }
17}

MP3

1namespace InterfaceExample
2{
3    public class MP3Player : IMobileStorage
4    {
5        public void Read()
6        {
7            Console.WriteLine("Reading from MP3Player……");
8            Console.WriteLine("Read finished!");
9        }
10
11        public void Write()
12        {
13            Console.WriteLine("Writing to MP3Player……");
14            Console.WriteLine("Write finished!");
15        }
16
17        public void PlayMusic()
18        {
19            Console.WriteLine("Music is playing……");
20        }
21    }
22}

移动硬盘

1namespace InterfaceExample
2{
3    public class MobileHardDisk : IMobileStorage
4    {
5        public void Read()
6        {
7            Console.WriteLine("Reading from MobileHardDisk……");
8            Console.WriteLine("Read finished!");
9        }
10
11        public void Write()
12        {
13            Console.WriteLine("Writing to MobileHardDisk……");
14            Console.WriteLine("Write finished!");
15        }
16    }
17}

可以看到，它们都实现了IMobileStorage接口，并重写了各自不同的Read和Write方法。下面，我们来写Computer：

1namespace InterfaceExample
2{
3    public class Computer
4    {
5        private IMobileStorage _usbDrive;
6
7        public IMobileStorage UsbDrive
8        {
9            get
10            {
11                return this._usbDrive;
12            }
13            set
14            {
15                this._usbDrive = value;
16            }
17        }
18
19        public Computer()
20        {
21        }
22
23        public Computer(IMobileStorage usbDrive)
24        {
25            this.UsbDrive = usbDrive;
26        }
27
28        public void ReadData()
29        {
30            this._usbDrive.Read();
31        }
32
33        public void WriteData()
34        {
35            this._usbDrive.Write();
36        }
37    }
38}

其中的UsbDrive就是可替换的移动存储设备，之所以用这个名字，是为了让大家觉得直观，就像我们平常使用电脑上的USB插口插拔设备一样。
OK！下面我们来测试我们的“电脑”和“移动存储设备”是否工作正常。我是用的C#控制台程序，具体代码如下：

1namespace InterfaceExample
2{
3    class Program
4    {
5        static void Main(string[] args)
6        {
7            Computer computer = new Computer();
8            IMobileStorage mp3Player = new MP3Player();
9            IMobileStorage flashDisk = new FlashDisk();
10            IMobileStorage mobileHardDisk = new MobileHardDisk();
11
12            Console.WriteLine("I inserted my MP3 Player into my computer and copy some music to it:");
13            computer.UsbDrive = mp3Player;
14            computer.WriteData();
15            Console.WriteLine();
16
17            Console.WriteLine("Well,I also want to copy a great movie to my computer from a mobile hard disk:");
18            computer.UsbDrive = mobileHardDisk;
19            computer.ReadData();
20            Console.WriteLine();
21
22            Console.WriteLine("OK!I have to read some files from my flash disk and copy another file to it:");
23            computer.UsbDrive = flashDisk;
24            computer.ReadData();
25            computer.WriteData();
26            Console.ReadLine();
27        }
28    }
29}

现在编译、运行程序，如果没有问题，将看到如下运行结果：

好的，看来我们的系统工作良好。

后来……

刚过了一个星期，就有人送来了新的移动存储设备NewMobileStorage，让我测试能不能用，我微微一笑，心想这不是小菜一碟，让我们看看面向接口编程的威力吧！将测试程序修改成如下：

1namespace InterfaceExample
2{
3    class Program
4    {
5        static void Main(string[] args)
6        {
7            Computer computer = new Computer();
8            IMobileStorage newMobileStorage = new NewMobileStorage();
9
10            Console.WriteLine("Now,I am testing the new mobile storage:");
11            computer.UsbDrive = newMobileStorage;
12            computer.ReadData();
13            computer.WriteData();
14            Console.ReadLine();
15        }
16    }
17}

编译、运行、看结果：

      哈哈，神奇吧，Computer一点都不用改动，就可以使新的设备正常运行。这就是所谓“对扩展开放，对修改关闭”。

      又过了几天，有人通知我说又有一个叫SuperStorage的移动设备要接到我们的Computer上，我心想来吧，管你是“超级存储”还是“特级存储”，我的“面向接口编程大法”把你们统统搞定。
      但是，当设备真的送来，我傻眼了，开发这个新设备的团队没有拿到我们的IMobileStorage接口，自然也没有遵照这个约定。这个设备的读、写方法不叫Read和Write，而是叫rd和wt，这下完了……不符合接口啊，插不上。但是，不要着急，我们回到现实来找找解决的办法。我们一起想想：如果你的Computer上只有USB接口，而有人拿来一个PS/2的鼠标要插上用，你该怎么办？想起来了吧，是不是有一种叫“PS/2-USB”转换器的东西？也叫适配器，可以进行不同接口的转换。对了！程序中也有转换器。
      这里，我要引入一个设计模式，叫“Adapter”。它的作用就如现实中的适配器一样，把接口不一致的两个插件接合起来。由于本篇不是讲设计模式的，而且Adapter设计模式很好理解，所以我就不细讲了，先来看我设计的类图吧：

      如图所示，虽然SuperStorage没有实现IMobileStorage，但我们定义了一个实现IMobileStorage的SuperStorageAdapter，它聚合了一个SuperStorage，并将rd和wt适配为Read和Write，SuperStorageAdapter的具体代码如下：

1namespace InterfaceExample
2{
3    public class SuperStorageAdapter : IMobileStorage
4    {
5        private SuperStorage _superStorage;
6
7        public SuperStorage SuperStorage
8        {
9            get
10            {
11                return this._superStorage;
12            }
13            set
14            {
15                this._superStorage = value;
16            }
17        }
18
19        public void Read()
20        {
21            this._superStorage.rd();
22        }
23
24        public void Write()
25        {
26            this._superStorage.wt();
27        }
28    }
29}

好，现在我们来测试适配过的新设备，测试代码如下：

1namespace InterfaceExample
2{
3    class Program
4    {
5        static void Main(string[] args)
6        {
7            Computer computer = new Computer();
8            SuperStorageAdapter superStorageAdapter = new SuperStorageAdapter();
9            SuperStorage superStorage = new SuperStorage();
10            superStorageAdapter.SuperStorage = superStorage;
11
12            Console.WriteLine("Now,I am testing the new super storage with adapter:");
13            computer.UsbDrive = superStorageAdapter;
14            computer.ReadData();
15            computer.WriteData();
16            Console.ReadLine();
17        }
18    }
19}

运行后会得到如下结果：

OK！虽然遇到了一些困难，不过在设计模式的帮助下，我们还是在没有修改Computer任何代码的情况下实现了新设备的运行。
好了，理论在第一篇讲得足够多了，所以这里我就不多讲了。希望各位朋友结合第一篇的理论和这个例子，仔细思考面向接口的问题。当然，不要忘了结合现实。

面向接口编程详解（三）——模式研究

      通过前面两篇，我想各位朋友对“面向接口编程”的思想有了一定认识，并通过第二篇的例子，获得了一定的直观印象。但是，第二篇中的例子旨在展示面向接口编程的实现方法，比较简单，不能体现出面向接口编程的优势和这种思想的内涵。那么，这一篇作为本系列的终结篇，将通过分析几个比较有深度的模式或架构，解析隐藏其背后的面向接口思想。这篇我将要分析的分别是MVC模式和.NET平台的分层架构。
      这篇的内容可能会比较抽象，望谅解。

1.从MVC开始
MVC简介：
      本文不打算详细解释MVC架构，而是把重点放在其中的面向接口思想上。所以在这里，只对MVC做一个简略的介绍。
      MVC是一种用于表示层设计的复合设计模式。M、V、C分别表示模型（Model）、View（视图）、Controller（控制器）。它们的职责如下：
      模型：用于存储应用中的数据及运行逻辑，是应用的实体。
      视图：负责可视部分，用于与用户交互及呈现数据。视图只负责显示，不负责将用户的操作行为解释给模型。
      控制器：负责将用户的行为解释给模型。根据指定的策略和用户的操作，调用模型的逻辑。

      关于三者的关系，我画了一张图，大家请看：

      它们之间的交互有以下几种：
      1.当用户在视图上做任何需要调用模型的操作时，它的请求将被控制器截获。
      2.控制器按照自身指定的策略，将用户行为翻译成模型操作，调用模型相应逻辑实现。
      3.控制器可能会在接到视图操作时，指定视图做某些改变。
      4.当模型的状态发生改变时，将通过某种方式通知视图。
      5.视图可以从模型获取状态，从而改变自己的显示。

      MVC介绍完了，那么可能会有人问，我们的主题呢？面向接口思想呢？其实，MVC中处处都存在面向接口的影子。下面，我对其中几个侧面进行解释。
      1.首先我们可以看到，视图和模型是有直接交互的，也就是上面的4、5两点。但是有一点可能会让你吃惊：它们两个谁也不“认识”谁，即它们相互并不知道对方是做什么的、有什么属性、有什么方法，但是它们能交互。这是怎么做到的呢？因为它们个各知道对方实现了某一个接口。
      此乃面向接口思想一大作用：使相互不认识的类进行交互。这样做是很有好处的，首先它们之间的耦合度大大降低，其次双方都可以进行替换，只要实现了相同的接口，就没有问题。
      打个不太恰当的比喻。我们都知道120这个电话号码，是急救电话。其实120就是个接口，因为当你拨打这个电话时，你不知道那边是哪所医院，甚至不知道那边是不是医院，你只知道电话那头的地方可以救人，也可以说实现了IHelp接口。这样，你通过一个号码可以说同全部的救人机构联系起来了，当有紧急事件，接线控制那边会将你的请求接到最近可用的机构，你就可以最快的得到帮助。
      现在我们假设没有使用面向接口思想，来看看会发生什么恐怖的事情：首先，我家的120号码是绑定在本市第一人民医院的，即当我拨打120时，只能拨通第一人民医院。如果有一天我食物中毒了，急忙拨通了120，但是电话那边告诉我他们医院的救护车都派出去了，我问那怎么接通别家医院的电话，那边的MM很温柔的告诉我，让我打电话给网通公司，然后重新为我布线。于是我吐血而亡……
      言归正传。这里，我要引入一个设计模式，叫观察着（Observer）模式。这个模式大约是这样的：整个模式中有两种实体：观察者和被观察者，它们分别实现一个接口，这里我们姑且叫做IObserver与IObserverSubject。IObserver只有一个方法，例如叫Update，当被观察者状态改变时，调用这个方法，用来通知观察者。IObserverSubject接口有两个方法，都是供观察者调用。一个用来将观察者注册为此被观察者的观察对象，另一个用于将观察者移除。
      一般情况下，一个被观察者对应多个观察者。
      在MVC中，视图是观察者，模型是被观察者，当模型状态改变时，调用所有观察者的Update方法，通知视图模型有变，视图在Update方法里写下响应代码，完成操作。通过这个方法，视图和模型就可以在仅依赖接口的情形下进行交互，而不必强耦合，而且在模型不变的情况下，视图可以随意替换。（只要实现了IObserver）

      2. 在MVC中另一个使用接口的地方就是控制器，这里我要首先引入一个设计模式：策略模式（Strategy）。在MVC中，控制器就使用了这个模式。
      刚才我说过，视图负责与用户交互，但是，它只负责界面显示部分，至于当用户做了某个操作（如单击某个按钮）后系统应该怎么反应，视图并不负责，它只是将这个动作交给控制器，控制器根据内置的策略，将用户操作翻译成模型的逻辑。这就是说，同一个视图、同一种操作，模型可以做出不同的反应，这取决与控制器的内置策略。所以，我们的系统中可以有很多控制器，它们有不同的策略，当视图希望改变策略时，它可以更换控制器。怎么实现呢？这就需要视图不能和具体控制器耦合，而是要仅依赖一个控制器接口（如IController），并聚合一个IController的实例。当希望更改策略时，可以在系统运行时动态更换Controller，这就是策略模式的实现。

      关于MVC的接口思想就先介绍到这里。其实MVC中还有很多地方用到面向接口，由于本文不是专门介绍MVC或设计模式的，所以对用到的模式没有做详解，而是把重点放在其中的面向接口思想上。如果没有设计模式的基础，读上文可能会有些困难，希望各位见谅！我打算在以后专门写文章来解析MVC。

2..NET平台下分层架构的面向接口思想
      我们知道，在做大一点的系统应用时（特别是B/S架构），比较好的方法是分层架构。所谓分层架构，是指将系统从职责上分成若干层，每层各司其职，上层依赖下层完成操作。
      在.NET平台上，比较经典的分层架构是三层架构，从下到上依次是：数据访问层、业务逻辑层、表示层。各层职责如下：
      数据访问层：负责与数据源交互，完成数据访问等一系列操作。
      业务逻辑层：完成与系统业务有关的逻辑操作。
      表示层：负责与用户交互、呈现数据等一切与系统表示有关的操作。

      刚才我们说过，分层架构下是向下依赖的（不考虑依赖倒置），也就是业务逻辑层要调用数据访问层完成与数据源有关的操作，而表示层调用业务逻辑层完成业务逻辑工作。但是，表示层对数据访问层是没有依赖的。
      在这个架构中，每一层都不是一个类，而是一个类族，例如，在一个CMS系统中，数据访问层可能会有一系列的类，分别负责用户、文章、评论等业务实体的数据访问操作，而业务逻辑层也一样。如果我们直接依赖，即业务逻辑层实例化数据访问层的类，表示层再实例化业务逻辑层的类，会造成强耦合。如果我想把数据库从SQLServer换成MySQL，则要改变整个业务逻辑层代码，这是个不好的设计。（还记得“开放-关闭”原则吗）所以，一般的做法是，为数据访问层和业务逻辑层分别定义一族接口，业务逻辑层不依赖具体的数据访问层，而是仅依赖数据访问层的接口族，表示层也一样，依赖业务逻辑层的接口族。如此一来，当要更换数据库时，我们就不必改写整个业务逻辑层，因为业务逻辑层里根本没有任何数据访问层中的具体类，而全是通过接口实现的。在.NET中，只要配合配置文件和反射机制，再运用Abstract Factory设计模式，就可以实现“依赖注入”，即在不改动代码的情况下根据配置选择相应的层次组件。这样，我们就可以为不通数据库分别实现数据访问层，也可以编写ORM的数据访问层，甚至是基于XML的，只要实现了数据访问层接口族，就可以和业务逻辑层无缝连接，从而极大提高了软件的灵活性和可维护性。当然要更改业务逻辑层也是一样。
      如果说，前面的例子都是从微观视角讨论接口，那么，这个例子则从宏观视角展现了面向接口编程的内涵和优势。很抱歉在这里不能对这个架构深入讲解，有兴趣的朋友可以参考微软的官方示例.NET PetShop4。（但是请注意，这个示例中业务逻辑层没有定义接口族，而是强耦合于表示层中，这可能是因为考虑到在这个系统中业务逻辑没有更改的可能。另外由于是个示例，不是真正的B2C系统，所以业务逻辑层很简单。）

      好了，本系列文章就到这里。希望各位朋友通过这三篇文章，能对“面向接口编程”有一定的了解。当然，我只是起到一个抛砖引玉的作用，其真正的内涵和精髓，还需要各位从实践中慢慢认识。还有，就是面向接口思想不是孤立的，它和设计模式等内容都是面向对象大系中的精华，而且是相互渗透、相互联系的。其实，很多设计模式就是面向接口思想的体现。我们应该把这些放在一起学习，从而真正提供自己的面向对象思考能力和实战能力。