SOLID五大原则（一）单一职责SRP

前言

为了使我们的代码更加的规范和易读，面向对象编程的时候我们最好应该严格地遵守五大原则进行开发，最初也许编码会稍显复杂，但当代码的迭代和维护量大起来之后，就会发现这些严格的规范都是值得的。

国际惯例，先吹牛逼
原始定义：There should never be more than one reason for a class to change。
官方翻译：应该有且仅有一个原因引起类的变更。简单点说，一个类，最好只负责一件事，只有一个引起它变化的原因。
我把单一职责放在第一个说，是因为这个原则使我们最最常接触到的也是最简单的一个原则。

看下面这个简单的例子：
我们最开始有一个业务，用户注册，并返回注册结果
业务调用（伪代码）

public void DemoMain()
{
    //注册用户
    bool isSuccess=RegisterUser();
}

        /// <summary>
        /// 注册方法，并返回注册结果
        /// </summary>
        /// <returns></returns>
        private bool RegisterUser()
        {
            //dosth
            //code
            return true;
        }

一段简单的执行注册业务的方法，然后后期业务发生变动，领导说了：我们在注册成功之后呢，要已短信的形式通知用户
好，说干就干

        /// <summary>
        /// 注册方法，并返回注册结果
        /// </summary>
        /// <returns></returns>
        private bool RegisterUser()
        {
            bool isSuccess = service.RegisterUser();
            if (isSuccess)
            {
                service.SendMessage("恭喜你，注册成功！获得1000000元现金奖励。");
            }
            return isSuccess;
        }

简简单单，业务满足了，确实实现了业务，但很遗憾，这段代码并不规范，因为它没有严格遵守单一职责
显而易见，在我们的设计之初，这个类只有一个职责那就是注册，但经过业务的变化之后，它有了第二个职责，这就违背了单一职责，该怎么做呢？
很简单，我们的注册类不做任何的修改，新添加一个短信服务类，并添加发送短信的方法，在调用处修改为：

public void DemoMain()
{
  //注册用户
  bool isSuccess=RegisterUser();
  if (isSuccess)
  {
      serviceSend.SendMessage("恭喜你，注册成功！获得1000000元现金奖励。");
  }
}

这样，我们的注册类仍然是干净的，我们只是在应用层对具体的方法进行重新编排，多调用了一个发送短信的方法，既满足了业务，也遵守了单一职责

思考？既然结果都一样，为什么非要遵循这个单一职责呢？

如果我们将发送短信的方法放在注册类里之后，如果后边继续加业务：在注册成功之后，要给该会员自动赠送一张礼券，业务只会越叠越多，到那个时候，你这个注册类，已经乱七八糟了，甚至连名都不知道该怎么起。
而我们如果是严格遵守单一职责，那么代码的变动，只会是这样：

public void DemoMain()
{
  //注册用户
  bool isSuccess=RegisterUser();
  if (isSuccess)
  {
      service.SendMessage("恭喜你，注册成功！获得1000000元现金奖励。");
      service.Dosth1();
      service.Dosth2();
  }
}

井井有条，只是在我们的应用层，对每一个具体的实现进行编排，每个类仍然可以一眼就确定是干了哪些事，这就是单一职责的目的。

---

本来是想一篇文章写完五大原则的，但感觉篇幅会很长，还是分为五篇分别写吧，加深印象。