※ 引述《qrtt1 (隱者)》之銘言： : ※ 引述《kazenol (隨便啦)》之銘言： : : 嗯...這邊我的問題是，物件的compareTo方法，可不可以直接定義在物件的class裡？ : : 因為物件去繼承介面，也是要在自己裡面去定義方法，那為什麼不自己來呢？ : : 從多重繼承的字面來看，應該是會使用到父母類別的方法或變數，可是介面裡寫的 : : 東西，除了跟父母類別的方法同名以外，我不知道繼承介面可以得到父母類別的什麼 : : 東西？而且其他不是父母類別的類別，萬一有了同樣名稱的方法，那不就變成同時也 : : 去繼承這個第三者了？ : : 其他幾位大大的寫法，我能理解其中的：先定義一個規範，其他要繼承這個類別的 : : 就要去把規範的內容寫出來。就好像是體委會丟一個建立二軍的公文要求中職六隊 : : 去建立二軍，但是體委會什麼目標、進程都沒有，要六隊自己提出建立二軍的規劃表 : : 然後上繳體委會，所以六隊提出的內容也會不一樣，但是基本上都有依照體委會"建立 : : 二軍"的目標去做。 : : 可是不見得每個二軍規劃表都有像la new一樣有"球員專用餐廳"啊，如果要使用 : : 二軍.餐廳()這個func，不就會卡住？如果中職六隊不去繼承體委會這個介面，他們也 : : 可以不用理會建立二軍這個規範。那是什麼原因這些class必須去繼承這個介面呢？ : http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/ : StrategyPattern.htm : Strategy Design Pattern 通常用這樣的機制去實踐的 : 也許您可以先看看感覺一下作者的意圖 : 我們不能以程式的觀點來看這個問題! 因為寫法有很多種。 : 但是要如何使程式達成鬆散的耦合則是一整個系統中的重點之一 : 您確時可以把演算法寫死在同一個class之內 :) : 含有這隻演算法的物件, 可能無法輕易更換 : 因為演算法是針對這個物件而寫 : 反之，演算法也無法重複使用在別的物件之上 : 因為被綁死了，也就是傳說中的交互性耦合 : 這樣就失去了物件導向期待reusable的目標了 我大致能了解作者的意思，也明白您的意思。如果不讓演算法只是針對這個物件而用 ，讓別的物件也能使用，用繼承我能理解，可是介面裡只是一個演算法的名稱，而實際 的演算法還是要寫在實作的物件裡。那麼不管父母類別裡的演算法函式怎麼寫的，去繼承 介面的子物件應該是看不到父母類別裡的方法，充其量是兒子知道父母有錢，但是怎麼 賺來的不知道，自己得要去想賺錢的方法。就算父母類別想將賺錢的演算法傳給其他人， 因為介面不准寫方法，也只能定義要賺錢()、會賺錢()這樣的口頭話。 所以我一直不懂的是，介面的多向繼承，到底是繼承了什麼？為何要去繼承？ 介面寫的都是一些空的名詞啊，既沒繼承到實質的方法與變數，同時子物件自己也必須 要寫自己的方法。 我唯一能想到的解釋是。一個人coding可以知道哪邊要做什麼事，跟一堆人coding可能 就有個主設計師把規則先寫出來，後面的人都得照這規則去繼續寫，就像是把大綱寫在 程式裡這樣吧。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.109.174.241