Re: [概念] single responsibility principle

看板OOAD作者leondemon (狗狗)時間15年前 (2010/02/26 00:49)推噓1(1推 0噓 4→)

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

※ 引述《hsnucsc (hsnugo)》之銘言： : 我也有找到另一個方法, 是增加interface : http://www.codingefficiency.com/2009/07/18/ : solid-s-single-responsibility-principle/ : http://0rz.tw/QP6hs (縮過的網址) : 不過仍然讓人很難分辨responsibility : 說嚴格一點, 好像每個method, 都有理由改變 : 但是又不可能把每個method都新增一個物件去處理這項功能 : 希望有人可以幫忙解答 : 謝謝我發現我沒有回答到你問的問題 Orz (結果我打那麼長的廢話 -.-) 你說的沒錯「好像每個method, 都有理由改變」但是是否有需要將所有的屬性或方法全部分開封裝？這個問題就要看你是做什麼樣的專案了！有些專案某些類別幾乎是不會變化那麼你將它封裝的很細就只是白花功夫但是有些類別很容易被要求改變那你去使用design pattern就會有效果... 這完全視你的專案目的而定所以才會在專案一開始就先做OOA&D 你才會知道這個專案哪些部分很容易發生改變而需要使用pattern 這個responsibility完全是看專案需求而定不過即使在一個專案下有一些物件是完全不需要使用pattern來重新封裝(因為很少改變) 但是如果你有「先見之明」覺得這些物件很可能會在將來其他專案被reuse 那麼先套上pattern可以有利於將來的再使用甚至是專案和專案之間的整合另外「針對介面寫程式」這句話就是告訴你SRP的思維事實上「真正要履行SRP的就是介面」專案一開始真正要規劃的並不是要規劃產生多少個類別而是要規劃需要多少個介面(或是抽象類別，以下所說的介面都包含抽象類別) 每個介面都是被規劃來處理某些事情而這些介面必須遵守SRP原則當一個介面在這個專案下會因為兩個截然不同的理由而需要修改時就必須考慮將介面拆開並藉由reference來couple到抽離出來的介面 (介面的coupling等於實體類別的鬆耦合因為是綁介面而不是綁特定的類別) 最後才去實作你的實體類別若是一個介面之下只會有一個類別去實踐這個介面(也就是變更需求不大) 通常我們就不會花功夫去做介面直接在該實體類別去實踐這個介面就好而其實剛剛說的一整個過程就是依賴倒轉原則 Dependency Inversion Principle(DIP) 什麼「細節應該依賴抽象，抽象不應該依賴細節」這句話聽聽就好因為用這種文言文講給初學者聽根本一點效果都沒有講白一點先將「專案的需求」轉成「介面或抽象類別」而每個「介面或抽象類別」都必須只為一種「專案需求的變化」才會改變這個「介面或抽象類別」所承擔的就是單一個變化的responsibility (SRP) 把這些「介面或抽象類別」依循固定規則方式來耦合起來就是使用design pattern 最後才去實踐這些「介面或抽象類別」變成實體類別就是依賴倒轉原則而要怎麼知道一個「專案」會有多少「專案的需求」就是靠OO analysis (靠經驗可以) 回到一開始你問的「好像每個method, 都有理由改變」就端看你的OOA做出來的結果是如何啦～ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 203.77.52.127 ※ 編輯: leondemon 來自: 203.77.52.127 (02/26 00:50)