※ 引述《kazenol (随便啦)》之铭言： : ※ 引述《godfat (godfat 真常)》之铭言： : : 因为在物件导向的程式撰写里，我们常利用基类别或介面的变数去操作 : : 另一个实际存在的子类别或介面实作者。但是有时候那个基类别其实不 : : 需要做太多事情，也就是说，可能只有很少很少的 public method, : : 甚至是只有一个，更有甚者，这个实际存在的子类别或介面实作者， : : 他可能已经继承自另一个基类别了。这时候如果我们没有 interface : : 这个东西的话，就势必得用多重继承了。而多重继承在物件导向中是个 : : 争议一直很大的东西…。也就是说 Java 利用了 interface 的机制来 : : 解决我们对於多重继承的需求。 : : 这是个不好的例子…因为看不出来这样做的用意是什麽。就拿我前几天 : : 在试的东西举例好了。假设我们要写一个泛型排序法，所谓泛型排序法 : : 就是对任何有排序准则的东西做排序。那麽我们该怎麽知道所传进来的 : : 物件具有比较能力？以下是乱写的 Java code, 不一定能跑，只是为了 : : 呈现概念。 : : void sort(Comparable[] input){ : : if( input[0].compareTo( input[1] ) == 1 ); : : } : : 好吧，这完全不能跑 XD : : 我们没办法得知各种物件间需要用什麽方法来比较大小。比方说二个 : : 个人资料，我们应该怎麽去比较他们之间的顺序？是看名字呢，还是 : : 看编号？也就是说，我们完全没有必要去规范 compareTo 应该怎麽 : : 实作。更有甚者，因为 Java 没有多重继承，如果你让你的物件去 : : 继承了 Comparable, 那你原先物件的继承体系怎麽办？重写？摆烂？ : 嗯...这边我的问题是，物件的compareTo方法，可不可以直接定义在物件的class里？ : 因为物件去继承介面，也是要在自己里面去定义方法，那为什麽不自己来呢？ 因为有时可能会有一个以上的class去继承同一个class或者说interface 像某些design pattern里如果说要一视同仁的话就得以这种手法 或许这样说吧 先定义一个车子的模子 然後我们可以用他来做出汽车、卡车....etc : 从多重继承的字面来看，应该是会使用到父母类别的方法或变数，可是介面里写的 : 东西，除了跟父母类别的方法同名以外，我不知道继承介面可以得到父母类别的什麽 : 东西？而且其他不是父母类别的类别，万一有了同样名称的方法，那不就变成同时也 : 去继承这个第三者了？ : 其他几位大大的写法，我能理解其中的：先定义一个规范，其他要继承这个类别的 : 就要去把规范的内容写出来。就好像是体委会丢一个建立二军的公文要求中职六队 : 去建立二军，但是体委会什麽目标、进程都没有，要六队自己提出建立二军的规划表 : 然後上缴体委会，所以六队提出的内容也会不一样，但是基本上都有依照体委会"建立 : 二军"的目标去做。 : 可是不见得每个二军规划表都有像la new一样有"球员专用餐厅"啊，如果要使用 : 二军.餐厅()这个func，不就会卡住？如果中职六队不去继承体委会这个介面，他们也 : 可以不用理会建立二军这个规范。那是什麽原因这些class必须去继承这个介面呢？ : : 然後你这一段最後一句提到其他小孩的唱歌运动是否会跟原本的一样。 : : 基本上假使你用到了动态多形机制，意思就是你不要求他们的唱歌运动 : : 是否一样了。所以这根本不是问题，反而是原则。动态多形就是要每个 : : 不同的物件间行为不同而诞生的。而这个行为虽然各自不同，却有着相 : : 同的意义。比方说你要所有的小孩表达快乐，那麽有的小孩可能是唱歌， : : 有的可能是运动（好啦这是很怪啦），不管他用什麽方法表达，你的命令 : : 就只是要求他表达快乐，而这也只是你想要的。反之，就不是动态多形 : : 要做的事，设计方向错误。 : : 不懂介面的话会有很多问题喔 @_@ : : 不过我个人认为多重继承还是有必要的… Java 的介面并没有完全解决 : : 问题。至於其他的语言对於多重继承的解法，就我所知还有 mixin, : : D 语言和 Ruby 就是以 mixin 来解决的。但不要问我 mixin 是啥， : : 还没研究过 XD : : 顺便一提，就我所知有多重继承的是 C++ 和 Common Lisp, 其他有点忘了 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.138.19.203