50,523
社区成员
发帖
与我相关
我的任务
分享抽象类有什么好处？？？
为什么要用到抽象类和接口呢？
都说是为了符合开闭原则，但是根本就感觉无从下手去定义一个抽象类或是接口。
觉得有些多此一举了。
唉水平太低就是这样了。
有经验的人可以说说吗。
都说是为了符合开闭原则，但是根本就感觉无从下手去定义一个抽象类或是接口。
觉得有些多此一举了。
唉水平太低就是这样了。
有经验的人可以说说吗。
...全文
请发表友善的回复…
发表回复
schee 2004-07-16
- 打赏
- 举报
扩展性强!
yaray 2004-07-15
- 打赏
- 举报
接口： 只定义方法名称，没有方法的具体实现。
抽象类： 只定义方法名称，没有方法的具体实现。 (与 接口 相同)
定义方法名称，并实现这些方法。 (与 类 相同)
以上两者都有。(真正的抽象类大多是这种方式. 可参看API源代码)
类：定义的方法必须都有实现。
抽象类： 只定义方法名称，没有方法的具体实现。 (与 接口 相同)
定义方法名称，并实现这些方法。 (与 类 相同)
以上两者都有。(真正的抽象类大多是这种方式. 可参看API源代码)
类：定义的方法必须都有实现。
jie015 2004-07-15
- 打赏
- 举报
听课。
不过我在书上看到，说Interface比抽象类更抽象。
优先考虑接口编程。
不过我在书上看到，说Interface比抽象类更抽象。
优先考虑接口编程。
孬毛毛 2004-07-15
- 打赏
- 举报
觉得接口主要体现多态、可扩展性。
而抽象类主要是体现方法复用的。
~~~不知道这个理解是否正确？？！！
而抽象类主要是体现方法复用的。
~~~不知道这个理解是否正确？？！！
lubin59 2004-07-14
- 打赏
- 举报
好久不永java，都快忘光了，赶快学习一下
孬毛毛 2004-07-14
- 打赏
- 举报
回复人： 0flying0(j2ee的狂热分子) ( ) 信誉：100 2004-4-26 19:07:37 得分: 0
其实“接口”才更有利于多态的实现的。
------------------------------------------
同意这一点~~~~~~复用、多态等特性，最根本是在接口上面体现出来的
其实“接口”才更有利于多态的实现的。
------------------------------------------
同意这一点~~~~~~复用、多态等特性，最根本是在接口上面体现出来的
programer23 2004-07-14
- 打赏
- 举报
面向抽象！
huyuefox 2004-06-18
- 打赏
- 举报
抽象类作为超类，可以将子类的公用逻辑用方法实现，而接口只是定义了实现类的规范（其实就是定义了实现类该做什么）
因此子类有公用的逻辑部分就在抽象类里实现该方法的细节，子类中有共性但实现细节不同则定义为抽象方法。抽象类只能被一个子类继承，而接口可以被多个实现类实现，所以同意楼上的接口的多态性更好
因此子类有公用的逻辑部分就在抽象类里实现该方法的细节，子类中有共性但实现细节不同则定义为抽象方法。抽象类只能被一个子类继承，而接口可以被多个实现类实现，所以同意楼上的接口的多态性更好
armorking2003 2004-06-17
- 打赏
- 举报
interface表述“has a”关系，用于描述功能
是用来说明它的是实现类是“做什么？”的
至于“怎么作？”，interface并不进行约束
而abstract class表述“is a”关系，它在描述功能的同时
也通过具体实现部分功能的方式，来约束“怎么作？”
只有接受了这个约束，才应该去继承它
从而可以将“其中被具体实现的部分功能”，在它的子类中得到重用
实际使用当中，interface与而abstract class各有优势，
需要权衡。
不过，有时候，两者也可以兼用
《effective java》中提出，
可以声明一个interface描述功能，
再提供一个该接口的骨架（skeleton）实现（实现该接口的abstract class）
固化对功能实现方式的约束，从而尽可能地实现重用
于是就有了另一个问题：
在使用当中，可能发现这个skeleton实现不能满足现有需求
这时可以在原有的interface基础上，派生出另一个skeleton实现
是用来说明它的是实现类是“做什么？”的
至于“怎么作？”，interface并不进行约束
而abstract class表述“is a”关系，它在描述功能的同时
也通过具体实现部分功能的方式，来约束“怎么作？”
只有接受了这个约束，才应该去继承它
从而可以将“其中被具体实现的部分功能”，在它的子类中得到重用
实际使用当中，interface与而abstract class各有优势，
需要权衡。
不过，有时候，两者也可以兼用
《effective java》中提出，
可以声明一个interface描述功能，
再提供一个该接口的骨架（skeleton）实现（实现该接口的abstract class）
固化对功能实现方式的约束，从而尽可能地实现重用
于是就有了另一个问题：
在使用当中，可能发现这个skeleton实现不能满足现有需求
这时可以在原有的interface基础上，派生出另一个skeleton实现
shingle 2004-06-13
- 打赏
- 举报
从设计上说抽象类的好处有二：
一、抽象类提供了部分实现，使子类可以重用部分抽象类的代码
二、抽象类为其子类提供了共同的接口（注意：这里说我接口与 java 中的 interface 是不同的）
也就是别人可以将各个子类的对象当成抽象类的对象使用。
我觉得“为了方便扩展”的说法是荒谬的，如果可以实现，为什么要代码写到别的类中去呢？
抽象类的关键是抽象方法，而设计抽象方法的原因是在于抽象类自己没有办法实现这个方法，
或者说在抽象类这一层，我们不知道如何实现这个方法，只有到了具体类才有办法知道实现。
如“动物”这个抽象类，有一个抽象方法“吃”，但是动物这个类是不能实现“吃这个方法的，
只有到了“人”这个类，才能有“用手将东西放进嘴里然后吞下去”这样的实现。
“动物”这个类的“吃”方法也不可能有默认的实现，因为现实中没有一个纯“动物”的实例，
它要么是“人”类的实例，要么是其它“动物”类子类的实例！
但我们一旦碰到一个“动物”对象，就可以调用“吃”这个方法，
当然我们也要预期不同对象的实现不是一样的
一、抽象类提供了部分实现，使子类可以重用部分抽象类的代码
二、抽象类为其子类提供了共同的接口（注意：这里说我接口与 java 中的 interface 是不同的）
也就是别人可以将各个子类的对象当成抽象类的对象使用。
我觉得“为了方便扩展”的说法是荒谬的，如果可以实现，为什么要代码写到别的类中去呢？
抽象类的关键是抽象方法，而设计抽象方法的原因是在于抽象类自己没有办法实现这个方法，
或者说在抽象类这一层，我们不知道如何实现这个方法，只有到了具体类才有办法知道实现。
如“动物”这个抽象类，有一个抽象方法“吃”，但是动物这个类是不能实现“吃这个方法的，
只有到了“人”这个类，才能有“用手将东西放进嘴里然后吞下去”这样的实现。
“动物”这个类的“吃”方法也不可能有默认的实现，因为现实中没有一个纯“动物”的实例，
它要么是“人”类的实例，要么是其它“动物”类子类的实例！
但我们一旦碰到一个“动物”对象，就可以调用“吃”这个方法，
当然我们也要预期不同对象的实现不是一样的
同桌老王 2004-06-11
- 打赏
- 举报
是为了自己或者别人以后扩展方便。
glchengang 2004-06-11
- 打赏
- 举报
简单的说,抽象类就是为了共用代码,没必要想得这么复杂.
http://dev.csdn.net/user/glchengang 看<一个体现Java接口及工厂模式优点的例子>
如果看了这篇文章你还是不能理解接口和抽象类的作用,告诉我,我再写.
http://dev.csdn.net/user/glchengang 看<一个体现Java接口及工厂模式优点的例子>
如果看了这篇文章你还是不能理解接口和抽象类的作用,告诉我,我再写.
raymond323 2004-06-09
- 打赏
- 举报
1
rootI 2004-06-09
- 打赏
- 举报
Refactoring
raimundo 2004-05-12
- 打赏
- 举报
赫赫，其实如果对比C++的话就很明白了，C++由于没有接口的语法，所以继承的设计哲学里面分接口继承和实现继承两种，而java中通过语言名确了使用interface进行接口继承，那么抽象类在设计上的唯一用处就是实现继承。我比较赞同这样的设计，一般的类都final，能继承的都是abstract，决不为了减少代码作一个既可以继承也可以具体使用的类。
frean 2004-05-10
- 打赏
- 举报
对于接口、抽象类，我的理解是：从类图出发，根据实际情况定义接口或抽象类，接口是定义行为的，任何一个类都可以看作有一个接口，如果需要可以定义接口，否则不需要定义，而抽象类是可以定义和实现行为，但不能执行行为，因为它不能实例化，但可以定义对象，这个对象的行为是抽象类的实现类的实例的行为。
yuannauy 2004-05-10
- 打赏
- 举报
那又什么时候使用“回调”呢？
MaiCle 2004-05-07
- 打赏
- 举报
gleaf() :具体类不是用来继承的！
Scott Meyers曾指出：只要有可能，不要从具体类继承
Scott Meyers曾指出：只要有可能，不要从具体类继承
java_alias 2004-05-05
- 打赏
- 举报
匆忙上网，收藏先，有空慢慢看
gleaf 2004-05-05
- 打赏
- 举报
回复人： ai92(抵制日货！！) ( ) 信誉：96 2004-04-23 01:35:00 得分:0
再来一个:
假如很多人要买水果吃，吃的动作只有一个，但是有的人要用现金买，有的人用信用卡，有的人赊帐。要为每个人定义一个类，就要定义多个相同的吃的方法。如果定义一个抽象类，在里面实现吃的方法，再做一个买的抽象方法。那每个人的类都从这个抽象类派生下来，只要实现买的方法即可，吃的方法就可以直接用父类的方法了。如果要改吃的方法就不用改多个，只要改这个抽象类里的就行了。
=============================================================
不同意，在这里也可以用普通类作为父类，在这个例子不一定要用抽象类，也可以用普通类。
=============================================================
在这个例子里可以使用普通类，此时“吃”方法需要被声明为抽象方法。
在这个类里面可能同时存在抽象方法和普通（现实）方法。有点不爽
就一般而言，仍然可以把这里的抽象方法从普通类里面分离出来，形成一个接口。而普通类实现接口。如此就把现实世界中的“抽象”和“具体”完全分离，有益于代码的可读性和可重用性。
再来一个:
假如很多人要买水果吃，吃的动作只有一个，但是有的人要用现金买，有的人用信用卡，有的人赊帐。要为每个人定义一个类，就要定义多个相同的吃的方法。如果定义一个抽象类，在里面实现吃的方法，再做一个买的抽象方法。那每个人的类都从这个抽象类派生下来，只要实现买的方法即可，吃的方法就可以直接用父类的方法了。如果要改吃的方法就不用改多个，只要改这个抽象类里的就行了。
=============================================================
不同意，在这里也可以用普通类作为父类，在这个例子不一定要用抽象类，也可以用普通类。
=============================================================
在这个例子里可以使用普通类，此时“吃”方法需要被声明为抽象方法。
在这个类里面可能同时存在抽象方法和普通（现实）方法。有点不爽
就一般而言，仍然可以把这里的抽象方法从普通类里面分离出来，形成一个接口。而普通类实现接口。如此就把现实世界中的“抽象”和“具体”完全分离，有益于代码的可读性和可重用性。
加载更多回复（31）
