您当前位置: 圣才学习网首页 >> IT类 >> .NET程序设计

深度解读单一职责原则

扫码手机阅读
用圣才电子书APP或微信扫一扫,在手机上阅读本文,也可分享给你的朋友。
评论(0
   
来源:网络 作者:未知
 
  单一职责原则(Single Responsibility Principle SRP)是Bob大叔提倡的S.O.L.I.D五大设计原则中的第一个。其中,职责(Responsibility)被表述为“变化的原因”reason to change);SRP被表述为“一个类应该有且只有一个变化的原因”。但如果光从字面去理解, SRP很容易让人望文生义产生误解。本文希望能阐明SRP 的本质,达到避免误解和指导设计的目的。
 
  动机
 
  对于设计原则的理解应该首先从它的动机入手,即遵循这个原则带来的好处是什么?对于 SRP来讲,如果遵循“一个类应该有且只有一个变化的原因”是因,那么“任何一个变化只会影响一个类”就是果。可见SRP的动机主要是系统的可维护性,即降低适应变化的成本。
 
  多功能与单变化
 
  对于单功能的类来讲,比较容易遵循SRP,比如:string转换为DateTime类型的工具类。理解SRP的难点在于在多功能类的情形,即不容易理解多功能与单变化的矛盾。让我们先来看一个Modem类的例子,Modem具有4个功能:拨号,挂断,发送数据,接收数据:
 
  class Modem {
 
  public void Dialstring aPno) {}
 
  public void Hangup() {}
 
  public void Sendchar aData) {}
 
  public char Receive() {}
 
  }
 
  我们先来考察一下Modem类的变化点,并将其分为两类:1.Modem类的内部细节变化,比如 DialHangupSendReceive等具体实现发生了变化;2.Modem类整体性的变化,比如Modem 类需要增加PoweronPoweroff方法。上面的Modem类具有多个变化点,不符合SRP
 
  抽象与抽象层次
 
  但是,需要注意的是上面的Modem类其实是很符合现实的概念模型的,Modem本身就应该具有这几个功能点。难道要把Modem类强行拆开吗,难道所有类都只应该有一个方法吗?是什么原因导致符合现实概念模型的Modem类设计与SRP不符合呢?问题在于抽象与抽象层次,Modem 类是现实概念模型的抽象没有错,但是Modem类缺乏抽象层次,低层概念与高层概念混杂,这正是问题所在。下面是重构以后的Modem:
 
  interface IDialable{
 
  void Dialstring aPno);
 
  }
 
  class Dialer : IDialable{
 
  public void Dialstring aPno{}
 
  }
 
  class Modem{
 
  public void Dialstring aPno) { m_dialer.DialaPno); }
 
  private IDialable m_dialer
 
  … //hangup, send, receive类似
 
  }
 
  上面的设计将各个功能点抽象为单一的接口,将变化封装在稳定的接口背后,再通过组合的方式建立起整体的Modem类与局部的功能点的联系。这样就避免了低层的变化传导到高层。
 
  总结
 
  可见,理解SRP的关键在于理解类的抽象层次,高层次的类是高层概念的抽象,低层次的类是低层概念的抽象。低层的变化只影响低层类,高层的变化只影响高层类。对于遵守SRP设计,一定具有很好的抽象层次,因此不妨以SRP为指导和检验,帮助我们设计出好的类来。最后,我用几个关键词梳理SRP的脉络:
 
  类只有一个变化的原因 >> 一个变化只影响一个类 >> 变化只影响其相应层次的类
 

小编工资已与此挂钩!一一分钱!求打赏↓ ↓ ↓

如果你喜欢本文章,请赐赏:

已赐赏的人
最新评论(共0条)评论一句