SRP:单一职责原则

前端之家收集整理的这篇文章主要介绍了SRP:单一职责原则前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

SRP:单一职责原则

1.定义:一个类应该只有一个发生变化的原因。

2.分析:如果一个累承担了多于一个的职责,那么引起它变化的原因就会有多个,就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的破坏。

3.定义职责:在SRP中,我们把职责定义为变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就有多于一个的职责,应该想办法分离开来。

4.实例:新建一个Rectangle类,该类包含两个方法,一个用于把矩形绘制在屏幕上,一个方法用于计算矩形的面积。如图

Rectangle类违反了SRP原则。Rectangle类具有两个职责,如果其中一个改变,会影响到两个应用程序的变化。

一个好的设计是把两个职责分离出来放在两个不同的类中,这样任何一个变化都不会影响到其他的应用程序。

5.持久化:下图展示了一种常见的违反SRP的清新。Employee类包含了业务规则和对于持久化的控制。业务规则往往会频繁的变化,而持久化的方式却不会频繁变化,并且变哈ude原因也是完全不同,所以把业务规则和持久化子系统放在一起的做法是绝对不应该的。

6.结论:SRP是所有原则中最简单的原则之一,也是最难正确运用的原则之一。我们会不由的把职责以组的方式形成一个类,其实软件设计真正要做的许多工作就是发现职责并把那些职责相互分离。

原文链接:/javaschema/285481.html

猜你在找的设计模式相关文章