※ 引述《kazenol (随便啦)》之铭言： : 嗯...这边我的问题是，物件的compareTo方法，可不可以直接定义在物件的class里？ 可以，但是你有仔细看我说什麽吗？ 每个物件的比较方法会一样吗？不会嘛 : 因为物件去继承介面，也是要在自己里面去定义方法，那为什麽不自己来呢？ 你是不是搞错什麽东西了？本来就是这样啊 @_@ 既然要自己去定义，自然是要自己来了… 我们不会说「继承介面」，而是「实作介面」 因为继承类别和实作介面其实是两回事 : 从多重继承的字面来看，应该是会使用到父母类别的方法或变数，可是介面里写的 : 东西，除了跟父母类别的方法同名以外，我不知道继承介面可以得到父母类别的什麽 : 东西？而且其他不是父母类别的类别，万一有了同样名称的方法，那不就变成同时也 : 去继承这个第三者了？ no no... 我觉得你好像有很大的误解…似乎有搞错继承的定义… 这样的话谈这些设计就没有意义罗，因为只会误解… 首先，你的最後一句话绝对是错的 同样的名称跟实作介面没有关系 class A{ public void test(){} } class B{ public void test(){} } A 和 B 没有任何关系 Java 里谈到的 interface... 是窄化的介面 @@ 不要被名词混淆了 : 其他几位大大的写法，我能理解其中的：先定义一个规范，其他要继承这个类别的 : 就要去把规范的内容写出来。就好像是体委会丢一个建立二军的公文要求中职六队 : 去建立二军，但是体委会什麽目标、进程都没有，要六队自己提出建立二军的规划表 : 然後上缴体委会，所以六队提出的内容也会不一样，但是基本上都有依照体委会"建立 : 二军"的目标去做。 你这个说法比较像是实作介面 : 可是不见得每个二军规划表都有像la new一样有"球员专用餐厅"啊，如果要使用 : 二军.餐厅()这个func，不就会卡住？如果中职六队不去继承体委会这个介面，他们也 : 可以不用理会建立二军这个规范。那是什麽原因这些class必须去继承这个介面呢？ 看不太懂 @_@ 我觉得你可能要再多看一下书，并练习一下 然後那个 design pattern 离你还太远，不用去想那个 XD 再看那个只会更混乱而已 -- By Gamers, For Gamers - from the past Interplay --

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