Re: [設計] 多用合成，少用繼承

看板OOAD作者qrtt1 (有些事，有時候。。。)時間10年前 (2014/03/16 16:12)推噓1(1推 0噓 0→)

留言1則, 1人參與討論串4/4 (看更多)

※ 引述《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