当前位置: 技术问答>java相关
關於抽象類和接口的問題(大討論)
来源: 互联网 发布时间:2015-07-29
本文导语: 在程序設計中我們不可避免的要求多繼承, 在這個其中我們是用一個抽象類加接口繼承 還是都使用接口繼承。 或者在程序中使用委托方式避免使用上繼承 | Patrick_DK(我向西 引北风 晒成一...
在程序設計中我們不可避免的要求多繼承,
在這個其中我們是用一個抽象類加接口繼承
還是都使用接口繼承。
或者在程序中使用委托方式避免使用上繼承
在這個其中我們是用一個抽象類加接口繼承
還是都使用接口繼承。
或者在程序中使用委托方式避免使用上繼承
|
Patrick_DK(我向西 引北风 晒成一身古铜)
我以為在最高層最好還是用抽象類,假如要應用其他實際類的東西可以通過委托實現。
在抽象類中有關於類的初始化。最好作為父類
我以為在最高層最好還是用抽象類,假如要應用其他實際類的東西可以通過委托實現。
在抽象類中有關於類的初始化。最好作為父類
|
如果不涉及多重继承,我一般的做法是:先定义一个接口,然后做一个抽象类,封装一些公用的方法代码。具体实现的类大部分可以从抽象类继承。
|
作者:透明
接口和抽象类
在去年的12 月初, 我在Design Patterns Explained 的讨论组上看到这个系列帖子,
觉得很有意思, 所以整理出来。如果你喜欢这种形式, 请写信到gigix@263.net, 我会整理
更多有趣的帖子出来。
面向对象中有一个术语: 派生。在用Java 编程的时候, 派生的来源可以是抽象类
( abstract class)、也可以是接口( interface)。何时使用抽象类? 何时使用接口? 这几
个帖子正是讨论了这个问题。
( 提出问题)
Alan, 我买了你的书, 读到了其中“ Bridge 模式” 那一章。然后, 我把一位朋友— —
他是个Java专家, 有五、六年使用Java的经验— — 叫来, 把你的书给他看, 并请他为我解
释你的Java 代码。我自己比较偏向于使用接口, 而你更多的使用了抽象类。他得出的结论
是: 你偏向于使用抽象类, 这反映出你对C++的爱好多于对Java的爱好。毕竟Java才有接
口这个概念, 而C++只有抽象类。因此, 我们感觉: 如果把你的示例代码中的抽象类换成接
口, 也许会使它们更能反映出实际情况和“ 按照协议设计” 的思想。实际上, 如果读过Peter
Coad的书, 你会发现他也主要使用接口。
( Alan Shalloway 的答复)
感谢你对这本书的评论。
我用Java 也有五、六年了, 所以我不认为使用抽象类就表示没有经验。实际上, 我觉
得Java 的一大缺憾就是它不支持多继承, 所以开发者经常被迫使用接口, 因为继承只能使
用一次。当然了, 这里面涉及到多继承的性能问题和基类成员的名字重复问题。但是不管怎
么说, 不允许多继承总是值得质疑的。
至于我这本书, 我选择使用抽象类, 是因为大多数人都熟悉它— — 不是每个人都喜欢去
看章节后面的C++示例的, 所以我决定用这种更通用的示例。
接口的问题就是它无法拥有默认行为。如果你用接口来定义一个什么东西并希望跨过这
层封装来添加一些行为, 你就必须使用委托。在我的记忆中, 有很多次就是因为不支持默认
行为而造成了麻烦。为了绕过这个限制, 我会使用委托, 但是这也是个痛苦的事情。
BTW: 我很喜欢Coad的书— — 我认为那是有史以来最好的设计书籍之一。
( Scott Bain 的跟贴)
从我自己的角度来说, 我是一个Java程序员( 从来没用过C++)。但是每当我遇到单继
承关系的时候, 我倾向于使用抽象类, 尽管我知道Java 不支持多继承。为什么这样? 因为
即使我现在没有任何默认行为, 将来我还可以放进一些默认行为, 而不必修改子类的结构。
而且, 如果要在一个继承体系中放置工厂方法来生成子类的实例, 抽象类是就是最好、
最合乎逻辑的地方。因为客户对象只需要“ 知道” 抽象类就可以了, 通过转型得到的实例完
全封装了子类的存在和选择子类的规则。这使得系统的扩展变得简单,而且不会造成副作用。
只有当需要让一个类“ 象什么” 而非“ 是什么” 的时候, 我才会使用接口。
( Alan Shalloway 的回复)
PDF created with FinePrint pdfFactory trial version http://www.fineprint.com
精彩! 很高兴看到这样的回复! J
我也发现, 在Java 中缺少默认行为造成的影响似乎还没有真正引起人们的重视。从一
开始, SUN 似乎就忽略了向后兼容的问题。我可以大胆的预言: 完全用接口构建成的系统将
在几年之后发现这是一个大问题。据我所知, 有几个基于COM 模型( 也就是接口) 构建的应
用程序的开发者现在已经陷入了维护问题, 因为当他们想修改接口来应对新的情况( 比如添
加新的参数或新的方法) 时, 这会耗去他们大量的时间。如果使用抽象类, 修改就不会这么
困难, 因为你可以只修改默认方法, 子类就不用动了。
我可不是说不能使用接口, 但是你必须清楚: 有些时候应该使用接口, 而有些时候就是
应该使用抽象类。不幸的是, 由于Java不支持多继承, 你必须很小心的做出选择。
( Scott Bain 的跟贴)
同样精彩! 关于接口, 我再来废话几句:
有时候, 一个东西可以“ 是” 几个东西。不明白这句话吗? 我就拿我自己来举个例子吧:
我“ 是” 一个程序员、一个老师、一个作者、一个父亲… … 你可以说我“ 实现了老师的接口”,
学生们会向我询问关于上课的问题。我还“ 实现了父亲的接口”, 但是我的学生可能知道这
一点, 也可能不知道。如果他们知道这一点, 他们就可以放心的向我询问关于抚养小孩的问
题了。
但是, 尽管我实现了所有这些接口, 我还有一个抽象类— — “ 人”。这个抽象类给我提
供了所有的默认行为( 比如说我偶尔会走背运)。
PDF created with FinePrint pdfFactory trial version http://www.fineprint.com
接口和抽象类
在去年的12 月初, 我在Design Patterns Explained 的讨论组上看到这个系列帖子,
觉得很有意思, 所以整理出来。如果你喜欢这种形式, 请写信到gigix@263.net, 我会整理
更多有趣的帖子出来。
面向对象中有一个术语: 派生。在用Java 编程的时候, 派生的来源可以是抽象类
( abstract class)、也可以是接口( interface)。何时使用抽象类? 何时使用接口? 这几
个帖子正是讨论了这个问题。
( 提出问题)
Alan, 我买了你的书, 读到了其中“ Bridge 模式” 那一章。然后, 我把一位朋友— —
他是个Java专家, 有五、六年使用Java的经验— — 叫来, 把你的书给他看, 并请他为我解
释你的Java 代码。我自己比较偏向于使用接口, 而你更多的使用了抽象类。他得出的结论
是: 你偏向于使用抽象类, 这反映出你对C++的爱好多于对Java的爱好。毕竟Java才有接
口这个概念, 而C++只有抽象类。因此, 我们感觉: 如果把你的示例代码中的抽象类换成接
口, 也许会使它们更能反映出实际情况和“ 按照协议设计” 的思想。实际上, 如果读过Peter
Coad的书, 你会发现他也主要使用接口。
( Alan Shalloway 的答复)
感谢你对这本书的评论。
我用Java 也有五、六年了, 所以我不认为使用抽象类就表示没有经验。实际上, 我觉
得Java 的一大缺憾就是它不支持多继承, 所以开发者经常被迫使用接口, 因为继承只能使
用一次。当然了, 这里面涉及到多继承的性能问题和基类成员的名字重复问题。但是不管怎
么说, 不允许多继承总是值得质疑的。
至于我这本书, 我选择使用抽象类, 是因为大多数人都熟悉它— — 不是每个人都喜欢去
看章节后面的C++示例的, 所以我决定用这种更通用的示例。
接口的问题就是它无法拥有默认行为。如果你用接口来定义一个什么东西并希望跨过这
层封装来添加一些行为, 你就必须使用委托。在我的记忆中, 有很多次就是因为不支持默认
行为而造成了麻烦。为了绕过这个限制, 我会使用委托, 但是这也是个痛苦的事情。
BTW: 我很喜欢Coad的书— — 我认为那是有史以来最好的设计书籍之一。
( Scott Bain 的跟贴)
从我自己的角度来说, 我是一个Java程序员( 从来没用过C++)。但是每当我遇到单继
承关系的时候, 我倾向于使用抽象类, 尽管我知道Java 不支持多继承。为什么这样? 因为
即使我现在没有任何默认行为, 将来我还可以放进一些默认行为, 而不必修改子类的结构。
而且, 如果要在一个继承体系中放置工厂方法来生成子类的实例, 抽象类是就是最好、
最合乎逻辑的地方。因为客户对象只需要“ 知道” 抽象类就可以了, 通过转型得到的实例完
全封装了子类的存在和选择子类的规则。这使得系统的扩展变得简单,而且不会造成副作用。
只有当需要让一个类“ 象什么” 而非“ 是什么” 的时候, 我才会使用接口。
( Alan Shalloway 的回复)
PDF created with FinePrint pdfFactory trial version http://www.fineprint.com
精彩! 很高兴看到这样的回复! J
我也发现, 在Java 中缺少默认行为造成的影响似乎还没有真正引起人们的重视。从一
开始, SUN 似乎就忽略了向后兼容的问题。我可以大胆的预言: 完全用接口构建成的系统将
在几年之后发现这是一个大问题。据我所知, 有几个基于COM 模型( 也就是接口) 构建的应
用程序的开发者现在已经陷入了维护问题, 因为当他们想修改接口来应对新的情况( 比如添
加新的参数或新的方法) 时, 这会耗去他们大量的时间。如果使用抽象类, 修改就不会这么
困难, 因为你可以只修改默认方法, 子类就不用动了。
我可不是说不能使用接口, 但是你必须清楚: 有些时候应该使用接口, 而有些时候就是
应该使用抽象类。不幸的是, 由于Java不支持多继承, 你必须很小心的做出选择。
( Scott Bain 的跟贴)
同样精彩! 关于接口, 我再来废话几句:
有时候, 一个东西可以“ 是” 几个东西。不明白这句话吗? 我就拿我自己来举个例子吧:
我“ 是” 一个程序员、一个老师、一个作者、一个父亲… … 你可以说我“ 实现了老师的接口”,
学生们会向我询问关于上课的问题。我还“ 实现了父亲的接口”, 但是我的学生可能知道这
一点, 也可能不知道。如果他们知道这一点, 他们就可以放心的向我询问关于抚养小孩的问
题了。
但是, 尽管我实现了所有这些接口, 我还有一个抽象类— — “ 人”。这个抽象类给我提
供了所有的默认行为( 比如说我偶尔会走背运)。
PDF created with FinePrint pdfFactory trial version http://www.fineprint.com
|
Java不支持多重继承的啊,但是,却通过接口来实现多重继承的啦!
抽象類和接口有相似的地方啊!但也有不同之处!
呵呵!个人之见!
抽象類和接口有相似的地方啊!但也有不同之处!
呵呵!个人之见!
|
接口: like a
抽象类:is a
http://www-900.ibm.com/developerWorks/cn/java/l-javainterface-abstract/index.shtml
抽象类:is a
http://www-900.ibm.com/developerWorks/cn/java/l-javainterface-abstract/index.shtml
|
尽量用接口
避免使用抽象类
一个类就一个父类,但可以有N个接口
你要是占用了父类,万一别的地方也需要呢
所以还是面向接口吧
避免使用抽象类
一个类就一个父类,但可以有N个接口
你要是占用了父类,万一别的地方也需要呢
所以还是面向接口吧
|
一个父亲能有多个儿子 但一个儿子却只能有一个父亲
java的单继承 在这一点上比较符合自然规律
java的单继承 在这一点上比较符合自然规律
|
多重继承最后会把你自己搞昏的,还是尽量使用接口吧!
|
看think in java,讲得很不错的,不过具体用还是要到实践中自己去体会
您可能感兴趣的文章:
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术,将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外,均为转载、整理或搜集自网络。欢迎任何形式的转载,转载请注明出处。
本站(WWW.)站内文章除注明原创外,均为转载、整理或搜集自网络。欢迎任何形式的转载,转载请注明出处。