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

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/u013276277/article/details/90706162

单一职责原则(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)变更引起的风险降低,如果接口的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,这对系统的扩展性,维护性都有非常大的帮助。  

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

 

    

展开阅读全文

没有更多推荐了,返回首页