于SRP中我们管任务定义也扭转之因。那么引起她生成的故纵然会出差不多只。

第8章节 SRP:单一任务规范

一、定义

  一个类应该只有来一个发生变化的缘由。

  一个看似应该一味发一个发生变化的来由。

第二、为什么而利用SRC

  因为各个一个职责都是变之一个轴线。当需要变化时,这种转变就会见反映为类的天职的变化。如果一个近似承担了多于一个的天职,那么引起她生成之缘由就会生多单。

  如果一个像样承担的天职过多,就相当于将这些职责耦合在了共。一个任务的转也许会见消弱或抑制这个仿佛就其他任务的力量。这种耦合会导致脆弱的宏图,当变化发生时,设计会受到意外的破坏。

8.1 定义职责

其三、案例演示

  考虑图中的统筹。

  图片 1

  Rectangle类具有两单办法,一个措施将矩形绘制到屏幕上,另一个方式则是计量矩形的面积。
现在来星星点点只应用程序使用Rectangle类。一个是使Rectangle计算矩形面积,但切莫需要绘制矩形;另一个应用程序可能会见绘制矩形,也恐怕计算面积。

  这个规划违反了纯任务规范。Rectangle类具有两个任务。第一单任务提供了矩形面积之盘算;第二只任务提供了矩形绘制。
对于SRC的背导致了一些严重的问题。

  对于这个违了SRC的程序来以下几点问题:

  首先,我们得于左手的先后中富含进GUI代码,即使我们是不需要的。

  其次,如果右侧程序的变更导致了Rectangle的更动,那么这改变会迫使我们重构建、测试和部署左侧的次序。

  
一个较好之设计虽是拿及时有限单任务分开到如下图所展示之片独意不同的接近中。这个企划将Rectangle类中开展计算的有更换到了GeometricRectangle类中。现在矩形绘制方法的变通不会见潜移默化至左手的主次。

  图片 2

  以SRP中我们把任务定义为转变之由来。如果您想到多于一个的心劲去改变一个近似,那么这近乎就所有多于一个底职责。同时,我们老不便顾到及时或多或少。我们习惯吃坐组的花样去考虑职责。违反SRP的言传身教代码:

季、什么是任务

  于SRC中,我们将任务定义也转变的由

  如果您能够想到多于一个之念头去改变一个看似,那么这个类似就有着多于一个之任务。

  有时,我们非常为难顾到当时一点,我们习惯于以组的款型去考虑职责。
例如,下面的Modem接口,大多数口看是接口非常合理。该接口所声明的4独主意确实是调制解调器所具备的意义

public interface Modem
{ 
    public void Dial(string pno); //连接 
    public void Hangup(); //断开 
    public void Send(char c); //发送
    public char Recv(); //接收 
} 

  然而,该接口中倒是形出点儿个任务。第一单任务是连接管理;第二只任务是数码通信。

  这简单个任务需要分开吗?

  这仗让应用程序变化的法。如果应用程序的扭转会影响至连管理章程的签约,那么这个计划虽有僵化性,因为调用send和recv的接近必须另行编译、部署。在这种情况下,这片单任务应该叫分手,如下图所著。

  图片 3

 

  另一方面,如果应用程序的浮动法连接造成这有限独任务同时转,那就不要分离它们。

  记住这么一个定论,独当变化来时,变化之轴线才享有实际意义。如果无征兆,那么下SRP或者其他其他原则都是不明智之。

public interface Modem
{
    public void Dial(string pno);
    public void Hangup();
    public void Send(char c);
    public char Recv();
}

五、分离耦合的职责

  请小心,在达到图备受,把有限个任务都耦合进了ModemImplementation类中。这或者不是最好好之,但是也许要得如此做。常常会发出局部以及硬件还是操作系统的底细有关的缘由,迫使我们管非甘于耦合在一起的东西耦合在了共同。然而,对于下之其余部分来说,通过分离它们的接口我们早就解耦了。

 

六、持久化

  下图显示了一致栽常见的违SRP的情。

  图片 4

  Employee类包含了事情规则及对此持久化的支配。这个片单任务在大部分情形下毫不应该混合在一起。业务规则往往会频地转移,而持久化的主意可不会见如此反复之转变,并且转变的因吧是全两样的,它们其实点儿单样子上转移,一个凡是工作方向及转,另一个是持久化方向达成生成。

  把工作规则与持久化子系统绑定以一道的做法是自讨苦吃。
测试驱动之开实践时会处在设计出现臭味之前就是强迫我们分别就片只任务。然而,如果测试没有强迫这种分离,那么就应以Facade(外观)、DAO(数据看)或者Proxy(代理)模式对统筹进行重构,分离就有限单任务。

  大多数人数会面认为是接口看起十分合理。该接口所声明的4只函数确实是调制解调器所负有的效应。

七、结论

  SRP是有着条件被尽简便易行的尺度之一,也是无与伦比麻烦对用的基准之一。我们会不自觉地管任务整合及齐。软件设计真正使举行的大队人马干活,就是意识职责并将那些职责相互分开。

 

  然而接口中倒是亮有些许独任务。第一个任务是链接管理;第二只任务是数据通信。dial和hangup函数进行调制解调器的连续处理,而send和recv函数进行数据通信。

  这片只任务应该分别吗?这仗让应用程序变化之点子。如果应用程序的别会影响连函数的签约(signature),那么这个设计虽有所僵化性的臭气,因为调用send和recv的接近必须要双重编译、部署之次数常常会超越我们期望之次数。在这种状态下,这有限单任务应该于分开。这样做避免了客户应用程序和这半个任务耦合在一起。

图片 5

 

  另一方面,如果应用程序的转移方法连接造成这半单任务同时转,那么就是不必分离它们。实际上,分离它们就会生出免必要的复杂的臭。

  在此还有一个想。仅当变化有常,变化之轴线才有实际意义。如果没有前兆,那么下SRP或者其他其他条件都是未明智的。

8.2 分离耦合的职责

  上图中,我将个别只任务都耦合进了ModemImplementation类中。这不是所期的,但是也许是必不可少的。常常会生一些跟硬件还是操作系统的底细有关的原由,迫使我们管未乐意耦合在一起的东西耦合在一起。然而,应用的其余部分来说,通过分离它们的接口我们都解耦了定义。

  我们好管ModemImplementation类看作是一个杂凑物,或者发弱点的切近。然而,请小心有所的因关系还是起其来之。谁啊未待借助让它。除了main外,谁也非需了解其的存在。因此,我们已拿丑陋的局部隐藏起来了。其丑陋性不会见泄露出来,污染使之其它组成部分。

8.3 持久化

图片 6  

  上图展示了一样种普遍的背SRP的动静。Employee类包含了事情规则与对此持久化的操纵。这半单任务在大部分动静下毫不应该混合在一起。业务规则往往会频地别,而持久化的道却不会见这么反复地变化,并且转变的因吧是一心两样的。把工作规则及持久化自系统绑定以联名的做法是自讨苦吃。

  幸运的凡,测试驱动之开实践时会处于设计出现臭味之前即强逼我们分开就简单独任务。然而,如果测试没有强迫这种分离,而僵化性和脆弱性的臭又蛮显著,那么即使应有下FACADE(外观)、DAO(数据看对象)或者PROXY(代理)模式对计划进行重构,分离就半只任务。

8.4 结论

   SRP是拥有规则被最好简便易行的尺码之一,也是极度难对用的规格有。我们会当地将任务结合在一起。软件设计真正使做的无数工作,就是发现职责并把那些职责相互分开。事实上,我们且论述的任何原则都见面因为这样或那样的法子赶回这问题上。

 

 

挑自:《敏捷软件开发:原则、模式和履行(C#版)》Robert C.Martin    Micah
Martin 著

转载请注明出处:

作者:JesseLZJ
出处:http://jesselzj.cnblogs.com

 

相关文章