深入继承之抽象类和接口综合分析及完整案列解说(一)
首先感谢园里的一位前辈anytao.cnblogs.com ,他对面向抽象类和接口编程作出比较完善的总结.下面的总结是直接Copy他的原话.
一.相同点
● 都不能被直接实例化,都可以通过继承实现其抽象方法。
● 都是面向抽象编程的技术基础,实现了诸多的设计模式。
● 都是面向抽象编程的技术基础,实现了诸多的设计模式。
二.不同点
● 接口支持多继承;抽象类不能实现多继承。
● 接口只能定义抽象规则;抽象类既可以定义规则,还可能提供已实现的成员。
● 接口是一组行为规范;抽象类是一个不完全的类,着重族的概念。
● 接口可以用于支持回调;抽象类不能实现回调,因为继承不支持。
● 接口只包含方法、属性、索引器、事件的签名,但不能定义字段和包含实现的方法;抽象类可以定义字段、属性、包含有
实现的方法。
● 接口可以作用于值类型和引用类型;抽象类只能作用于引用类型。例如,Struct就可以继承接口,而不能继承类。
● 接口只能定义抽象规则;抽象类既可以定义规则,还可能提供已实现的成员。
● 接口是一组行为规范;抽象类是一个不完全的类,着重族的概念。
● 接口可以用于支持回调;抽象类不能实现回调,因为继承不支持。
● 接口只包含方法、属性、索引器、事件的签名,但不能定义字段和包含实现的方法;抽象类可以定义字段、属性、包含有
实现的方法。
● 接口可以作用于值类型和引用类型;抽象类只能作用于引用类型。例如,Struct就可以继承接口,而不能继承类。
通过相同与不同的比较,我们只能说接口和抽象类,各有所长,但无优略。在实际的编程实践中,我们要视具体情况来酌情量才,但是以下的经验和积累,或许能给大家一些启示,除了我的一些积累之外,很多都来源于经典,我相信经得起考验。所以在规则与场合中,我们学习这些经典,最重要的是学以致用,当然我将以一家之言博大家之笑,看官请继续。
三.规则与场合
● 请记住,面向对象思想的一个最重要的原则就是:面向接口编程。
● 借助接口和抽象类,23个设计模式中的很多思想被巧妙的实现了,我认为其精髓简单说来就是:面向抽象编程。
● 抽象类应主要用于关系密切的对象,而接口最适合为不相关的类提供通用功能。
● 接口着重于CAN-DO关系类型,而抽象类则偏重于IS-A式的关系;
● 接口多定义对象的行为;抽象类多定义对象的属性;
● 接口定义可以使用public、protected、internal 和private修饰符,但是几乎所有的接口都定义为public,原因就不必
多说了。
● “接口不变”,是应该考虑的重要因素。所以,在由接口增加扩展时,应该增加新的接口,而不能更改现有接口。
● 尽量将接口设计成功能单一的功能块,以.NET Framework为例,IDisposable、IDisposable、IComparable、
IEquatable、IEnumerable等都只包含一个公共方法。
● 接口名称前面的大写字母“I”是一个约定,正如字段名以下划线开头一样,请坚持这些原则。
● 在接口中,所有的方法都默认为public。
● 如果预计会出现版本问题,可以创建“抽象类”。例如,创建了狗(Dog)、鸡(Chicken)和鸭(Duck),那么应该
考虑抽象出动物(Animal)来应对以后可能出现风马牛的事情。而向接口中添加新成员则会强制要求修改所有派生类,并
重新编译,所以版本式的问题最好以抽象类来实现。
● 从抽象类派生的非抽象类必须包括继承的所有抽象方法和抽象访问器的实实现。
● 对抽象类不能使用new关键字,也不能被密封,原因是抽象类不能被实例化。
● 在抽象方法声明中不能使用 static 或 virtual 修饰符。
● 借助接口和抽象类,23个设计模式中的很多思想被巧妙的实现了,我认为其精髓简单说来就是:面向抽象编程。
● 抽象类应主要用于关系密切的对象,而接口最适合为不相关的类提供通用功能。
● 接口着重于CAN-DO关系类型,而抽象类则偏重于IS-A式的关系;
● 接口多定义对象的行为;抽象类多定义对象的属性;
● 接口定义可以使用public、protected、internal 和private修饰符,但是几乎所有的接口都定义为public,原因就不必
多说了。
● “接口不变”,是应该考虑的重要因素。所以,在由接口增加扩展时,应该增加新的接口,而不能更改现有接口。
● 尽量将接口设计成功能单一的功能块,以.NET Framework为例,IDisposable、IDisposable、IComparable、
IEquatable、IEnumerable等都只包含一个公共方法。
● 接口名称前面的大写字母“I”是一个约定,正如字段名以下划线开头一样,请坚持这些原则。
● 在接口中,所有的方法都默认为public。
● 如果预计会出现版本问题,可以创建“抽象类”。例如,创建了狗(Dog)、鸡(Chicken)和鸭(Duck),那么应该
考虑抽象出动物(Animal)来应对以后可能出现风马牛的事情。而向接口中添加新成员则会强制要求修改所有派生类,并
重新编译,所以版本式的问题最好以抽象类来实现。
● 从抽象类派生的非抽象类必须包括继承的所有抽象方法和抽象访问器的实实现。
● 对抽象类不能使用new关键字,也不能被密封,原因是抽象类不能被实例化。
● 在抽象方法声明中不能使用 static 或 virtual 修饰符。
正所谓真理是大家看出来的,所以将原子里有创新性的观点潜列于此,一是感谢大家的共享,二是完善一家之言的不足,希望能够将领域域形成知识,受用于我,受用于众。
以前在园字里看过很多前辈对抽象类和接口的探讨,结论是各有千秋,言之不尽。其中我最有印象的是dunai和shenfx的总结:
● dunai:抽象类是提取具体类的公因式,而接口是为了将一些不相关的类“杂凑”成一个共同的群体。至于他们在各个语言中
的句法,语言细节并不是我关心的重点。
● shenfx:当在差异较大的对象间寻求功能上的共性时,使用接口;当在共性较多的对象间寻求功能上的差异时,使用抽象类。
的句法,语言细节并不是我关心的重点。
● shenfx:当在差异较大的对象间寻求功能上的共性时,使用接口;当在共性较多的对象间寻求功能上的差异时,使用抽象类。
MSDN对抽象类和接口又是怎么解说的呢?下面是我在MSDN上Copy的建议:
● 如果预计要创建组件的多个版本,则创建抽象类。抽象类提供简单易行的方法来控制组件版本。通过更新基类,所有继承类都
随更改自动更新。另一方面,接口一旦创建就不能更改。如果需要接口的新版本,必须创建一个全新的接口。
● 如果创建的功能将在大范围的全异对象间使用,则使用接口。抽象类应主要用于关系密切的对象,而接口最适合为不相关的类
提供通用功能。
● 如果要设计小而简练的功能块,则使用接口。如果要设计大的功能单元,则使用抽象类。
● 如果要在组件的所有实现间提供通用的已实现功能,则使用抽象类。抽象类允许部分实现类,而接口不包含任何成员的实现。
随更改自动更新。另一方面,接口一旦创建就不能更改。如果需要接口的新版本,必须创建一个全新的接口。
● 如果创建的功能将在大范围的全异对象间使用,则使用接口。抽象类应主要用于关系密切的对象,而接口最适合为不相关的类
提供通用功能。
● 如果要设计小而简练的功能块,则使用接口。如果要设计大的功能单元,则使用抽象类。
● 如果要在组件的所有实现间提供通用的已实现功能,则使用抽象类。抽象类允许部分实现类,而接口不包含任何成员的实现。
另外我们在看看Dflying Chen和一醉解千愁 他门俩的见解:
Dflying Chen:接口用来定义两个对象通信的契约;抽象类用来封装对象间公用的行为。二者在设计起初的目标完全不同,
可惜在实际应用中被太多的人误解。
一醉解千愁:接口 -- 粗略的技术规范, 抽象类 -- 对粗略的技术规范作了一些简单的说明 ,类 -- 技术规范的具体实现.
可惜在实际应用中被太多的人误解。
一醉解千愁:接口 -- 粗略的技术规范, 抽象类 -- 对粗略的技术规范作了一些简单的说明 ,类 -- 技术规范的具体实现.
在我们大型的项目中,一般项目经理会按照功能分块,那么每个块最终必然是有联系的,他们靠什么联系呢?当然就是公开的接口了.至于接口下面是怎么实现的,大家没有必要知道太多,只要知道他们组这个接口实现了什么功能既可.这个时候,各版块之间的升级也就显得简单了,只要接口不动,内部的代码随便怎么修改都显得不那么重要了. 另外就是代码的复用程度更加高和更简单了.
这也同时说明了接口的设计相对来说是很重要的了,现在您也明白了我为什么花上这么长的时间和这么长的篇幅借用前辈门的观点来阐述抽象类和接口这个东西了吧。
后续部分请查阅深入继承之抽象类和接口综合分析及完整案列解说(二) 。