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

最新推荐文章于 2022-02-05 21:52:02 发布

danpu0978

最新推荐文章于 2022-02-05 21:52:02 发布

阅读量414

点赞数

文章标签： java 设计模式 python 人工智能编程语言

原文链接：https://www.javacodegeeks.com/2014/02/the-single-responsibility-principle.html

版权

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

介绍

在这篇文章中，我想介绍单一责任原则（ 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）。它有助于了解模块的职责并易于维护。我认为注入的配置方法具有注释方法的优势。仅仅因为配置方法使模块成为人们关注的焦点。