面向对象--接口与抽象类、对象和接口(通俗讲解).doc

面向对象--接口与抽象类的恩恩怨怨

接口与抽象类是面向对象编程中两个非常重要的角色，二者各自起着非常重要的作用。但是很多初学的朋友往往会对使用接口还是抽象类存在的很大的迷惑。就我自己的一点心得，发表一下拙见。

面向对象的一些回顾：

面向对象世界中有一个古老的法则：接口隔离原则，指的是不要把多个功能全部都集中在一个接口里面。接口实现的功能要相对单一；衍生开来可以得到另外一个结论：对一组或者称一系列功能的实现，尽量定义相对功能单一的小模块来实现这一组功能。这其实也是解耦和的体现。

那这跟我们的接口和抽象类有什么关系呢？那又得摆出另外一个法则：依赖倒置原则，针对接口编程而不是针对实现编程。

说到这，又会有一个新的问题蹦出来，这是自相矛盾啊，既然要针对接口编程还要抽象类干吗使？我们经常说面向对象，面向对象是来源于生活的。是人们要把对现实世界中的一系列方法论应用到程序设计当中来。从对象这一概念的引入我们就可以揣摩这一点。人类社会中有很多对象的概念，人、车、物体。不幸的是用程序来实现这些对象比在概念上定义对象要难很多。
（如果能达成这一共识，您可以继续往下看，否则就请看官您移步至留言讨论吧）

MS给出开发者的建议是，用抽象类来实现接口。子类再继承基类。

实例说明：

为什么要这么建议？OK，我们试着结合实际来说明一下这个问题吧。我们要造车。这个车有个基本的属性就是能移动、还必须有轮子。那我们就设计一个接口

1publicinterfaceICar
2{
3stringWheel
4{
5get;
6set;
7}
8voidMove();
9}
10

接下来的事情，就是实现了。造什么车都行，继承一下就行。随着科技的发展，我们的车想要飞了。此时当然不能修改这个接口，因为要遵循开闭原则。为什么要遵循？我们可以想一下，人坐上飞机能飞上天。但是也没见谁认为人有会飞这个特性的。那也好办，不许修改，那我再加一个接口。

1interfaceIFlyable
2{
3voidFly();
4}
5
好，我们的飞行汽车最后应该是这样的。

1classFlyCar:ICar,IAerocraft
2{
3privatestringwheel=string.Empty;
4
5publicvoidFly()
6{
7Console.WriteLine("{0}车飞起来了",this.wheel);
8}
9publicstringEngine
10{
11get
12{
13returnwheel;
14}
15set
16{
17wheel=value;
18}
19}
20
21publicvoidMove()
22{
23Console.WriteLine("{0}轮车在走",this.wheel);
24}
25}
26
看起来很不错，车能飞能走了。那它现在他的祖宗到底车还是飞行器呢？我们自己在心里辩论一下吧。估计不是很容易辩清楚。
我们前面说过，面向对象的思想来源于现实生活。如果把这组例子引入到现实中来，造会飞的汽车。肯定是要在原有的汽车上面下功夫。比如你装上喷气动力装置，或者装上翅膀。这只属于扩展功能，而不能说是继承基类。但上面的例子可以明显的看出，我们的飞行汽车已经成了杂交品种。分不出到底是车还是飞行器了。这里就可以知道为什么C#和JAVA都不支持多重继承基类了。避免杂交，减少耦合。

上面把车定义成接口并不完美，我们知道，一辆正常的车肯定能移动。这是天生的本质，不需要任何实现。但是上面还需要子类来实现这个功能。从这一点其实可以衍生出很多问题来。我们这里不做过多讨论。

重新设计这个系统。我们可以把移动，飞行都看成是一种行为。我们的车本身拥有Move这个行为，是构成车基类的基本要素。

1interfaceIMoveable
2{
3voidMove();
4}
5interfaceIFlyable
6{
7voidFly();
8}
9publicabstractclassCar:IMoveable
10{
11publicabstractstringWheel
12{
13get;
14set;
15}
16publicvirtualvoidMove()
17{
18Console.WriteLine("车移动了");
19}
20}
21publicsealedclassFlyCar:Car,IFlyable
22{
23privatestringwheel=string.Empty;
24publicoverridestringWheel
25{
26get
27{
28returnwheel;
29}
30set
31{
32wheel=value;
33}
34}
35
36publicvoidFly