不会用继承,那是你还没有学会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 的主要目的就是简化代码以及提供代码的重用率。

解决方案 »

  1.   

    jamesfancy()边城狂人(James Fancy) :谢谢你,你说的真的太清楚了,不过我还是有点绕不过来呵呵,你说的对,我可以把他全部做到一个类里面,提供很多的style,用户调用的时候肯定要用if判断的,可是分成不同的类就可以不用判断?一样也要判断用户选择的style然后调用不同的类啊?我感觉继承如果用了,模块旧分得更细了,把所有的程序都拆开了,尤其那种多层继承的,代码的可读性真的很差?另外想和您探讨一下,现在我把购物环节的数据库连接,字符串过滤等都封装到不同的工具类去了,虽然数据库连接每个类都要用的,但是有必要所有的类都去继承么?如果是您,一个商城来说您会怎么配置呢?非常想听听您的思路,谢谢啊!
      

  2.   

    haofengfu(风斧) 我觉得我们可能是一个情况,代码并不负责,所以感受不到啊
      

  3.   

    具体到商城我也没有相关的经验,如果从头考虑又比较费神,我是个懒人,就再取一个例子来说明吧。人,女人,男人
    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哦,所以这个例子举得不太好,呵呵,不过大体上能说明一些问题吧。
      

  4.   

    我是初学者,没有权利发言,但我知道用了继承会方便许多。真正体现oop的好处
      

  5.   

    记得有人说Java的初衷就是想回避继承。
    当然具体编码的时候自己想怎么样就怎么样吧!
      

  6.   

    jamesfancy()边城狂人(James Fancy) 您的解释太透彻了,我这下子明白了,呵呵,分一定给你不过等等看看大家还有什么好的想法和意见,你对oop的理解真的已经很深入了,我想很多朋友还是和我一样思维方式没有改变所以才有这个误解:)另外还想问问,对于多层的继承你是怎么看的呢?我们公司的项目继承的层次竟然有5-6层的,每层还经常去用super去调用父类的构造函数,这样有什么好处?而且这样错误和差错都很费劲吧?我感觉对于接手的人来说,太过复杂了,只有写的人自己明白:)
      

  7.   

    javafaq2004(农村干部瞎忙活) 呵呵,我也觉得错误的纪律呈现几何级数的提高
      

  8.   

    inherit is one of cores of oo thinking.it diminishs the amount of code.
      

  9.   

    唉!有什么可争的?
    谁都知道所有的java类都是从java.lang.object继承来的。
    换句话说,你只要用了java就离不开继承了。
    要不你把所有的应用组件都自己写一遍试试!?
      

  10.   

    多级(或多层)继承,在 JDK 里就有非常多的体现,比如 swing 组件中,所有组件都是从 JComponent 继承而来的,如 AbstractButton,而 JButton、JMenuItem 和 JToggleButton 又都继承自 AbstractButton。JMenuItem 又有 JMenu 等子类,JToggleButton 有 JCheckBox 和 JRadioButton 等子类,这些就是多层继承。还是具一个现实生活中的实例吧,因为生活中本身一切都是对象,也比较好理解。事物
    ├─生物
    │  ├─动物
    │  │  ├─哺乳动物
    │  │  │  ├─犬科
    │  │  │  │  ├─狗
    │  │  │  │  │  ├─哈巴狗
    │  │  │  │  │  ├─猎犬
    │  │  │  │  │  ├─北京犬
    │  │  │  │  │  └─狐狸狗
    │  │  │  │  └─狼
    │  │  │  └─猫科
    │  │  │      ├─老虎
    │  │  │      ├─猫
    │  │  │      └─野猫
    │  │  ├─单细胞动物
    │  │  ├─昆虫
    │  │  └─鸟类
    │  └─植物
    └─非生物从这棵树就可以看出来多层继承的关系。虽然并不是每一个程序都需要多层继承,但是这种情况还是在某些情况下存在的。
      

  11.   

    jamesfancy()边城狂人(James Fancy) 真是强人 …… 有机会和你学两手就好了……
      

  12.   

    继承体现了面向对象语言的主要特点,JAVA当然不能例外!
      

  13.   

    普通应用当然很少用到继承,但是你自己考虑设计一套Web框架看看?看你用不用继承~--原因很简单,你现在做的东西其实都是在建立在许多应用框架之上的,也就是说,很多设计模式上的东西,框架的设计者已经为你做好了,免去了要让你想破脑壳的大部分工作量,好让你从底层框架抽身出来,将力气用于业务逻辑。--不信??你自己看看JDK的源代码,或者Struts的源代码,或者Hibernate的源代码,看人家是怎样使用OO三大特征和各种设计模式的。
      

  14.   

    JDK的实现得好不好,我们来看这样两点:
    1、MFC一共才600多个类,敢问JDK多少个?
    2、JDK的AWT也好,Swing也好,我们用JBuilder拖几下就不行了,不能象PhotoShop一样的操作,大家知道VB吧!想怎么拖就怎么拖,你可以压根不理解编程。
      

  15.   

    javafaq2004(农村干部瞎忙活) 对你的话我有些不赞同1. MFC 是众所周知的难用,它封装的 API 和不封装时的 API,在使用上并没有提供多大的方便。而且实现的类多有错吗?提供了更多的工具类给你,你难道还不愿意?2. JBuilder 我没用过,不敢妄断它的好坏,但是能不能自由拖动组件,这也不是判断一个语言好坏的标准,这是评判一个 UI Designer 的标准。Java 也有很多不错的 IDE 支持很好的拖动。不过由于 Java 的 JFrame 等默认是 BorderLayout,按东南西北中来布局组件的,所以在拖动上你会觉得受限,如果你不用任何 Layout,你就可以想怎么拖就怎么拖,这不是 Java 的问题,是你自己没学好。3. VB 是好,VB 本来就是针对非专业编程用户的,或者说是入门级编程用户的。目标不同而已。你怎么不拿 Java 跟汇编比呢?各种语言各有所长,也各有所短,请不要妄自去对比。有人说我男人女人的例子举得好,不妨再调侃一句:让一个男人去和女人比谁生娃生得多,那可真有点难度。
      

  16.   

    1. MFC 是众所周知的难用,它封装的 API 和不封装时的 API,在使用上并没有提供多大的方便。而且实现的类多有错吗?提供了更多的工具类给你,你难道还不愿意?类多学着使用起来难学。Java 在设计 Collection 框架的时候不是也考虑了这个问题吗?至于功能 JDK 的功能并不比 MFC 强大,甚至是比不上。有很多关于使用继承出现很多类的讨论了。2. JBuilder 我没用过,不敢妄断它的好坏,但是能不能自由拖动组件,这也不是判断一个语言好坏的标准,这是评判一个 UI Designer 的标准。Java 也有很多不错的 IDE 支持很好的拖动。不过由于 Java 的 JFrame 等默认是 BorderLayout,按东南西北中来布局组件的,所以在拖动上你会觉得受限,如果你不用任何 Layout,你就可以想怎么拖就怎么拖,这不是 Java 的问题,是你自己没学好。呵呵,记得MFC的设计人员说过,如果对一个类的使用具有强制性,我想这个类本身就不应该存在。正如你所说的,JBuilder之所以这样,是由于JDK中有 Layout 的问题。为什么一定要用户知道有这个东西才可以使用 Frame 呢?难道 Frame f = new Frame();f.show();f.add(component);不是更加好?这是 Java 和 COM 不能比的地方。3. VB 是好,VB 本来就是针对非专业编程用户的,或者说是入门级编程用户的。目标不同而已。你怎么不拿 Java 跟汇编比呢?各种语言各有所长,也各有所短,请不要妄自去对比。有人说我男人女人的例子举得好,不妨再调侃一句:让一个男人去和女人比谁生娃生得多,那可真有点难度。我没有说你的例子举得不好。只是觉得滥用继承不好。
    比如你的例子中,为什么人不使用接口呢?我想大家关心的是你能走路,而不是由于你是继承自动物,所以能走路。所以我想如果仅仅只是功能,继承未必不逊色于接口加组合。没有觉得你的不对。就是James也提到了,JDK的实现违背了他的初衷,没有很好的支持回避继承。不信你可以多尝试一下接口。
      

  17.   

    继承不是必须的。
    你用的方法应该算是组合。
    其实很多情况下,优先考虑组合,再考虑继承。
    继承是在需要用的时候才用,不是有事没事非得要用。
    看实际情况啦。
    没有谁说过不用继承就不是oop的。
      

  18.   

    go_my_sky(凡石) 
    代表我的观点之一。
      

  19.   

    remanwang(玩玩儿)那得看你的继承用得好不好了。用好了什么都好,用不好什么都不好。
      

  20.   

    javafaq2004(农村干部瞎忙活) 我没有说 JDK 比 MFC 强大,我的意思只是说不能这么简单的判断二者是好是坏。
    JFrame 默认使用 BorderLayout 和默认使用 null 实际上并无多大差别,有些人习惯了用东南西北中进行布局,就会觉得默认 BorderLayout 好,如果习惯自由拖动的,就会觉得 null 好,那也是个人习惯的问题。
    我并不否认接口,我也认为接口的设计非常不错,不过用继承也不错啊。如果不用继承,仅用接口,有时候需要重写很多代码的。
    别人怎么说我听,但我不一定要照样去做,我自己觉得怎么样方便,就怎么样,也蛮好的。
      

  21.   

    在我上面的例子中,我已经说过了,按男人,女人,孩子这样划分,其实不好,因为孩子也分男女的。再结合后面举的物种的那个例子,其实把男/女,或者说雄/雌,设计为接口相对来说要好得多。这样甚至连雌雄同性等问题都一并解决了。拿上面的购物车和篮子为例,

    ShoppingSkep
    ShoppingTruck
    接口
    Putable // 可以放入东西的东西,提供接口方法 put();如果不用继承,ShoppingSkep 和 ShoppingTruck 分别都实现 Putable
    那么它们都是自己实现一个 put 方法。而二者的 put 方法做所事情都一样,就是放东西,这就造成了重复代码。如果 Truck 继承自 Skep,那么 put 方法在 Skep 中实现后,Truck 就可以直接继承使用。