六大原則之單一職責原則
1、什麼是單一職責原則
單一職責比較官方的的定義是:應該有且僅有乙個原因引起類的變更。說的通俗點其實就
像是工廠裡的流水線一樣,每個車間基本上只做一件事,所有車間組合起來就是乙個生產流程。我
們寫程式的時候也可以這樣,將乙個類的功能細化一下爭取做到乙個類只做一件事。
到多各類去會讓程式變的很複雜?其實利用乙個類做多件事雖然可以減低程式的複雜度,但是他帶
來的確實更大的兩個問題:(1)、第乙個問題是:對於乙個比較複雜的程式,乙個類的分工不明
確會造成在寫程式時的混亂,傳個引數可能要想半天這樣就大大的影響了寫程式的效率。(2)、
第二問題是:乙個專案不可能會一次成型,後期會對他進行擴充套件或者是維護,類的分工不明確在這
時就會牽一髮而動全身,本來做乙個類的修改就行的,但是因為高耦合使得我們必須對多個類進行
修改。在商業上會增加成本,在學習上變的高效。
2、單一職責原則的特點
(1)、類的複雜性降低,實現什麼功能都清晰明確的定義;
(2)、可讀性提高,複雜性降低;
(3)、可讀性提高,則是可維護性提高;
(4)、變更引起的風險降低,變更是必不可少的,若介面做好單一原則,對系統的擴充套件性
、維護性都有非常大的幫助;
3、有對比才有高下
舉乙個使用者資訊管理系統的例子,用兩種不同的方式寫的,乙個用了單一職責原則,乙個沒用。
我們先看沒用的那個:
public class userinfo implements iuserinfo
public void setusername(string username)
public string getuserid()
public void setuserid(string userid)
public string getpassword()
public void setpassword(string password)
//修改使用者密碼
public boolean changepassword(string oldpassword)
//刪除使用者
public boolean deleteuser()
}
此類有設定使用者名稱、設定id、設定密碼、增刪改等功能。
整個使用者管理系統的類圖如:
戶管理系統的類圖1
大家其實可以清晰的看到,這個類總體上來說有兩個功能,乙個是儲存使用者資訊;乙個是對系統內的使用者資訊進行管理。這麼寫也能達到我的目的,但是在後期的修改上會有比較大的問題,假如我要在使用者的資訊中新增一項屬性e-mail那我要對iuserinfo介面進行修改,又假如我要對在管理系統中新增乙個查詢的功能我又得去修改
iuserinfo
介面這樣當這個使用者管理系統複雜以後容易造成邏輯混亂。
其實只要我們對這個使用者管理系統的程式進行乙個小小的修善就能讓它變的清晰明朗,我們又何樂而不為呢!以下是對此管理系統的乙個小的改進類圖如下:
使用者管理系統的類圖2
使用者管理系統的類圖2就基本上是每乙個類的工作劃分清晰了,其實這也就是單一職責的基本原理。
4、感悟
總的來說這些設計模式的原則,他是死的,主要是看我們怎麼去運用它。這個單一職責的原則在每個類的設計中都可以用到。他就好像是公司的每個職位一樣的,每個人都分配有自己的職責,你也志勇對你自己的任務負責就行了。
「過猶不及」這句話相信大家都聽過,這句話放在這也是乙個提醒。雖然單一職責的原則好,但是我有時候切不可將乙個類劃分的太過於細緻,就是我們打**的步驟:撥通**、通話、結束通話**。這個我們不僅可能去每一步都去建立乙個類,說是按照單一原則每乙個步驟都進行劃分,這樣就屬於鑽了牛角尖的哪種。其實不管是我們的程式還是我們的生活中都要注意「過猶不及」這個詞,萬事萬物都是有乙個度的超過了這個度就容易鋼過易折。有人肯定會問了:那麼這個度我們應該怎麼去把握呢?在這我只能:「呵呵」一聲,然後告訴你這個完全要憑修為去把控。
5、單一職責的原則的優缺點分析
優點:分工清晰明朗,做到引起變化的只有乙個原因,出錯時能快速鎖定位置,也利於維護與擴充套件。
**靈活。
缺點:在比較小的專案中,會造成系統的複雜度增加的情況,類的增多會對執行效率有影響。
程式設計六大原則之單一職責原則
定義 乙個類只有乙個發生變化的原因。通俗的說,乙個類只負責一項職責。又稱單一功能原則,適用於介面 方法 類 原理 如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力 優點 降低類的複雜度 提高類的可讀性 提高系統的可維護性 變更引起的風險降...
設計模式六大原則之 單一職責原則
規定乙個類只有乙個發生變化的原因。通俗理解為 乙個類只負責一項職責。類t負責兩個不同的職責,當職責p1改變需求時需要修改t類,這時候就有可能因為修改的邏輯導致職責p2出現故障 遵循單一原則,建立兩個類t1和t2,在修改t1的時候不會影響t2,同理,修改t2的時候也不影響t1的邏輯 類的單一職責比較難...
設計模式六大原則 單一職責原則
設計模式六大原則 1 單一職責原則 定義 不要存在多於乙個導致類變更的原因。通俗的說,即乙個類只負責一項職責,乙個人只負責做一件事。乙個類,只有乙個引起它變化的原因。應該只有乙個職責。每乙個職責都是變化的乙個軸線,如果乙個類有乙個以上的職責,這些職責就耦合在了一起。這會導致脆弱的設計。當乙個職責發生...