请大家谈谈事到如今继承还有啥意义？

从某一程度上来讲，楼主的思考是正确的，毕竟继承是耦合的温床！
从设计的角度出发，我们确实应该避免继承，但并不能因此而说继承没有任何意义！
因此继承关系除了出现在普通的超类和子类之间，还出现在接口与子接口之间、抽象父类及其子类之间。当然了，第一种继承关系随着设计程度阶段的提升会越来越不提倡，但即使如此，另外两种继承关系,却不可能完全杜绝，而不管哪种继承关系都在一定程度上避免了重复代码的编写。
设计理念中有一种叫“Don't Repert Yourself", 就是希望你不要写重复的代码，而继承也算是其中的一种啦！

从某一程度上来讲，楼主的思考是正确的，毕竟继承是耦合的温床！
从设计的角度出发，我们确实应该避免继承，但并不能因此而说继承没有任何意义！
因为继承关系除了出现在普通的超类和子类之间，还出现在接口与子接口之间、抽象父类及其子类之间。当然了，第一种继承关系随着设计程度阶段的提升会越来越不提倡，但即使如此，另外两种继承关系,却不可能完全杜绝，而不管哪种继承关系都在一定程度上避免了重复代码的编写。
设计理念中有一种叫“Don't Repeat Yourself", 就是希望你不要写重复的代码，而继承也算是其中的一种啦！

一个简单的例子，event中有action接口也有adapter抽象类。你用接口，就必须重写所有方法，继承adapter就能只重写你需要的方法。毕竟接口中的方法全是空的，没有具体实现。
简单一个例子：如果有个Persion类，有个实体方法eat，那么所有继承了Persion的类都可以直接使用eat方法，而不必重写。
如果你采用的是接口，那就不管了，那怕你100个类实现找个接口，100个eat方法内容都相同，你也得写100遍。
100遍和1遍，这就是选择。

各有千秋啊，继承是为了重用代码，而接口只是为了统一代码而做的……各种方法各有特色，所以Java也就有这么好啊。呵呵

继承的好处例如有这样一个接口Intface A
还有这样三个类 class B,class C,class D
他们都去实现Intface A
如果后期需要对程序做修改，比如在Intface A中加入一个新方法
那么实现了该接口的三个类，都得为这个新添加的方法提供实现，要是往Intface A是多加几个方法就太痛苦于是有位老前辈便用继承与接口的概念相结合解决了这个问题
添加一个 abstart class E 让这个抽象类去实现Intface A
再让class A,class B,class C去继承abstart class E
现在如果仍需要往Intface A里添加新的规范(方法)只需让实现了该缺口的抽象类去具体实现。
另外三个子类就可以有选择地进行实现当然这也是偶老师讲的，如果楼主真不知道继承用来干啥？我想现在最起码能用在这个设计模式里

问这个问题可以考虑下这样一个问题。
-------------
为什么有继承？
-------------楼主理解了这个问题吗？OO很多人在谈，不同的人理解的程度和使用的程度都不同。从设计角度来看，策略是方法，视角是方向。OO是方向，设计模式是方法。OO更贴近哲学。楼上的朋友shine333 的回复让你多写点代码。想问下楼主写代码的时候思考是否只局限在class提供了什么？它需要什么样的功能？功能又用到哪些数据？之类云云。如果是这样shine333 的建议你是应该认真考虑下，我个人十分赞同他的观点。当你发现把自己的代码变得精简、清晰、易懂，甚至随便给个大学生他也能看出个一二三四，你就会发现你的XX语言写的代码是在借鉴人类认知世界的方式在表达客观世界。OO就是这样产生的，是为合理的表达方式而产生的。
（从这个角度上来说：软件语言顺从了大部分人类自然语言表达方式）不然，你井在自己的狭隘的思维模式中，指望有多少人能很容易的理解你。代码写出来往往只是很小的一步，多少人认可你，选择你也许要花掉你编码的几百倍的时间。包括别人愿意接受你的代码，选择修改你的代码而不是重写。

继承本来就应该少用甚至不用。
Java之父都说了，要是让他重新设计Java，他要彻底抛弃继承。
Java从C++一脉相承而来，有继承特性是理所当然的，但并不代表它鼓励你必须使用继承。就像String类有一个String(String)构造方法，但是你永远都不要去用它。

to:Dan1980java 是OO的语言，如果它能完全摒弃继承，我想问：那样还需要有抽象吗？

当我实现多数据库支持的DAO时就需要继承
如：
public Abstract class AbstractDao {
public void method1() {
   //标准sql，主流数据库都支持
} public abstract void method2();//sql不一致，如取数据库第一条记录
}public class OracleDao extends AbstractDao {
public void method2() {
  //Oracle实现
}
}public class DB2Dao extends AbstractDao {
public void method2() {
  //DB2实现
}
}
因为大部分sql都可以用标准的，少数部分各数据库支持不一样需要各自实现，比如DAO中有300个方法，只有20个需要独自实现，这里个人觉得还是继承比较好当然通过组合和实现接口也能实现，但是却麻烦了很多

要扩展一个Button，不用继承的话，自己要做的工作太多了。即使内置一个Button对象，用组合也累死了。

shit 完全不知道你在瞎BB什麽，你自己就被困在java提供的各種規則里，還來說別人狭隘。
如果你真的對oo有深刻理解，就別在這說空話，整點有意義的。上面很多人講了一堆，都跳不出我主貼里的三句話
說實話，我很失望
對你們這些程序員的失望
哲學是什麽？哲學是把所有東西的共性提取出來，把複雜的東西統一化，簡單化可從諸位上面的發言，我完全看不到。
我只看到你們管中窺豹，單從自己所看到的片面上進行長篇大論。還有，上面那幾位，連我寫過多少代碼，做過多少項目一點都不知道，就開始BB什麽我先寫代碼再來討論這些問題的，我送你們三個字：操你媽，也可多送幾個：我操你媽的2逼玩意。一副高人的樣子，只會說空話，對別人豪無了解就知道BB，你他媽的怎麼不去當官啊，不去當公務員啊？白瞎了你這齷齪的能力了

上面有朋友說到接口也是一種繼承，這個說法是很對的。但是我這貼里討論的繼承是指各種oop里的狹義的繼續，如java里的extends看了上面這么多朋友的說法，大部分的觀點認為，繼承最大的作用在于“代碼級復用”但是很可惜，從長遠角度來說，代碼級復用的意義并不大。並且隨著開發工具的先進，代碼級的復用將會被逐步淘汰。請對oop有深刻理解的朋友，發表一下看法

shit,你覺得我是來要求你教我什麽東西嗎？你有資格要我交學費嗎？
第一，我這是討論貼，不是請教貼。
第二，你可以發表任何看法，無論是對是錯，我不可能罵你。
第三，你回復的時候，首先要看清貼子，認清自己的能力，而不是看個標題就進來亂回一通，把自己定位在宗師的高度，認為別人都是沒寫過幾行代碼的學生而進行一頓豪無意義的說教。對于這種人，我不會客氣。我不喜歡說空話的人。

对于楼主这种凶悍的作风，我还是蛮佩服的，其他网站上肯定会禁贴。刚接触开源的时候，我学习别人代码的同时也学习别人精神。做程序员没有感恩，没有虚心的接受，没有仔细的思考，不要指望能走到多远。我没有装大师也不想，每个人都是平等的，谁懂的多也只是相对的，我把我的认识说出来，你能不能接受是你的事情，想帮你却被骂我依然开心。几句话就知道你为人了，很值得啊。以后楼主的帖子我会敬而远之的。 to:paullbm 你人不错，规劝善导，不可则止，勿自辱焉。感谢其他一切讨论的人。

我相信楼主是善于思考的，而且也绝不是初级水平。这个坛子里，积分不代表什么，很多2颗星的用户都会问很低级的问题。再说，这个问题非常值得探讨，即使是很初级的用户，能提出这种问题也是很可贵的，比那些只知道埋头写代码的人强。所以请大家不要冷言冷语以对。回到这个问题上，我觉得大家有点把继承和子类型两个概念搞混淆了，最近的很多英语著作特别强调两者的区别，前者是Inheriting，后者是Subclassing，并指出，Subclassing是重要的，但Inheriting是应该避免的；继承（Inheriting）指的是代码级复用，而子类型（Subclassing）则是指类型抽象。具体到实现上，继承只能通过class ... extends 实现，而Subclassing既可以通过extends一个class，也可以通过extends一个interface，或者implements一个interface来实现。所以，这两者的实现形式有可能是一样的，但动机绝对不一样。

换句话说，同样是extends一个类，如果你的动机是不劳而获地得到它已经实现的某些功能，那就是继承（Inheriting），应该尽量避免；而如果你的动机是成为和它一样的类型，以便于在很多场合可以当作一个和它一样类型的对象被其他对象使用/访问，那么就是Subclassing，这是非常重要的一种手段。所以说，与其说继承是OO的核心之一，不如说是Suclassing。在下一代OO语言中，继承的概念必定会越来越弱化，而Subclassing则不会。

to: Dan1980汗！没人否定楼主问的问题。在下一代OO语言中，继承的概念必定会越来越弱化，而Subclassing则不会。Inheriting 应该尽量避免。这些我很认同。计算机语言表达世界，抽象到最后无非是数据和行为。我之所以说继承不会被没灭。一个是从java的OO的思想来看。接口是抽象功能。
抽象类抽象对象（小猫、小狗）。即使撇开这些，就现在的语法来看，接口抽象能力代替不了抽象类。抽象类能包含具体的数据和具体的行为，抽象模糊的行为。这个是接口取代不了的。
如果说能把继承和子类两个观点完全撇开。并完美的为子类提供新的语法支持。
我还没能体会到这种可能的实现方式。所以希望 Dan1980 兄能再提供点更有意思的信息。(注：我就是一菜鸟。)

我喜欢讨论，请别介意提些疑问呵呵也就是说subclassing完全可以由接口来替代了？但是还是没说清为什么不要inheriting，只是强调了大师说不要inheriting，没错，代码级复用的确可以由比如组合替代，但是如此便能合理地证明inheriting由此丧失了存在的必要性吗也就是说inheriting就没有其他优点了吗消除重复如何实现

to: dracularking就代码复用用提的确可以不通过 extends abstract class,采用Rod Johnson Spring 中提到的混合模式，实现多接口。同时提供setInterface1Impl1() setInterface1Impl2() setInterface1Impl3()代码复用的时候使用impl的实现方法。重复代码全部通过接口进行抽象，具体实现抽离到impl中。inheriting 作为手段，是否只是因为 extends 而会被舍弃？implements 是一种特殊的 inheriting。子类如果不使用 extends 抽象类。纯粹使用混合模式的方式去解决，让人感觉OOP反而被淡化了。因为抽象的单位感觉变成了方法而不是对象。总让人觉得奇怪。抽象对象导致的extends,
个人觉得 oop 提倡的对象抽象始终更合服情理。

不好意思：
--------------------
同时提供setInterface1Impl1() setInterface1Impl2() setInterface1Impl3()
--------------------
指针对不同接口的实现应该改为Interface1Impl Interface2Impl Interface3Impl

本来不准备进来了，看实在是热闹，也就来凑凑。
先申明，一家之言，仅供参考啊，
继承，其本质是为了重用。
接口，其本质是“协议”，规定对象与对象间的接头协议。引用一篇文章有详细说明。 http://mybeautiful.javaeye.com/blog/628672

我承认楼主的观点，“任何继承可以解决的问题，都可以用接口加组合实现。”
但是有时候确实有是（IS-A）的关系, 还是继承显得更优雅。
一个例子吧，
现有一个  狗类，
我专门打狗的   （其他动物我不打）。我们这里又多了个日本狗，如果它不继承狗的话，我将不会打它。当然，你也可以这样解决。
1.把狗跟日本狗的公共部分提出来，搞个新类XXXX，然后狗跟日本狗都组合一个XXXX.
2.提取一个接口，叫 IDog，狗跟日本狗都实现  IDog.
3.从此我改打 IDog.
这样也能解决问题。楼主想想，这样是不是很奇怪。

to:Mybeautiful
继承，其本质是为了重用。
接口，其本质是“协议”，规定对象与对象间的接头协议。
个人感觉（A 继承 B），继承是定性，认定 A 是 B，使A具备B的能力。重用是从语法上来看的效果。接口本质的确可以说成是OO 语言中“协议”，或者说成“规范”。
推荐两个不错的帖子
http://www.javaeye.com/topic/3291
http://www.javaeye.com/topic/150

是啊设计模式原则中有条提到 Favor composition Over inheritance
但即使这样仍还是觉得紧耦合的extends有其存在的合理性
就像你说的，从更完整和自然的oo角度阐释，oo缘起某个角度可以说是人类认知客观世界最自然的方式吧
子承父，非常客观自然，子也自然而然地或者说不可抗拒地会得到父的某些遗传特征，从oo自然完整的角度可能就可以说是需要extends的，还有avoid duplicate code

调试易

请大家谈谈事到如今继承还有啥意义？

解决方案 »

请大家谈谈事到如今 继承 还有啥意义？

解决方案 »

请大家谈谈事到如今继承还有啥意义？