设计原则（1/6）：单一职责原则

单一职责原则：

(Single Responsibility Principle, SRP)

---

应该有且仅有一个原因引起类的变更：

意思就是不管干啥，我都只干一件事，你叫我去买菜，我就只买菜，叫我顺便去倒垃圾就不干了

---

应用范围：

单一职责原则适用的范围有接口、方法、类。按大家的说法，接口和方法必须保证单一职责，类就不必保证，只要符合业务就行。

---

假设我们要做一个用户修改名字以及修改密码的功能，可以有多种实现方案，比如下面列举 2 种实现方式：

错误的示范:

public enum Operation
{
   [Description("修改昵称")]
    UpdateUserName,
   [Description("修改密码")]
    UpdatePassword
}
public interface IUserOperation
{
    void UpdateUserInfo(User user, Operation type);
}
public class UserOperation : IUserOperation
{
    public void UpdateUserInfo(User user, Operation type)
    {
         if (type == Operation.UpdateUserName)
         {
              // 执行修改昵称的操作
         }
         else if (type == Operation.UpdatePassword)
         {
              // 执行修改密码的操作
         }
    }
}

第一种实现通过 Operation 类型的不同来做不同的事情，把修改密码和修改名字耦合在一起，容易引起问题，只要稍不注意，传错枚举值就悲剧了，在代码中也没法很直接看到是做什么操作，也就是这个方法的职责不明确。

---

所以我们使用第二种方式来实现：

正确的示范：

public interface IUserOperation
{
    void UpdateUserName(User user);
    void UpdatePassword(User user, string password);
}

public class UserOperation : IUserOperation
{
    public void UpdateUserName(User user)
    {
        // 实现修改昵称的操作
    }

    public void UpdatePassword(User user, string password)
    {
       // 实现修改密码的操作
    }
}

第二种实现，把修改密码和修改名字分离开来，也就是把修改密码和修改名字都当做独自的职责处理，这样子就很清晰明了，你调用哪个方法，就很明确的知道这个方法是实现什么逻辑。结论是啥呢？用第二种方式实习才符合单一职责原则。现实中看到很多像第一种实现的代码，而且是枚举有十来个的情况，看代码真费劲。

---

再设想一下这个场景，假设我们让小明去倒垃圾，小红去买菜，小红回来后再叫小红去洗碗。下面也举 2 个实现的例子：

错误的示范:

public class Xiaoming : IHousework
{
    public void Shopping()
    {
        // 小明不购物, 所以不实现
        throw new NotImplementedException();
    }

    public void PourGarbage()
    {
        Console.WriteLine("小明只倒垃圾");
    }
}
public class Xiaohong : IHousework
{
    public void Shopping()
    {
        Console.WriteLine("小红只购物");
    }

    public void PourGarbage()
    {
        // 小红不倒垃圾, 所以不实现
        throw new NotImplementedException();
    }
}

中途回来小红去洗碗，要怎么实现？按这个写法，就在 Housework 接口添加 washingUp() 方法，然后小明和小红依次都实现洗碗这个方法，只是小明不做具体实现代码，这样子是不是觉得很别扭，不符合单一职责原则的，修改一个地方，不影响其他不需要改变的地方，只对需要用到的地方做修改。小明本来就不用洗碗，却要去实现洗碗这个方法。

---

所以我们使用第二种方式来实现：

正确的示范：

public interface IShopping
{
    void DoShopping();
}

public interface IPourGarbage
{
    void DoPourGarbage();
}

public interface IWashingUp
{
    void DoWashingUp();
}

public class Xiaoming : IPourGarbage
{
    public void DoPourGarbage()
    {
        Console.WriteLine("只实现倒垃圾的行为，因为小明只负责倒垃圾");
    }
}
public class Xiaohong : IShopping, IWashingUp
{
    public void DoShopping()
    {
        Console.WriteLine("实现购物的行为，因为小红只负责购物");
    }

    public void DoWashingUp()
    {
        Console.WriteLine("实现洗碗的行为，因为小红也要负责洗碗");
    }
}

可以看到，这种实现把不同的家务都当做不同的职责，分离开来，这种实现可以按需实现做家务的类型，小明只需要去倒垃圾，就实现 PourGarbage 接口，小红去购物和洗碗，就实现 Shopping 和 WashingUp 接口，完全不会影响到对方，这才是完美的根据单一职责原则编写出来的代码。

---

类

但是对于实现类就需要多方面考虑了，生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦；而且过分的细分类的职责也为人为的制造系统的复杂性，本来一个类可以实现的行为非要拆成两个，然后使用聚合或组合的方式再耦合在一起，这个是人为制造了系统的复杂性

类这个看了一些资料都说没法硬性要求一定按单一职责原则分，或者说类的职责可大可小，没有很明确的像上面接口那样按照单一职责原则分就很清晰也很有道理。 设想一下这个场景：我们要实现一个用户注册、登录、注销操作，可以像如下 2 种实现方式：

第一种实现方式：

从用户的角度考虑，这些操作都是用户的行为，可以放在一个统一的类 UserBiz：

public class UserBiz
{
    public void Register(User user)
    {
        // 注册操作
    }
    public void Login(User user)
    {
        // 登录操作
    }
    public void Logout(User user)
    {
        // 注销操作
    }
}

第二种实现方式：

有人又说，不是说单一职责么？从业务操作考虑，需要把注册、登录、注销分开：

public class UserRegisterBiz
{
    public void Register()
    {
        // 注册操作
    }
}

public class UserLoginBiz
{
    public void Login()
    {
        // 登录操作
    }
}

public class UserLogoutBiz
{
    public void Logout()
    {
        // 注销操作
    }
}

感觉像是在抬杠，其实这个没有好坏之分，根据具体业务具体分析，你说你的登录、注册、注销操作代码很多，需要分开，那就分开，无可厚非。

---

通过上面的例子，我们来总结一下单一职责原则有什么好处：

    ● 类的复杂性降低，实现什么职责都有清晰明确的定义；

    ● 可读性提高，复杂性降低，那当然可读性提高了；

    ● 可维护性提高，可读性提高，那当然更容易维护了；

    ● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修

改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大
的帮助。

---

总结：

这个单一职责原则，目的就是提高代码的可维护性、可读性、扩展性，如果为了单一职责而破坏了这 3 个特性，可能会得不偿失。

参考与致谢：http://www.liebrother.com/single-responsibility-principle