最近買了本設計模式的書，名字叫《設計模式之禪》。這是我第一本設計模式的書，看了幾章了感覺自己受益匪淺，所以想就把自己感覺到比較有意思的設計模式知識分享給大家。
首先說一下我們程式設計師為什麼要學習設計模式把！下面是引用書上的原話：
你是程式設計師，沒有問題，通過學習設計模式能夠讓你寫出更加高效，優雅的**；
你是架構師，那更好，設計模式可讓你設計出健壯，穩定，高效的系統，並且自動地預防未來業務變化可能對系統帶來的影響；
你是專案經理，也
ok，設計模式可以讓你的工期大大縮短，讓你的專案團隊隊員快速地理解你的意圖，最終的成果就是優質的專案：高可靠性，高穩定性，高效率和低維護成本。
那麼我們看完這幾行話後，是不是有一種很想學習設計模式的感覺呢？反正我看完這幾行話後特別想把書讀完啊！呵呵
~~~
好了，額不再廢話啦！開始切入正題吧！
設計模式分為
6 大設計原則和
23中設計模式。
6大設計原則
分別是：單一職責原則；黎克特制替換原則；依賴倒置原則；介面隔離原則；迪公尺特法則；開閉原則。
23種設計模式
分別是：單例模式；工廠方法模式；抽象工廠模式；模板方法模式；建造者模式；原型模式；中介者模式；命令模式；責任鏈模式；裝飾模式；策略模式；介面卡模式；迭代器模式；組合模式；觀察者模式；門面模式；備忘錄模式；訪問者模式；狀態模式；直譯器模式；享元模式；橋梁模式。
這篇博文，我想主要介紹一下
6 大設計原則中的單一職責原則。
單一職責原則的英文名稱是
single responsibility principle
，簡稱srp
。這個設計原則備受爭議，那麼爭議之處在**呢？就是對職責的定義，什麼是類的職責，以及怎麼劃分類的職責。
rbac
模型（role-based access control
），基於角色的訪問控制，通過分配和取消角色來完成使用者許可權的授予和取消，使動作主體（使用者）與資源的行為（許可權）分離。下面我們來看乙個類圖：
通過這個介面的設計，我們可以發現有一些問題，因為使用者的屬性和使用者的行為沒有分開。我們應該把使用者的資訊抽取成乙個
bo（ bussness object
，業務物件），把行為抽取成乙個
biz（ business logiz
，業務邏輯），那麼我們就可以對這個類圖進行修改：
我們重新拆分成兩個介面，
iuserbo
負責收集和反饋使用者的屬性資訊，
iuserbiz
負責使用者的行為，完成使用者資訊的維護和變更。
分清職責後的**就可以如下：
iuserbiz userinfo = new userinfo();
//實現業務物件
iuserbo userbo = (iuserbo)userinfo;
userbo.setpassword("wzk");
//實現業務邏輯
iuserbiz userbiz = (iuserbiz)userinfo;
userbiz.deleteuser();
上面我把乙個介面分成兩個介面的動作。就是依賴了單一職責原則，所以單一職責我就可以理解為：應該有且僅有乙個原因引起類的變更。
下面我們還是通過乙個**通話的例子來進一步說明單一職責原則，大家都知道我們在通**的時候會有以下過程發生：撥號，通話，回應，掛機。這個介面類圖如下：
這樣我們的**就可以這樣寫：
//撥通**
void dial(string phonenumber);
// 通話
void chat(object o); //
通話完畢掛話
void huagup();
這是書中一段源**，我開始認為這個介面是符合單一職責原則的，但是仔細分析後，發現它其實包含了兩個職責：乙個是協議管理，乙個是資料傳送。
dial()
和 hangup()
兩個方法實現的是協議管理，分別負責撥號接通和掛機；
chat()
實現的是資料的傳送。那麼我們在現實生活當中協議接通和資料傳送都會發生變化，所以我們可以將介面拆分成兩個介面，類圖如下：
這個類圖就完全符合單一職責原則的要求了，每個介面職責分明，結構清晰，那麼我們的手機類要把
connectionmanager
和 datatransfer
組合一塊才能使用。組合是一種強耦合關係，都有共同的生命週期，我們使用這個強耦合關係不僅不如使用介面實現的方式，並且還增加了類的複雜性。下面我們就來修改一下這個類圖：
這樣子設計就變成了，乙個類實現了兩個介面，把兩個職責融合在乙個類中。
那麼通過上面的例子，說明單一職責原則有什麼好處呢？引用書上一段話吧！
（1）類的複雜性降低，實現什麼職責都有清晰明確的定義。
（2）可讀性提高。
（3）可維護性提高。
（4）變更引起的風險降低。
注意：單一職責原則提供了乙個編寫程式的標準，用「職責」或「變化原因」來衡量介面或類設計得是否優良，但是「職責」或「變化原因」都是不可度量的，因專案而異，因環境而異。
對於介面，我們在設計得時候一定要做到單一，但是對於實現類就需要考慮多方面因素了。生搬硬套單一職責原則會引起類的劇增，給維護帶來非常多的麻煩，過分細分類的職責也會人為地增加系統的複雜性。
還有就是類的單一職責可能會受很多因素的制約。比如說：專案工期，成本，人員技術水平，硬體情況，網路情況等因素。所以說對於單一職責原則，引用作者一句話就是：介面一定要做到單一職責，類的設計盡量要做到只有乙個原因引起變化。
《設計模式》雜記之單一職責原則
收藏,編輯 最近買了本設計模式的書，名字叫 設計模式之禪 這是我第一本設計模式的書，看了幾章了感覺自己受益匪淺，所以想就把自己感覺到比較有意思的設計模式知識分享給大家。首先說一下我們程式設計師為什麼要學習設計模式把！下面是引用書上的原話 你是程式設計師，沒有問題，通過學習設計模式能夠讓你寫出更加高效...
設計模式之單一職責原則
關於單一職責原則，我想大家都聽過不少，今天來看看這個原則具體是什麼，有哪些好處使我們需要選擇遵守它呢？一 定義 乙個類只能因為乙個原因而修改。怎麼理解呢？簡單來說，乙個類只能實現一項功能，或者換句話說，乙個類只有乙個職責，只有當這個職責發生變化，它才會被修改，說白了就是乙個類質感乙個類該幹的事。二 ...
設計模式之單一職責原則
首先就名字而言不難想象，單一必定是只能有乙個，而這個乙個指的是什麼呢，那就是乙個職責。而職責通俗易懂來說就是乙個功能，乙個類只能有乙個功能，而如果有兩個及以上的功能就不再符合單一職責原則了。就好比乙個水壺，它的功能就只是裝水，而不存放別的東西，那它就滿足了單一職責原則。優點有複雜度低，或者說簡單明瞭...