設計模式6大原則之-單一職責原則

單一職責原則

例1：

大家應該能看出來這個類圖中的介面設計是有問題的，使用者的屬性和使用者的行為沒有分開。我們根據使用者的屬性和行為拆開這個介面。

重新拆分成兩個介面，IUserBo 負責使用者的屬性，IUserBiz負責使用者的行為。當我們執行個體化除UserINfo這個對象後，我們可以把UserInfo當做IUserBo實作類別使用也可以將它當做IUserBiz的實作類別使用，這就要看我們用在什麼地方了。如果是擷取使用者資訊，就把UserInfo 當做IUserBOSS的實作類別，如果是維護使用者資訊，就當做是IUserBiz的實作類別。在實際應用中我們更傾向於把一個介面拆分成兩個，一個是IUserBO一個是IUserBIz。類圖如下。

這樣做以後，我們就把一個介面拆成了兩個，這樣就符合了單一職責原則，那麼什麼是單一職責原則呢？

單一職責原則，核心思想是：一個類，最好只做一件事，只有一個引起它變化的原因。

單一職責原則可以看作是低耦合、高內聚在物件導向原則上的引申，將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。職責過多，可能引起變化的原因就越多，這將是導致職責依賴，相互之間就產生影響，從而極大的損傷其內聚性和耦合度。單一職責通常意味著單一的功能，因此不要為類實現過多的功能點，以保證實體只有一個引起它變化的原因。 例2：

Rectangle擁有兩個方法，一個方法是draw,用來畫圖形，另一個方法是area用來計算面積。Rectangle違背了單一職責原則，因為它具有兩個職責：計算面積與繪製矩形。繪製圖形會與使用者介面有關，但是計算圖形面積卻未必與介面有關，如果把這兩個職責寫到一個類中，那麼如果只需要使用area（）方法這一職責來計算面積，那就不得不把draw()方法一同編譯，但是卻可能也用不到它。如果其中一個職責需要修改，就不得不重新編譯和部署另外一個。如果類的職責超過一個，這些職責之間就會產生耦合。改變一個職責，可能會影響和妨礙類為其它類服務的功能。把兩個職責分開會好一些。

兩個職責分離，這樣耦合度就會降低。SRP原則的核心就是要求對類的改變只能是一個，對於違反這一原則的類應該進行重構，例如以Façade模式或Proxy模式分離職責，通過基本的方法Extract
Interface、Extract Class和Extract Method進行梳理。

例3：看一下下面的介面

    public interface Phone    {        //撥通電話        public void dial(string phoneNumber);        //通話        public void chat(object o);        //回應        public void answer(object o);        //通話完畢        public void huangup();    }

這個介面有問題嗎？還真有問題。單一職責要求一個介面或者類只有一個原因引起變化，也就是一個介面或者類只有一個職責，它負責一件事情。Phone這個介面不是一個職責，它是有兩個職責：一個是協議管理，一個是資料轉送。diag()和huangup()這兩個方法實現的是協議管理，撥號和掛斷。chat()和answer()是資料轉送。協議改變和資料轉送都會引起類的變化，那麼我們就不能說它是符合單一職責原則。由於這兩個職責變化不互相影響，那麼就考慮拆成兩個介面。
這個類圖已經符合單一職責原則，但是卻複雜多了，組合是一種強耦合關係，兩者都有共同的生命期，這種強耦合增加了類的複雜性，我們修改一下。

這樣設計才完美，一個手機實現兩個介面，把兩個職責融合一個類中，雖然你會覺得這個phone類有兩個原因引起變化，但是我們是面向介面編程，對外公布的是介面，而不是實作類別。如果非要使得類符合單一職責原則，那麼就要使用上一個類圖了，但是這樣的話類的耦合性就增加了。

單一職責原則的好處：

類的複雜性降低可讀性提高可維護性提高變更引起的風險降低