lyn*_*nxx 6 java oop design-patterns single-responsibility-principle solid-principles
我对单一职责原则很困惑。该原则指出，类更改的原因应该只有一个。
我面临的问题是，对方法的任何更改或做事中的任何逻辑更改都会更改类。例如，考虑以下类：
class Person{
public void eat(){ };
public void walk(){ };
public void breathe(){ };
public void run(){ };
public void driveCar(Car car){ };
}
鲍勃叔叔将其描述为应该只有一个人/演员负责更改。我有以下两个问题：
\n\n\n
\n- 对于上述课程，谁是负责更改的参与者/人员？
\n
参与者是用户（包括客户、利益相关者、开发人员、组织）或外部系统。我们可以争论人是否是一个系统，但这并不存在。
\n另请参阅：用例。
\n\n\n\n
\n- 饮食、呼吸或行走逻辑的任何改变不会改变 Person 类吗？那么，这是否意味着每种方法都是改变的理由，因为其做事的逻辑可能会改变？
\n
不，方法不是改变的理由。方法是可以改变的……但为什么会改变呢？什么会促使开发商改变它？
\n单一责任原则的一部分是代码最多应该与一个外部系统交互。请记住，并非所有参与者都是外部系统，但有些是。我认为大多数人会发现 SRP 的这一部分很容易理解，因为我们可以在代码中看到与外部系统的交互。
\n然而，这还不够。例如，如果您的代码必须计算税收，您可以在代码中对税率进行硬编码。这样，它就不会与任何外部系统交互（它只是使用常量）。然而，在一项税收改革之后，政府被揭露为更改代码的原因。
\n您应该能够做的事情是交换外部系统（可能需要一些额外的编码工作）。例如，从一种数据库引擎更改为另一种。然而，我们不希望这些更改之一转化为对代码的完全重写。更改不应传播，并且更改不应破坏其他内容。为了确保这一点，我们希望隔离所有处理数据库引擎的代码（在本例中）。
\n\n\n因相同原因而变化的事物应归为一组，因不同原因而变化的事物应分开。\n-- Robert C Martin
\n
我们可以对上面的政府例子做类似的事情。我们可能不希望软件读取国会会议纪要，相反，我们可以让它读取配置文件。现在外部系统是文件系统，并且会有与其交互的代码，并且该代码不应该与其他任何东西交互。
\n您的代码是由一组需求定义的。有些是功能性的，有些则不是。如果这些要求中的任何一个发生变化，您的代码就必须更改。更改需求的原因就是更改代码的原因。
\n注意：您可能没有记录所有需求，但是，未记录的需求仍然是一个需求。
\n然后，您需要知道这些要求从何而来。谁或什么可以改变他们？这些就是你改变的原因。这可能是公司政治的变化，可能是我们添加的功能，可能是新的法律，也可能是我们正在迁移到不同的数据库引擎或不同的操作系统，翻译成另一种语言，适应另一个国家等等。
\n其中一些是与您的代码交互的外部系统（例如数据库引擎），有些则不是（公司的政治）。
\n你想孤立他们。因此，您将拥有与数据库交互的代码，而没有其他代码。您将拥有实现业务规则的代码，仅此而已。等等。
\n要意识到，即使代码的每个部分的实现都将依赖于外部的东西，但它们的接口不一定如此。因此，定义接口并注入依赖项，这样您就可以更改每个部分的实现，而不必更改其他部分\xe2\x80\xa6，也就是说，代码部分的实现不应该成为更改其实现的理由代码的其他部分。
\n注意：代码的任何部分都不应该承担多重职责。让代码的一部分负责处理每个职责，并让代码的一部分负责将其他部分组合在一起。同样，如果代码的一部分没有责任\xe2\x80\xa6，则没有理由保留它。因此，代码的每一部分都应该有一个职责。
\n对于你的代码，问问自己，类的要求是什么Person。它们完整吗？他们从哪里来？他们为什么要改变？
有关单一责任原则的更权威的解释，请参阅Robert C Martin - 单一责任原则（51 分 8 秒，英语），挪威开发者大会，2015 年。
\n