不会用继承,那是你还没有学会OOP编程思想。建议你多看看这方面的书。
就拿你的例子来说吧在你说的情况下,的确是不需要用到继特性的。我们假设,你的程序提供了一多种风格让用户选择,用户可以选择查看商品列表时的风格,比如横向和纵向两种风格。那么你就要定义一个显示列表的基类,假设为 BaseList。然后两个显示风格的类分别是 HList 和 VList。在 BaseList 中你要定义好一些方法。比如,取得数据,分析数据等,这些东西不管横向还是纵向都是需要的。同时要定义一个显示接口,其它类就调用这个接口来显示表格。而在 VList 和 HList 从 BaseList 继承,就继承了取得数据,分析数据的方法,这些不需要重写了。然后实现显示接口,具体实现是纵向显示或者横向显示。在显示时就可以BaseList list = BaseList.getStyle(selectedStyle);
list.showTable();这样。如果不用继承,取得数据的分析数据的方法在每个类中需要重写不说(也许你可以用一个单独的类来完成这些操作)。在选择风格的时候,你就必须用一个 switch 或者 一系列的 if 语句来判断,如
if (selectedStyle == Style.V) {
VList list = new VList();
list.showTable();
} else if (selectedStyle == Style.H) {
HList list = new HList();
list.showTable();
} else {
....
}假设此时我们需要添加一种新的 style,那么是不是还要改写这一段 if 语句呢?
如果用的是继承,我们只需要改写 BaseList.getStyle 即可。如果这个方法中使用了 java reflection,那么有可能连 BaseList.getStyle 都不需要改写,只需要转入参数的时候传入新的 style 名称即可。时间有限,可能说得不是很清楚。OOP 的主要目的就是简化代码以及提供代码的重用率。
就拿你的例子来说吧在你说的情况下,的确是不需要用到继特性的。我们假设,你的程序提供了一多种风格让用户选择,用户可以选择查看商品列表时的风格,比如横向和纵向两种风格。那么你就要定义一个显示列表的基类,假设为 BaseList。然后两个显示风格的类分别是 HList 和 VList。在 BaseList 中你要定义好一些方法。比如,取得数据,分析数据等,这些东西不管横向还是纵向都是需要的。同时要定义一个显示接口,其它类就调用这个接口来显示表格。而在 VList 和 HList 从 BaseList 继承,就继承了取得数据,分析数据的方法,这些不需要重写了。然后实现显示接口,具体实现是纵向显示或者横向显示。在显示时就可以BaseList list = BaseList.getStyle(selectedStyle);
list.showTable();这样。如果不用继承,取得数据的分析数据的方法在每个类中需要重写不说(也许你可以用一个单独的类来完成这些操作)。在选择风格的时候,你就必须用一个 switch 或者 一系列的 if 语句来判断,如
if (selectedStyle == Style.V) {
VList list = new VList();
list.showTable();
} else if (selectedStyle == Style.H) {
HList list = new HList();
list.showTable();
} else {
....
}假设此时我们需要添加一种新的 style,那么是不是还要改写这一段 if 语句呢?
如果用的是继承,我们只需要改写 BaseList.getStyle 即可。如果这个方法中使用了 java reflection,那么有可能连 BaseList.getStyle 都不需要改写,只需要转入参数的时候传入新的 style 名称即可。时间有限,可能说得不是很清楚。OOP 的主要目的就是简化代码以及提供代码的重用率。
class Person
class Woman extends Person
class Man extends PersonPerson 有一些 attributes,如头脑,四肢,五官等
Person 有一些 method,如走,拿,吃饭等Woman 和 Man 也同样具体 Person 这些 attributes 和 methods,所以他们都从 Person 继承
但是 Woman 有一些特有的 attributes,如女性的第二性征
Man 也有一些特有的 attributes,如男性的第二性征同时,Woman 也有一些特殊的 method,如生孩子这层关系不用继承也可以表示,但是表示出来就不会像用继承这样清晰。而且,在某些时间,比如上车的时候,允许 Person 上车,你不用去区分是男人还是女人吧,所以可以
getUp(Persion p)
如果没有继承,就需要
getUp(Woman p)
getUp(Man p)
如果再多一个 class Child extends Person
那就得再实现一个 getUp(Child p)
用继承就不需要新添加方法了。在上洗手间的时候是要分男女的,这时候又可以细化到子类一级
goWc(Man p)
goWc(Woman p)
至于小孩子的情况,似乎没有小孩子专用WC哦,所以这个例子举得不太好,呵呵,不过大体上能说明一些问题吧。
当然具体编码的时候自己想怎么样就怎么样吧!
谁都知道所有的java类都是从java.lang.object继承来的。
换句话说,你只要用了java就离不开继承了。
要不你把所有的应用组件都自己写一遍试试!?
├─生物
│ ├─动物
│ │ ├─哺乳动物
│ │ │ ├─犬科
│ │ │ │ ├─狗
│ │ │ │ │ ├─哈巴狗
│ │ │ │ │ ├─猎犬
│ │ │ │ │ ├─北京犬
│ │ │ │ │ └─狐狸狗
│ │ │ │ └─狼
│ │ │ └─猫科
│ │ │ ├─老虎
│ │ │ ├─猫
│ │ │ └─野猫
│ │ ├─单细胞动物
│ │ ├─昆虫
│ │ └─鸟类
│ └─植物
└─非生物从这棵树就可以看出来多层继承的关系。虽然并不是每一个程序都需要多层继承,但是这种情况还是在某些情况下存在的。
1、MFC一共才600多个类,敢问JDK多少个?
2、JDK的AWT也好,Swing也好,我们用JBuilder拖几下就不行了,不能象PhotoShop一样的操作,大家知道VB吧!想怎么拖就怎么拖,你可以压根不理解编程。
比如你的例子中,为什么人不使用接口呢?我想大家关心的是你能走路,而不是由于你是继承自动物,所以能走路。所以我想如果仅仅只是功能,继承未必不逊色于接口加组合。没有觉得你的不对。就是James也提到了,JDK的实现违背了他的初衷,没有很好的支持回避继承。不信你可以多尝试一下接口。
你用的方法应该算是组合。
其实很多情况下,优先考虑组合,再考虑继承。
继承是在需要用的时候才用,不是有事没事非得要用。
看实际情况啦。
没有谁说过不用继承就不是oop的。
代表我的观点之一。
JFrame 默认使用 BorderLayout 和默认使用 null 实际上并无多大差别,有些人习惯了用东南西北中进行布局,就会觉得默认 BorderLayout 好,如果习惯自由拖动的,就会觉得 null 好,那也是个人习惯的问题。
我并不否认接口,我也认为接口的设计非常不错,不过用继承也不错啊。如果不用继承,仅用接口,有时候需要重写很多代码的。
别人怎么说我听,但我不一定要照样去做,我自己觉得怎么样方便,就怎么样,也蛮好的。
类
ShoppingSkep
ShoppingTruck
接口
Putable // 可以放入东西的东西,提供接口方法 put();如果不用继承,ShoppingSkep 和 ShoppingTruck 分别都实现 Putable
那么它们都是自己实现一个 put 方法。而二者的 put 方法做所事情都一样,就是放东西,这就造成了重复代码。如果 Truck 继承自 Skep,那么 put 方法在 Skep 中实现后,Truck 就可以直接继承使用。