呵呵,看了《JAVA与模式》你就知道接口和抽象类有多大的作用了……

解决方案 »

  1.   

    我看的是JAVA核心技术(1),可能刚接触"接口"这个概念对它了解的肯定还不深刻,但绝对没有一点低估它的意思,上面的一段话我只是想让大家看看我对接口的认识是否有偏差,它的作用是否象我所说的那样(当然它的重要性是不言而欲的),如果理解的正确我想对以后的学习有好处的,不会走弯路;如果我对它的理解还有偏差的话,还请指出.(就象上面举的"菜单"的例子一样,虽然菜单做起来不值几个钱,只要把菜名写清楚就行了,但是一个饭店如果缺少了"菜单",虽然不影响客户吃饭,但给客户带来很大的不便.而且一个饭店同样的"菜单"可以让不同餐座上的客户去使用,这就体现了它的通用性."菜单"就想"接口"一样,看起来很简单,但少了它就会带来很大的麻烦,而有了它就会大大提高工作的效率.)
    请大家给个评判!理解正确的就给100分,部分正确的话给60分,不正确的30分;并提出那里理解的有问题,非常感谢!!!
      

  2.   

    接口是个半成品
    半成品比原材料贵却比成品便宜
    :)
    一说到菜单 我就想起句柄还有reference和实例对象的比喻
    还有的就是我饿了
      

  3.   

    OLE就是一大堆接口定义,只要你遵循协议就可以在程序中嵌入其他程序。
      

  4.   

    有高人曾经说过
    接口是"like a"的关系
    抽象类是"is a"的关系而且就算是有什么like a/is a之类的说法,那也只是Java编写者希望你这么去做,就实际上来说抽象类和接口还是没有实用上的太大区别(不是指使用)
    只有一点比较大的区别,interface可以多重(继承,其实不是继承),而抽象类只能单继承
      

  5.   

    1正确
    2稍微有点问题,我估计在你的代码中的确是看不出什么区别
    因为这种区别往往是要构建和重构一个体系中才能看得出来。
    简单的来说,你确定你的代码中不需要有具体逻辑,不需要有必须的成员数据,那就应该使用接口
    反之,当你需要有共同的逻辑包括数据的时候,那就应该使用抽象类
    如果你必须暴露抽象类的一部分内部方法为public,或者你不能保证这个类一定是不变的或者这个类一定是最小集合。那就应该定义接口+抽象类实现换句话说,你应该保证接口不变而内部实现逻辑可变。也就是说,尽可能做到低耦合所以Collection是接口
    List是接口
    AbstractCollection是抽象类
    AbstractList是抽象类3没问题
    4事实上,java不会认为自己是多继承的。最简单,interface extends interface
    class extends class
    但是class implements interface
    事实上java应该把接口看成一种类似约定的东西,所以类去“实现”接口而不是“继承”接口
    从逻辑上说,接口是定义的方法体,而类是数据和方法的混合体。他们两者之间用继承来说明也是牵强的
    抛弃你的多继承的想法吧,继承是一件非常需要智慧的设计,如果贸贸然什么都用继承,那你很快发现你的体系盘根错节,再扩展一条线就几乎要重写。
    例如msn的例子,他分两种server,但是消息机制很特别,有的消息需要接受并返回一个id,有的不需要,但是不幸的是,两种server有时候共用一个消息但是回答是不同的。
    等写到发送消息的时候,同一个消息cmd有的是有id的,而有的没有link:http://www.hypothetic.org/docs/msn/index.php
    只是msn protocol 1.0,在4.0以后的消息机制ms似乎都没有公开,当然,对于这种公司来说,这是毫不为奇的。即便他一开始的确想要公开协议标准所以,先接口后抽象类,即便你发现需要构造共同方法,那在接口和具体类之间构造抽象类比抽象类和接口之间构造接口要容易得多