最少承诺原则和单一职责原则

介绍

在这篇文章中，我想介绍单一责任原则（ SRP ）。
我认为这是任何干净且设计良好的系统的基础。

什么是SRP？

该术语由Robert C. Martin提出 。 它是SOLID原理中的“ S”，是OOD的基础。 http://en.wikipedia.org/wiki/SOLID_ （面向对象的设计）这是Robert C. Martin撰写的SRP的PDF文件https://docs.google.com/file/d/0ByOwmqah_nuGNHEtcU5OekdDMkk/

从维基百科：

…在面向对象的编程中，单一职责原则规定每个类应具有单一职责，并且该职责应完全由该类封装。 它的所有服务都应严格地与这一责任相一致……。

从干净代码 ：

一个类或模块应该有一个更改理由 ，并且只有一个更改理由 。

因此，如果出于多种原因需要修改类（或模块），那么它会做的事情不只一件事。 即有多个责任。

为什么选择SRP？

• 整理代码
  假设有一家修理厂的汽车修理工。
  他有很多工具可以使用。 工具分为几种类型。 钳子，螺丝起子（菲利普斯/刀片），锤子，扳手（油管/六角）等等，如何简化工具的组织？ 每个抽屉中有几种类型不同的抽屉？ 或者，许多小抽屉，每个抽屉都有一个特定的类型？现在，把抽屉想象成模块 。 这就是为什么许多小模块（类）的组织性要强于大模块的原因。
• 不那么脆弱
  当一个班级有多个原因需要改变时，它就更加脆弱。
  一个位置的更改可能导致完全其他位置发生某些意外行为。
• 低耦合
  更多的责任导致更高的耦合度。
  联轴器是责任。 较高的耦合度导致更多的依赖关系，这更难维护。
• 代码变更
  对于单个职责模块而言，重构要容易得多。
  如果您想获得the 弹枪效果 ，请让您的班级承担更多责任。
• 可维护性
  显而易见，维护一个小的单一目的类比维护一个大型的单一类要容易得多。
• 可测性
  “单一目的类”的测试类将具有较少的测试用例（分支）。
  如果一个类有一个目的，那么它通常将具有更少的依赖关系，从而减少模拟和测试准备。 “通过测试进行自我记录”变得更加清晰。
• 调试更轻松
  自从我开始进行TDD和测试优先的方法以来，我几乎没有进行调试。 真。
  但是，有时候我必须调试才能了解发生了什么。 在单一职责类中，查找错误或问题原因变得容易得多。

什么需要承担单一责任？

系统的每个部分。

• 方法
• 班级
• 套餐
• 模块

如何识别SRP的中断？

• 类的依赖性过多
  输入参数太多的构造函数意味着很多依赖关系（希望您确实注入了依赖关系），另一种看到很多依赖关系的方法是测试类。
  如果需要模拟太多对象，通常意味着破坏SRP。
• 方法参数太多
  和全班同学的气味一样 将方法的参数视为依赖项。
• 测试班变得太复杂
  如果测试的变体太多，则可能表明班级职责过多。
  这可能表明某些方法做得太多。
• 类/方法长
  如果方法很长，可能表明它做得太多。
  上课也一样。 我的经验法则是，课程级别不应超过200-250 LOC。 包括进口
• 描述性命名
  如果您需要描述AND世界使用的类/方法/包，则可能会破坏SRP。
• 低内聚性
  凝聚力本身就是一个重要的话题，应该有自己的职位。
  但是，凝聚力和SRP密切相关，因此在这里提到它很重要。 通常，如果一个类（或模块）不是内聚的，则可能会破坏SRP。非内聚类的提示： 该类有两个字段。 某些方法使用一个字段。 其他方法使用其他字段。
• 一处改变打破另一处
  如果更改代码以添加新功能或仅重构就破坏了一项似乎无关的测试，则可能表明您违反了SRP。
• 弹枪效应
  如果更改很小，则会在代码中产生很大的涟漪。 如果需要更改许多位置，除其他气味外，它可能暗示SRP已损坏。
• 无法封装模块
  我将使用Spring进行解释，但是概念很重要（而不是实现）。
  假设您使用@Configuration或XML配置。 如果您无法在该配置中封装Bean，它应该给您带来太多责任的暗示。 配置应隐藏任何内部bean并公开最少的接口。 如果您出于多种原因需要更改配置，那么，您知道…

如何使设计符合单一责任原则

以下建议可适用于SOLID原则的其他主题。 它们也适用于任何“清洁法规”建议。
但是在这里，它们旨在实现“单一责任原则”。

• 意识
  这是干净代码的一般建议。
  我们需要注意我们的代码。 我们需要保重。 至于SRP，我们需要尽早尝试并赶上负责过多的课程。 我们需要始终寻找“太大的方法”。
• 可测试的代码
  以可以测试所有内容的方式编写代码。
  然后，您将非常希望您的测试简单且具有描述性。
• TDD
  （我不会在这里添加任何内容）
• 代码覆盖率指标
  有时，当一堂课做得太多时，一开始就不会有100％的覆盖率。
  检查代码质量指标。
• 重构和设计模式
  对于SRP，我们主要进行提取方法，提取类，移动方法。
  我们将使用组合和策略而非条件。
• 清晰的系统模块化
  当使用DI注入器（Spring）时，我认为Configuration类（或XML）可以查明模块设计。 和模块的单一责任。
  与拥有一个大文件/类相比，我更喜欢具有几个中小型的配置文件（XML或Java）。 它有助于了解模块的职责并易于维护。 我认为注入的配置方法具有注释方法的优势。 仅仅因为配置方法使模块成为人们关注的焦点。

结论

正如我在本文开头提到的那样，我认为单一职责原则是良好设计的基础。
如果在设计和开发过程中牢记此原则，那么您将拥有一个更简单易读的代码。
将遵循更好的设计。

最后一点

与往常一样，在应用实践，代码和设计时需要格外小心。 有时，我们可能会做过多的工作，使简单的事情变得复杂。 因此，在任何重构和变更中都必须应用常识。

翻译自: https://www.javacodegeeks.com/2014/02/the-single-responsibility-principle.html

最少承诺原则和单一职责原则