[心得整理] c# 物件導向程式 - 4.SRP單一職責原則

[心得整理] c# 物件導向程式 - 4.SRP單一職責原則

前言

要介紹SOLID原則是Robert C. Martin - Bob大叔(無暇的程式碼作者),提出的
用大神的經驗整理出來一些好的習慣,可讓物件導向程式寫的更優雅

單一職責原則 - 現實生活面

現實生活中,修理機車有專門修理機車的店,修理汽車有修理汽車的店
並不是 我要修理交通工具就跑到修理交通工具店裡面就可以修汽車和機車

因為規劃職責不同 如果你用修理交通工具的職責去想
那就會把修理汽車,機車,甚至是公車 都算這修理職責裡
當然不是不可以,只是現實世界沒有人這樣搞

再用另一個角度去想職責,把汽車當出發點
修理汽車,就不會跟修理機車混在一起了 對吧

單一職責原則 - 程式面

一個類別只有一個改變的理由 

意思就是一個類別應該只負責一個職責所以改變的理由只也有一個
但因為設想得出發點不同(是要用修理的角度,還是汽車的角度)
這是非常難作到完美的,對於不懂的領域要去請教專業的人
讓最懂這部份專業人士來切分職責,才不會設計出一個不適合的類別
或是包山包海萬用類別

對我來說 
SRP單一職責原則是心法,要隨時去想這類別是不是太複雜
是否要在切分成兩個類別,讓類別的職責只有一個
壞味道
當命名覺得困難的時候 也可以想一下是否太多職則了
當寫測試覺得很難寫的時候 也可能是太多職則要測試了

結語

SOLID原則 的S - SRP單一職責原則
是個標準知易行難的原則,但是把觀念記住就會時時警惕
這樣設計類別時,就會更去了解程式碼背後代表的意義
而不是需求拿到就一直打字囉

202-04-25補充想法

ICrud 的介面裡面定義四個方法有違反SRP嗎,還是拆成IReadable,IUpdateable…等呢
又或者IReadable,IModifyable
又或者先做四個介面繼承兩個最後在變成為一個
有需要做到這樣嗎
假設專案不能刪除資料 這樣刪除方法裡面就是空實作還是出例外,LSP呢
 

推薦閱讀

[ASP.NET]91之ASP.NET由淺入深 不負責講座 Day17 - 單一職責原則

OOP學習筆記 - SOLID的單一職責原則(SRP)

軟體路上不孤單Day10-物件導向原則介紹3[SRP]

亂談軟體設計(3):Single-Responsibility Principle

如果內容有誤請多鞭策謝謝