設計原則篇之一（單一職責）

 

        所謂設計原則，就是在設計時必須遵守的原則。就個人學習過程來看，主要有SOLID和DRY兩大類。那么首先說下SOLID原則。

   SOLID主要包括五種原則。單詞中每個字母都代表一種原則。這五種原則分別是：

SRP	The Single Responsibility Principle	單一責任原則
OCP	The Open Closed Principle	開放封閉原則
LSP	The Liskov Substitution Principle	里氏替換原則
DIP	The Dependency Inversion Principle	依賴倒置原則
ISP	The Interface Segregation Principle	接口分離原則

單一職責原則（SRP）

     解析：SRP被表述為”一個類應該有且只有一個變化的原因“,單一職責意味着每個類或者方法只做一件事情，該原則也是多數開發人員最容易理解但是也是最容易違反的一個原則。在ASP.NET MVC中，一個很好的例子，就是不同的顯示接口對應不同的控制器。例如，HomeController就只應包含主頁有關的操作，而ProductController應該只處理產品頁面的操作。

多功能與單變化

    對於單功能類來說，比較容易遵循SRP。例如：將繁體中文轉換為簡體中文的工具類。我們來看一個手機(Phone)類的例子，Phone具有2個功能：發短信，打電話。

public class Phone{

    public void Message() {}

public void MakePhone() {…}

}

 

 

我們先來考察一下Phone類的變化點，並將其分為兩類：

1.Phone類的內部細節變化，比如Message和MakePhone方法發生了變化；

2.Phone類整體性的變化，比如Phone類需要增加PlayMovie方法。這個Phone類具有多個變化點，不符合SRP。

進一步抽象

    難道每個類都應該只有一個方法嗎？當然不是。我們可以將每個方法提取到抽象中。下面代碼是將方法提取到抽象中。

  

 public interface IMessage

   {

       void MessageMethod();

   }

   public class Message:IMessage

    {

        public void MessageMethod(){   }

}

 

   public interface IMakePhone

   {

        void MakePhoneMethod();

   }

   public class MakePhone:IMakePhone

    {

        public void MakePhoneMethod()  { }

    }

 

   public class Phone

   {

       private IMessage message;

       public void MessageMethod()

       {

           message.MessageMethod();

       }

       private IMakePhone makePhone;

       public void MakePhoneMethod()

       {

           makePhone.MakePhoneMethod();

       }

   }

 

    上述方法將功能點抽取到單一的接口中，將變化封裝到了穩定的接口背后，這樣就避免了底層的變化傳導到高層。如果想更好的運用單一職責原則，就必須理解好C#編程中的抽象。

     當下，正是單一職責盛行的時代，每個人都專精於某一個模塊，需要多人協同合作，才能組成絢麗多彩的世界。代碼寫到一定程序，慢慢的我們就需要考慮一些設計原則，當然原則是以實際應用為基礎的。