部分內容恕刪 ※ 引述《yoll522 (幽靈)》之銘言： : 如果說現在要組一個team : Team { : 醫療忍者 m = new 綱手(); : 忍者 n = new 自來也(); : 隊長 o = new 飛猿(); : } : 就好像說，我都知道鋼手要當醫療忍者了，也知道飛猿要當隊長 : 那為什麼寫程式時不就乾脆寫成 : Team { : 鋼手 m = new 綱手(); : 自來也 n = new 自來也(); : 飛猿 o = new 飛猿(); : } : 這樣呢? : 如果忍者這父類別有一個abstract的招換術需要子類去定義他 : 那繼承忍者的所有類別，都一定會去定義招換術不是嗎? : 那既然繼承的子類都定義了，那麼所有的方法也都可以安心使用不是嗎@@? : 就像前面的文章所說的 : 忍者 n = new 自來也(); : 忍者 m = new 綱手(); : n.招喚術(); // 文太出現了 : m.招喚術(); // 蝸蝓出現了 : 因為自來也、鋼手都是繼承忍者的，所以他們肯定會定義招換術，那麼程式寫成 : 自來也 n = new 自來也(); : 鋼手 m = new 綱手(); : n.招喚術(); // 文太出現了 : m.招喚術(); // 蝸蝓出現了 : 這樣也沒錯不是嗎@@? : 拜託各位幫忙解除小弟的疑問，謝謝大家 你說的都沒錯 在這些情況下程式也的確能正確執行 但是當你要改程式的時候就不一定了 因為宣告了 綱手 m = new 綱手(); 之後所有m的使用都會當成是綱手在用，而不會是當成醫療忍者在用 接著一些只有綱手有而醫療忍者沒有的function就可能被使用，比如說出現: m.創造再生之術(); 這樣的程式碼 但是當某一天你必須"修改"程式碼將醫療忍者換成別人(ex:時音)的時候: 綱手 m = new 時音(); // 不能這樣這樣寫，compile也不會過 你必須這樣寫: 時音 m = new 時音(); 然後你就會發現原本寫 m.創造再生之術(); 的地方全部掛掉要重寫 已經想好的戰術都必須因為時音沒有創造再生之術()而整個改掉 一但去修改既有的邏輯(戰術) 過程中就可能產生新BUG 而且容易導致系統不穩定 但是上述的這個問題在你用 醫療忍者 m = new 綱手(); 的情況下是不存在的 因為你當初在設計戰術 是假設那是個普通的醫療忍者 而不是綱手 你不會在戰術內考慮 m.創造再生() 這件事情，你只會考慮普通醫療忍者會的招數 所以即使之後需要改變小隊配置 改為 醫療忍者 m = new 時音(); 所有和 m 相關的部分都不用去改動 就算產生新BUG也一定是class 時音哪邊寫錯了 馬上就知道有問題的範圍在哪 這種將涵式介面抽像的技巧 基本上都是在為後天的修改鋪路 (這邊不考慮一些特殊技巧如command pattern / abstract factory pattern 的情況) 只要我們定義好 醫療忍者 會的東西有哪些 在使用上就可以放心使用 不需要去管管今天頂替這位置的是綱手還是時音 就算後來想換成小櫻也沒關係 你可能會問 "那我不就不能使用綱手的招數了嗎?" 這邊就會牽扯到最開始設計小隊的邏輯 你的小隊邏輯是: 一個小隊由三個忍者組成: 醫療忍者 + 隊長 + 忍者 即： Team { 醫療忍者 m = ..... 隊長 n = ...... 忍者 o = ...... } 醫療忍者是誰並不重要 只要是醫療忍者就好 不用去考慮醫療忍者是不是綱手的問題 因此使用抽像的醫療忍者便足夠了 你不要去管到底那個醫療忍者是誰 這樣的情況下 你只會設計出通用的戰術 因此可以任意換上不同的醫療忍者 但如果今天我們要出的是SS級任務，必須由三忍合力組隊　你的小隊會變成這樣： 三忍Team { 綱手 m = new 綱手(); 自來也 n = new 自來也(); 大蛇丸 o = new 大蛇丸(); } 你在思考這個三忍Team的戰術時會直接認定這小隊的組成就是 綱手 + 自來也 + 大蛇丸 你不用去考慮由佐助頂替大蛇丸的情況 因為這隻小隊就是只能由三忍組成 這隻小隊的戰術就是為這三個人而專門設計的 換成任何人都不成立 因此這隻小隊要換別人來組的情況是不存在的 自然不用去思考換人的問題 這時候直接宣告為綱手/自來也/大蛇丸就沒有問題 因為邏輯上根本就不會有換人的情況 說了這麼多 其實就是好不好修改的問題 宣告為父類別則功能自然比較少 因為有些function只存在於子類別 比如說創造再生() 但也因為使用上有限制 換人頂替這個位置就不用擔心出狀況 因為只要是醫療忍者就ok 而如果打從一開始這位置就非得是子類別不可(比如說非綱手不可) 自然也就沒有修改的需要 因為不管改成誰都和原本的邏輯(由三忍組隊)相違背 (除非你就是想修改程式的邏輯 不過這本來就要重寫不是嗎？ 因為不再是三忍Team了) 這個問題其實是所謂的耦合(coupling): 耦合度越高的程式越難修改=> 思考戰術時預設立場越多 這戰術就越少隊伍可以使用 反之耦合度越低的程式越好修改=> 這戰術只要是醫療忍者+隊長+忍者的小隊 就一定能用 最後則是 如果你的程式完全不考慮未來修改和維護的話 耦合度多高其實都沒關係XD (但如果是開發大型程式 中間發現有bug要修改程式碼 你可能會哭出來:P) --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.243.110.120 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1405790781.A.742.html