設計模式原則 單一職責原則（二）

單一職責原則解釋：就乙個類而言，應該只有乙個引起它變化的原因.我們有時候在做程式設計的時候，很自然而然的會給乙個類增加這樣那樣的功能，比如：我們要做乙個**，會給這樣乙個default.aspx.cs後台檔案加入演算法的**，資料庫訪問的sql語句，業務邏輯的**等等都寫到這個類檔案中，這就意味著，無論任何需求要來，你都需要去動這個類檔案，這其實是很糟糕的，維護麻煩，復用根本不可能，更別提靈活性了，假如你又要做乙個類似的應用程式，不過它執行的平台是手機，web介面的程式不能使用，那之前的這個web應用程式如何移植到手機上以達到復用的效果

.所以至少至少我們可以將程式分為兩個類，乙個是業務邏輯類，乙個是介面ui類，當有一天要改變介面的時候，不過是介面表現類的變化而已，和業務邏輯類無關，以此達到復用的目的

.如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化會限制這個類完成其他職責的能力，這是種脆弱的設計，當需求發生變化時，這種設計就崩潰了

.其實我們以前經常做的三層架構就體現了單一職責原則，業務邏輯層處理業務邏輯，資料訪問層訪問資料庫，表現層處理介面

設計模式原則 單一職責原則（二）

單一職責原則解釋 就乙個類而言，應該只有乙個引起它變化的原因 我們有時候在做程式設計的時候，很自然而然的會給乙個類增加這樣那樣的功能，比如 我們要做乙個 會給這樣乙個default.aspx.cs後台檔案加入演算法的 資料庫訪問的sql語句，業務邏輯的 等等都寫到這個類檔案中，這就意味著，無論任何需...

設計模式原則 單一職責原則

定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...

設計模式原則 單一職責原則

對類來說的，即乙個類應該只負責一項職責。假如類a負責多項職責，當其中一項職責需求發生變更時，可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責，那麼當我們需要修改 使用者資料持久化 需求時，由於 糅雜在乙個類裡，可能會對 訂單資料持久化 的職責造成影響...