Aelous-Blog

养一猫一狗,猫叫夜宵,狗叫宵夜

0%

JS设计模式-单一职责原则

单一职责原则(SRP)

就一个类而言,应该仅有一个引起它变化的原因。

单一职责原则的职责被定义为“引起变化的原因”。如果我们有两个动机去改写一个方法,那么这个方法就有了两个职责。每一个职责都是变化的一个轴线,如果一个方法承担了过多的职责,那么在需求的变迁过程中,需要改写这个方法的可能性就越大。特别是当两个职责耦合在一起的时候,一个职责发生变化可能会影响到其他职责的实现,造成意想不到的破坏。这种耦合性得到的是低内聚和脆弱的设计。

因此 SRP 原则体现为:一个对象(方法)只做一件事情。

设计模式中的 SRP 原则

SRP 原则在很多设计模式中都有着广泛的运用,例如代理模式、迭代器模式、单例模式和装饰者模式。

其中每个方法都应该只对应着一个职责。

何时应该分离职责

SRP 原则是所有原则中最简单也是最难正确运用的原则之一。

要明确的是,并不是所有的职责都应该一一分离。

一方面,如果随着需求的变化,有两个职责总是同时变化,那么就不必分离他们。比如在 ajax 请求的时候,创建 xhr 对象和发送 xhr 请求几乎总是在一起,那么创建 xhr 对象的职责和发送 xhr 请求的职责就没必要分开。

另一方面,职责的变化轴线仅当它们确定会发生变化时才有意义,即使两个职责已经被耦合在一起,但它们还没有发生改变的征兆,那么也许没有必要主动分离它们,在代码需要重构的时候再分离也不迟。

违反 SRP 原则

在人的常规思维中,总是习惯性地把一组相关的行为放到一起,如何正确地分离职责不是一件容易的事情。

一方面,我们受设计原则的指导,另一方面,我们未必要在任何时候都一成不变的遵守原则。在实际开发中,因为种种原因违反 SRP 的情况并不少见。比如 jQuery 的 attr 等方法,就是明显违反 SRP 原则的做法。jQuery 的 attr 是一个非常庞大的方法,既负责赋值,又负责取值,这对于 jQuery 的维护者来说,会带来一些困难,但对于 jQuery 的用户来说,却简化了用户的使用。

在方便性和稳定性之间要有一些取舍。具体是选择方便性还是稳定性,没有标准答案,而是要取决于具体的应用环境。

SRP 原则的优缺点

SRP 原则的优点是见底了单个类或者对象的复杂度,按照职责把对象分解成更小的粒度,这有助于代码的复用,也有利于进行单元测试。当一个职责需要变更的时候,不会影响到其他的职责。

但 SRP 原则也有一些缺点,最明显的是会增加编写代码的复杂度。当我们按照职责把对象分解成更小的粒度之后,实际上也增大了这些对象之间相互联系的难度。

End~~ 撒花= ̄ω ̄=花撒
如果您读文章后有收获,可以打赏我喝咖啡哦~