设计原则篇之一（单一职责）

 

        所谓设计原则，就是在设计时必须遵守的原则。就个人学习过程来看，主要有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#编程中的抽象。

     当下，正是单一职责盛行的时代，每个人都专精于某一个模块，需要多人协同合作，才能组成绚丽多彩的世界。代码写到一定程序，慢慢的我们就需要考虑一些设计原则，当然原则是以实际应用为基础的。