Re: [概念] single responsibility principle

看板OOAD作者leondemon (狗狗)時間15年前 (2010/02/25 20:35)推噓3(3推 0噓 6→)

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

※ 引述《hsnucsc (hsnugo)》之銘言： : 我找了很多網站 : 都將解釋SRP成: 每一個物件, 應該要只有單一的responsibility : 而將responsibility解釋成: 只有一個理由去改變物件 : 但是我還是覺得responsibility這個詞很模糊看了一下你的po的兩篇文我想你對於OO的design pattern應該是不熟悉我會強烈建議你先去念Design Pattern 自然而然就會知道這些原則是怎麼回事以及知道什麼才是真正的OO programming 一般來說要寫OO程式初學者會直接硬幹也就是列出會用到的物件類別之後就開始拼命對class塞attr和method 然後遇到分歧處就開始subclassing 但是這樣的編寫程式只會造成後續的麻煩尤其是在維護上（無論是擴充或是修改）當你開發到一定規模的程式時修改程式碼往往比開發新功能更花時間而OO design pattern就是這個現象的救世主在四人幫(GoF)的Design Pattern (1994)中書皮就講明了"Elements of Reusable Object-Oriented Software" 它闡述了一個OO的程式碼該如何撰寫才能讓程式具有彈性在不同的情況下大都有適合的pattern可以使用而當你使用了這些pattern 將會對於你未來對於這些程式碼的維護或再利用有很大幫助你看的Head First OOA&D 事實上它是再開始撰寫程式碼之前的動作先明確的確定該如何撰寫再去實作簡單的說就是「謀定而後動」較好的寫OO流程是 1. 先做 OO analysis & design 2. 再用 OO design pattern決定該如何實作 3. 最後 OO programming撰寫程式碼如果你不懂為什麼要先做OOA&D 是因為你不知道中間有design pattern的步驟或是無法體會design pattern所能帶來難以想像的幫助正常情況下 OOA&D可以幫助你了解各個物件類別該套用到哪些design pattern 以及整個程式完整的架構(如果你有好好做UML圖的話) 如果要學完整的OO programming 則在學完基本OO特性、如何使用物件及如何撰寫程式碼之後會先完整學完OO design pattern(OODP) 最後才去學OOA&D 關於Design Pattern的學習我會建議你先去看「大話設計模式」（程杰著）它比較適合新手同時搭配http://www.oodesign.com/ 這個網站先確定把這些所有提到的DP都弄懂精髓所在以及所有OO原則之後再去看Head First Design Pattern才會更了解這本書在說什麼當你徹底的了解OO原則的精髓就能自然而然的使用design pattern了所以當你再去學OOA&D 就能夠對於新的專案開發能快速切入要點最後關於你問的SRP原則事實上是OO設計原則的一部分它的前提順序是這樣的： 1. 當你程式需要改變時你應該是增加新的程式碼而不是修改舊的 (OCP) =>簡單的說已經寫好的程式(或說是封裝好的) 則不應該再去更動原有類別更改已經寫的程式碼通常不會有什麼好下場往往只會弄得一團亂當你要修改一個類別時你就是在破壞它原有的封裝這是不好的現象而這部份可以藉由多型來完成 2. 情非得已下必須修改現有的程式碼時則你應該只需修改一個類別(或是最少類別) =>簡單的說如果你只需要修改一個類別就比較能夠追蹤修改後的影響這部份可以藉由封裝「因為一種理由而產生變化」的程式碼到一個類別來完成 3. 程式碼中絕對不能含有相同的演算法你必須把相同的部份抽取出來才能達到2的原則 =>簡單的說就是因為你要改這個演算法時你不用再去一個一個類別去改這樣就不會遺漏哪些部分忘了修改而造成debug的大災難這部份會因為不同的狀況有適合的design pattern可以使用 4. 當你要修改一個類別時你應該只會因為一種「原因」而去改它 (SRP) =>簡單的說當你要「拆開(或說是修改)」一個已經封裝的類別時你應該只會修改跟這個原因相關的程式碼其他的就不會動到但是當你封裝在一起時你就有可能會不小心動到 (哪怕是你上個廁所時被你家的貓踩鍵盤) 因為你不會去花時間檢查你預期完全沒有修改到的部份所以一但同時被「開放」修改時你是在增加風險 (早叫你雞蛋不要放同一籃了) 而這部份可藉由封裝不同原因才會修改的程式碼來達成 PS 事實上這是要減少耦合增加reuse的機會 5. 這是OO programming中最恐怖的單字：耦合(coupling) =>基本上所有的design pattern和OO原則都是圍繞在這個單字其實coupling的意義就是「把兩個東西綁在一起」(這年代講耦合誰聽得懂阿！) 耦合(或說「緊的耦合」)只發生在3個狀況下： 1) inherit 2) reference 3) encapsulate 「緊的耦合」應該發生在兩個程式碼意義是99.99%以上的關聯時而任何間接方式就是「鬆的耦合」(例如多型) 我改用另一個例子來說明如果你把「eat():」和「fly():」兩個方法都「封裝」在Bird的類別當中你就是把這兩個method耦合在一起(這個耦合是藉由封裝) 但是這兩個method的意義是有99.99%以上的關聯嗎？我想是沒有因為會吃飯不見得就會飛 (不然我就不會坐在這裡長篇廢話) 當你下次要讓「狗」會吃飯時或是讓「飛機」會飛時你之前實作的程式碼就不能再利用 (當然例子不是舉的很好因為飛機的飛法和鳥的飛法是不一樣的) 汽車也是「引擎」的動力輸出和「方向盤」的使用介面並不互相耦合這兩樣只是跟「汽車」耦合 (直升機也有引擎但是沒有方向盤玩具車有方向盤但沒有引擎) 換句話說把「引擎」的能力和「方向盤」的功能都封裝在「汽車類別」裡有違原則哪天你想改車來替你的愛車升級引擎時你就要改原本汽車的程式碼啦！但是藉由設計模式你只需要將「汽車類別」去跟「引擎介面」耦合(不是引擎實體類別) 這樣的意思就是汽車的確是有引擎但是是哪顆引擎則可以有彈性的動態選擇簡單的說你就是藉由多型而可以彈性的讓汽車擁有不同的引擎但是如果你好不容易抽離出來成為多型的「引擎」程式碼卻將「方向盤」的功能也封裝在「引擎」的介面底下(封裝就是耦合啦！) 那麼當使用者選擇某顆引擎的時候他就被強制的安裝一個耦合在一起的方向盤(怒！) 反過來講當使用者安裝方向盤的時候也被強制換一顆引擎更扯的是當你想改裝你的方向盤時你也可以看到引擎的設計圖甚至可以偷改引擎 (因為你打開了已經封裝好的東西) SRP就是告訴你：「別在把風馬牛不相干的東西湊在一起坐撒尿牛丸啦！」其他的原則我就不贅述了基本上用design pattern之後你的程式碼有可能會拆得到處都是然後在檢視或使用一個類別時會搞不懂這個類別底層到底在幹嘛、要怎麼運行但是事實上你有做好documentation和UML圖的話就會很容易使用 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 203.77.52.127 ※ 編輯: leondemon 來自: 203.77.52.127 (02/25 20:40) ※ 編輯: leondemon 來自: 203.77.52.127 (02/25 20:42) ※ 編輯: leondemon 來自: 203.77.52.127 (02/25 21:24)