推 ppc : 推 07/16 01:55
※ 引述《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