C#軟體設計——小話設計模式原則之：單一職責原則SRP

前言：上篇C#軟體設計——小話設計模式原則之：依賴倒置原則DIP簡單介紹了下依賴倒置的由來以及使用，中間插了兩篇WebApi的文章，這篇還是回歸正題，繼續來寫寫設計模式另一個重要的原則：單一職責原則。

軟體設計原則系列文章索引

C#軟體設計——小話設計模式原則之：依賴倒置原則DIP

C#軟體設計——小話設計模式原則之：單一職責原則SRP

C#軟體設計——小話設計模式原則之：接口隔離原則ISP

C#軟體設計——小話設計模式原則之：開閉原則OCP

單一職責原則，英文縮寫SRP，全稱Single Responsibility Principle。

原始定義：There should never be more than one reason for a class to change。

官方翻譯：應該有且僅有一個原因引起類的變更。簡單點說，一個類，最好隻負責一件事，隻有一個引起它變化的原因。

上面的定義不難了解，引起類變化的原因不能多于一個。也就是說每一個類隻負責自己的事情，此所謂單一職責。

我們知道，在OOP裡面，高内聚、低耦合是軟體設計追求的目标，而單一職責原則可以看做是高内聚、低耦合的引申，将職責定義為引起變化的原因，以提高内聚性，以此來減少引起變化的原因。職責過多，可能引起變化的原因就越多，這将是導緻職責依賴，互相之間就産生影響，進而極大的損傷其内聚性和耦合度。單一職責通常意味着單一的功能，是以不要為類實作過多的功能點，以保證明體隻有一個引起它變化的原因。

不管是從官方定義，還是對“單一職責”名稱的解釋，都能很好的了解單一職責原則的意義。其實在軟體設計中，要真正用好單一職責原則并不簡單，因為遵循這一原則最關鍵的地方在于職責的劃分，部落客的了解是職責的劃分是根據需求定的，同一個類（接口）的設計，在不同的需求裡面，可能職責的劃分并不一樣，為什麼這麼說呢？我們來看下面的例子。

關于單一職責原則的原理，我們就不做過多的解釋了。重點是職責的劃分！重點是職責的劃分！重點是職責的劃分！重要的事情說三遍。下面根據一個示例場景來看看如何劃分職責。

假定現在有如下場景：國際手機營運商那裡定義了生産手機必須要實作的接口，接口裡面定義了一些手機的屬性和行為，手機生産商如果要生成手機，必須要實作這些接口。

我們首先以手機作為單一職責去設計接口，方案如下。

然後我們的手機生産商去實作這些接口

這種設計有沒有問題呢？這是一個很有争議的話題。單一職責原則要求一個接口或類隻有一個原因引起變化，也就是一個接口或類隻有一個職責，它就負責一件事情，原則上來說，我們以手機作為單一職責去設計，也是有一定的道理的，因為我們接口裡面都是定義的手機相關屬性和行為，引起接口變化的原因隻可能是手機的屬性或者行為發生變化，從這方面考慮，這種設計是有它的合理性的，如果你能保證需求不會變化或者變化的可能性比較小，那麼這種設計就是合理的。但實際情況我們知道，現代科技日新月異，科技的進步促使着人們不斷在手機原有基礎上增加新的屬性和功能。比如有一天，我們給手機增加了攝像頭，那麼需要新增一個像素的屬性，我們的接口和實作就得改吧，又有一天，我們增加移動辦公的功能，那麼我們的接口實作是不是也得改。由于上面的設計沒有細化到一定的粒度，導緻任何一個細小的改動都會引起從上到下的變化，有一種“牽一發而動全身”的感覺。是以需要細化粒度，下面來看看我們如何變更設計。

 我們将接口細化

實作類

對于上面題的問題，這種設計能夠比較友善的解決，如果是增加屬性，隻需要修改IMobilePhoneProperty和MobileProperty即可；如果是增加功能，隻需要修改IMobilePhoneFunction和MobileFunction即可。貌似完勝第一種解決方案。那麼是否這種解決方案就完美了呢？答案還是看情況。原則上，我們将手機的屬性和功能分開了，使得職責更加明确，所有的屬性都由IMobilePhoneProperty接口負責，所有的功能都由IMobilePhoneFunction接口負責，如果是需求的粒度僅僅到了屬性和功能這一級，這種設計确實是比較好的。反之，如果粒度再細小一些呢，那我們這種職責劃分是否完美呢？比如我們普通的老人機隻需要一些最基礎的功能，比如它隻需要充電、打電話、接電話的功能，但是按照上面的設計，它也要實作IMobilePhoneFunction接口，某一天，我們增加了一個新的功能玩遊戲，那麼我們就需要在接口上面增加一個方法PlayGame()。可是我們老人機根本用不着實作這個功能，可是由于它實作了該接口，它的内部實作也得重新去寫。從這點來說，以上的設計還是存在它的問題。那麼，我們如何繼續細化接口粒度呢？

 接口細化粒度設計如下

實作類和上面類似

此種設計能解決上述問題，細分到此粒度，這種方案基本算比較完善了。能不能算完美？這個得另說。接口的粒度要設計到哪一步，取決于需求的變更程度，或者說取決于需求的複雜度。

以上通過一個應用場景簡單介紹了下單一職責原則的使用，上面三種設計，沒有最合理，隻有最合适。了解單一職責原則，最重要的就是了解職責的劃分，職責劃分的粒度取決于需求的粒度，最後又回到了那句話：沒有最好的設計，隻有最适合的設計。歡迎園友拍磚斧正。如果園友們覺得本文對你有幫助，請幫忙推薦，部落客将繼續努力~~