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