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

看板OOAD作者 (有些事,有時候。。。)時間10年前 (2014/03/16 16:12), 編輯推噓1(100)
留言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

07/16 01:55, , 1F
07/16 01:55, 1F
文章代碼(AID): #1J9LpGOz (OOAD)
文章代碼(AID): #1J9LpGOz (OOAD)