設計模式的六大原則（1）單一職責原則。

設計模式的六大原則（1）單一職責原則？

定義：不要存在多於乙個導致列變更的原因。通俗的說就是，即乙個類只負責一項原則

問題由來：類t負責兩個不同色職責：職責p1、職責p2.當由於職責p1需求發生改變而需要修改類t時。有可能會導致原本執行正常的職責p2功能發生故障

解決方案：遵循 單一職責原則，分別建立兩個類t1、t2，使t1完成職責p1功能，t2完成職責p2功能 。這樣，當修改類t2時，也不會使職責p1發生故障風險。

說到單一職責時，很多人都會不屑一顧，因為它實在是太簡單了，稍有經驗的程式設計師即使從來沒有讀過設計模式、從來沒有聽說過單一職責原則。在設計軟體時都會自覺的遵循這一重要原則，因為這是常識 。在軟體程式設計中，誰也不希望修改這個功能導致其他功能發生故障。而避免這一問題的方法便是遵循單一職責原則。雖然單一職責原則 如此簡單，並且被認為是常識，但是即使經驗再豐富的程式設計師寫出的程式，也會會違背這一原則的**存在。為什麼會出現這種 現象呢？因為也有職責擴散，就是因為某種原因，職責p被分化為粒度更細的職責p1和p2.

比如：t類只負責乙個職責p，這壓根設計是符合單一職責原則的。後來由於某種原因，也是需求變更了，也許是程式的設計者境界提高了。需要將職責p細分為麗都更細的職責p1、p2，這時如果要使程式遵循單一職責 原則，需要將類t也分解為兩個類t1和t2，分別負責p1和 p2兩個職責。但是在程式已經寫好的情況下，這樣做簡直太浪費時間了。所以，簡單的修改類t，用它來負責兩個職責是乙個筆記愛不錯的選擇，雖然這樣 做有浡於單一職責原則。（這樣做的風險在於職責擴充套件的不確定性，因為日我們不會想到這個職責p，在將來可能會擴散到 p1、p2、p3、p4……pn。所以記住，在職責擴散到我們無法控制的程式之前，立刻對**進行重構）

舉例說明，用乙個雷描述動物呼吸場景

class animal

}public class cilent
｝class aqutic
}public class cilentelse}}
public class cilent
}

這種修改方式直接在**上違背了單一職責原則，雖然修改起來最簡單，但隱患卻是最大的。

還有一種修改方式，**如下：

class animal

public void breathe2(string animal)
}public class cilent
}

例如本文舉得這個例子，它太簡單了，它只有乙個方法，所以，無論在**級別上違反，都不會造成太大的影響。實際應用的類要複雜的多，一旦發生職責擴散而需要修改類時，除非這個類本身非常簡單，否則還是遵循單一職責原則的好。

遵循單一職責的優點：

可以降低類的複雜難度，乙個類只負責一項職責，其邏輯肯定要比負責多職責簡單的多；
提高類的可讀性，提高系統的課維護性，變更的風險降低，變更是必然的，如果單一職責遵守的好，當修改乙個功能時，可以顯著降低對其他功能的影響
需要說明的一點是單一職責 原則不只是物件導向程式設計思想所特有的，只是要模組化的程式設計，都適於單一職責原則。

設計模式六大原則（1） 單一職責

只能有乙個職責，例如學生類，他的職責就是學習，他不能越職做不是學生做的事情 主要約束類，其次才是介面和方法，主要針對的是程式中的實現和細節 只能有乙個職責，例如睡覺方法，它的職責就是睡覺，不能同時又包含運動 1 降低類的複雜度，乙個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多 2 提高類的可...

設計模式六大原則（1） 單一職責原則

定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...

設計模式六大原則（1） 單一職責原則

定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...