設計模式之單一職責原則single responsibility principle 簡稱srp
定義：應該有且僅有乙個原因引起類的變更
使用者管理類的介面：
（該介面設計存在問題，使用者的屬性和使用者的行為沒有分開，這是乙個嚴重的錯誤。我們應該吧使用者的資訊抽取成乙個bo（bussiness object，業務物件），把使用者的資訊抽取成乙個biz(business logic, 業務邏輯），如下圖所示）
使用時，要獲得使用者資訊的，就當是iuserbo的實現類，要是希望維護使用者資訊，就把它當成iuserbiz的實現類。
在實際使用中，我們更傾向於使用兩個不同的類或介面：乙個是iuserbo，乙個是iuserbo，類圖如下：
單一職責原則的應用：
**通話時會有四個過程：撥號、通話、回應、掛機，那我們寫乙個介面，類圖如下：
現在可以很容易的根據單一職責原則說它設計的有問題：這個介面擁有兩個職責：乙個是協議管理（dial（）和hangup（），分別實現撥號和掛機），乙個是資料傳送（模擬訊號的傳遞），那我們將其根據單一職責原則重新設計，又這兩種職責的變化不互相影響，則：
單一職責原則的優點：
單一職責不僅適用於介面、類，同時也適用於方法。即乙個方法盡可能的做乙個事情，像下面的這個方法就不可取：
正確做法是
對於單一職責原則，介面一定要做到單一職責，類的設計盡量做到只有乙個原因引起變化。
設計模式六大原則之 單一職責原則
規定乙個類只有乙個發生變化的原因。通俗理解為 乙個類只負責一項職責。類t負責兩個不同的職責，當職責p1改變需求時需要修改t類,這時候就有可能因為修改的邏輯導致職責p2出現故障 遵循單一原則，建立兩個類t1和t2，在修改t1的時候不會影響t2，同理，修改t2的時候也不影響t1的邏輯 類的單一職責比較難...
設計模式六大原則 單一職責
不要存在多餘乙個導致類變更的原因。public class animal public class client 如果這個時候新增魚，因為魚只能呼吸水，所以需要修改animal類 public class animal else public class client 這樣做的話，就違背了設計模式的...
設計模式六大原則 單一職責原則
設計模式六大原則 1 單一職責原則 定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責，乙個人只負責做一件事。乙個類，只有乙個引起它變化的原因。應該只有乙個職責。每乙個職責都是變化的乙個軸線，如果乙個類有乙個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當乙個職責發生...