JavaScript如何深入实践单一职责原则，避免长尾效应的负面影响？

本文共计2252个文字，预计阅读时间需要10分钟。

目录- 单一职责原则- 设计模式中的SRP原则- 何时应该分离职责- 反SRP原则- SRP原则的优缺点- 单一职责原则就是一个类- 应该只有一个引发它变化的原因在JavaScript中，需要用到的类特性

目录

• 单一职责原则
• 设计模式中的SRP原则
• 何时应该分离职责
• 违反 SRP 原则
• SRP 原则的优缺点

单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。在 JavaScript 中，需要用到类的场景并不太多，单一职责原则更多地是被运用在对象或者方法级别上，因此本节我们的讨论大多基于对象和方法。

单一职责原则（SRP）的职责被定义为“引起变化的原因”。如果我们有两个动机去改写一个方法，那么这个方法就具有两个职责。每个职责都是变化的一个轴线，如果一个方法承担了过多的职责，那么在需求的变迁过程中，需要改写这个方法的可能性就越大。

此时，这个方法通常是一个不稳定的方法，修改代码总是一件危险的事情，特别是当两个职责耦合在一起的时候，一个职责发生变化可能会影响到其他职责的实现，造成意想不到的破坏，这种耦合性得到的是低内聚和脆弱的设计。

因此，SRP 原则体现为：一个对象（方法）只做一件事情。

设计模式中的SRP原则

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