※ 引述《internaltide (internaltide)》之銘言： : 看了一些設計模式跟物件導向的書，都會提到一個觀念就是 : 多用合成，少用繼承 : 之後，自己在寫程式時有嘗試著多使用合成去取代繼承 : 但是發現被合成物件(物件C、D)要取得合成物件(物件A)的資料時都會很不方便 : EX. : // 物件A : class objectA{ : public static shareResources; : public attr1; : public attr2; : public objectC; //合成的物件C : public objectD; : public function func1(){...} : public function func2(){...} : } : // 繼承物件A的物件B : class objectB extend objectA{ : ~~~~~~~~~~~~ : ~~~~~~~~~~~~ : } : 可能同樣的物件內容B跟C，但實際上當要取得物件A的資料時 : 物件B可以很直覺的直接使用物件A的屬性或間接使用方法來取得資料。 : 但物件C就很麻煩了，變成我可能必須在A Class的建構式中時就要把資料 : 想辦法塞到C物件，搞到後來變成當D物件也需要相同資料時，我又得重複 : 塞相同的資料到物件D。 暈!! 看起來 class A 只是被當成存放資料的「結構」而不是當作承擔某些責任的行為者。 繼承 class A 若只是需要有一樣的結構，就只是單純在語法上用了繼承。 這是你的實作選擇。 設計上不管你要繼承還是合成， 重點是使用這組「類別」、「函式庫」的使用者覺得好用。 什麼情況是好用？要加新功能或擴充舊有物件很方便，能容易地面對需求改變 （但得需符合你設計時的考量，對未知的變化是難以掌握的） 真的站到設計模式的視野後，就不會再討論在寫法上是繼承還是合成。 在實作結構上，該用什麼就會用什麼，不會刻意去避免不用哪一種寫法。 以「裝飾者」來說，總得繼承要被裝飾的物件 （這是 java 這類靜態語言的觀點，不同語言特性就可能不同了^^） 他裝飾了之後，專注在改變原始物件的「外顯」行為。 對於他裝飾的物件，極少需要用它「內部」的資料。 所以，即使原來的資料有千百個 field 也不關他的事。 client side 只需要呼叫同樣的 method 即有不同的效果。 以我個人的想法，目前你被資料欄位細節的操作迷惑了。 目前你的變化是，有「新需求」就得同時加新的「類別」 並改變「原始設計」裡的 shareResources。 這明顯是個不優的設計，為什麼呢？ 因為提供原始設計的人，跟後來使用的人不一定是同一個人。 也可能不是同一個公司，也可能沒有 source code。 於是加新東西要改原始的設計是極不合理的情況。 我前面提的裝飾者模式就是一種不會動到原始設計的情境。 多數的設計模式書籍也都在繞著這些核心打轉 本質上它們就是「開放封閉原則」目前你的設計就不合乎這原則。 而隨著新功能的擴充，不斷變大的 class A， 就會漸漸失去原先設計它的本意，打破「單一責任原則」只是時間的問題 （或早就不符合了） : 後來，我都是直接在物件A設了一個名為shareResources的陣列並宣告為Static， : 再把所有共用資源都往那個陣列塞。 : 然後，無論合成物件或繼承物件都可以直接取用物件A的資料了。 : 不曉得做法好不好，有沒有大師提供更聰明的方法?? 「感覺」起來是不必要的修改。 如果先出道的 A 獲得了一個新的資源 x 在 shareResources 內， A 知道該怎麼用它嗎？顯然 A 不會知道，但 A 可能在設計時對 shareResources 有某些預想，例如 A 有權可以 reset shareResources 內的所有的東， 若 A 的子孫觸發了這個 reset 的動作，再來使用 x 就會產生非預期的效果。 為了避免這種非預期的情況，細心得設計者每次修改時，就得檢簡 A 以及「所有」繼承 A，且可能觸發 reset 動件的類別，是否有機會存在特定的 call sequence 後，產生 side effect。 對於剛接手 code 的人，就沒 sense 要「檢查」那麼多部分才不會弄壞「設計」 那就可能一邊開發，一邊替 bug 產生的「加速度」增加。 聽起來就冷汗直流，on borad 後看到這樣的情況， 會想「還是趁大家還不熟，換下一家唄」 那新增的 x 只是一個說例，它可以推擴成 y, z, ...。 說到道，當你在最原始的設計變更加入 x 後，那它就是整棵繼承樹共通的責任了。 大家都有責任維護皇城內(shareResources)的和平。 設法把責任(x)分散到獨立的物件，大家的「共業」少一點，皇城的分爭才會少一些。 不用常常莫名奇妙出 bug，再想辦法推動和諧社會。 Design Pattern 看人蔘，如此警世吶～～ --

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