6大设计原则之单一职责原则

单一职责原则（Single Responsibility Principle, SRP）

     当你跟同事争论的时候冒出一句，你这个设计不符合SRP原则时，那是多么的装比，说不定被你的气势直接压住了，哈哈，开个玩笑，实力才是说话权。

     单一职责的定义：应该有且仅有一个原因引起类的变更。原话是： There should never be more than one reason for a class to change.。简单的像句废话，但是确实很难做到。举个例子：打电话，电话通话过程有四个：拨号，通话，回应，挂机，那我们写个接口，go语言如下：

type IPhone interface{
  dial(phoneNumber string)
  chat(p person)
  hangup()
}

      实现类你们就自己写吧，这个接口大家看着有没有问题，可能大家觉得没啥问题，当然我可能有时候也会觉得OK。单一职责原则要求一个接口或类只有一个原因引起变化，，也就是说一个接口或者类只需要一个职责，他就负责一件事情，这时候你看看上面接口是否做到了，好像不是吧。

     电话这个接口可不止一个职责，她包含两个职责：协议管理和数据传送，dial()和hangup()两个方法是协议管理，chat()是数据传送，然后我们想想协议变化会影响类的变化吗？会的，所以我们应该把这两个职责分别写两个接口，这样他们就不互相影响了。其实，对于协议管理和数据传输两个职责，你还可以往下细分，这样每个小工能都会有一个接口，但是，并不建议这么做，因为这会带来设计的复杂性。所以在使用单一职责原则时应该把我一个度。这个主要看工程人员的把控，比不一定完全做到，但你得有这个意识。

     单一职责的好处：
 （1）类的复杂性降低，实现什么职责都有清晰明确的定义

 （2）可读性提高，复杂性降低了

 （3）可维护性高，可读性高了，自然可维护性就高了

 （4）变更引起的风险降低，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性，维护性都有非常大的帮助。  

    其实单一职责原则最难分的就是职责，所以建议接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。这可能会带来一定的工作量，但是是值得的。当然，工程师在平时设计中，可能会考虑到工作量的问题，难免会有妥协，但是为了以后的便利，还是值得的。