The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
根据Robert Martin的《Clean Code》所述，单一责任原则意味着“一个类应该只有一个改变的原因”。让我们尝试解读这个相当模糊的陈述，并看看它如何帮助我们设计更好的面向对象软件。如果它确实有所帮助的话。
我在关于SOLID的文章中提到过SRP，说它并不能真正帮助程序员理解由Larry Constantine在1974年引入的“高内聚性”概念。现在让我们通过例子来看看，并分析在考虑SRP的情况下如何改进一个类，以及这个类是否会变得更加面向对象。
让我们试试来自jcabi-s3的AwsOcket类（我简化了代码）：
如果我错了，请指正，但根据SRP，这个类负责太多事情：1）检查AWS S3中对象的存在性，2）读取其内容，和3）修改其内容。对吗？这不是一个好的设计，必须进行更改。
为了改变它并使其只负责一件事，我们必须引入一个getter，它将返回一个AWS客户端，然后创建三个新的类：ExistenceChecker、ContentReader和ContentWriter。它们将进行检查、读取和写入。现在，为了读取内容并将其打印到控制台，我目前正在执行以下操作：
明天，如果我重构这个类，我将会做以下操作：
除了这些检查程序、读取程序和写入程序实际上并不是类，而是纯粹的过程持有者之外，使用这个 ocket 就变成了一场噩梦。我们无法确定在将其传递到其他地方时会发生什么。例如，我们无法保证从中获取的内容是否会在传递过程中进行解密或解码。我们无法对其进行装饰。它不再是一个对象，而是一个 AWS 客户端的持有者，由其他某些类使用。
是的，现在它只负责一件事：封装对 AWS 客户端的引用。就 SRP 而言，它是一个完美的类。但它不再是一个对象。
如果将 SRP 原则应用到任何类上，都会发生同样的情况：它们将变成数据或其他对象的持有者，并拥有一组设置器和获取器。也许还有一个额外的方法。
我的观点是，SRP 是一个错误的理念。
让类变得小而内聚是一个好主意，但让它们只负责 “一件事” 是对 “高内聚” 概念的一种误导性简化。这只会使它们成为其他东西的愚蠢承载者，而不是构造更大实体的封装器和装饰器。
在我们追求这个虚假的 SRP 理念时，我们失去了一个更重要的原则，这个原则实际上与真正的面向对象编程和思维有关：封装。一个对象负责多少个事情远不如它对封装的实体有多紧密地保护重要。一个拥有一百个方法的庞大对象远没有一个只有五个成对的获取器和设置器的 DTO 麻烦！这是因为 DTO 在整个代码中都散布着问题，我们甚至无法找到它，而庞大对象总是在我们面前，我们总是可以将其重构为更小的部分。
首先是封装，其次才是大小，如果有的话。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 16:48
