srp unity_SRP是骗局

srp unity

根据罗伯特·马丁（ Robert Martin）的《清洁法》（ Clean Code），“ 单一责任原则 ”意味着“一个阶级应该只有一个改变的理由”。让我们尝试解密这个模糊的语句，看看它如何帮助我们设计更好的面向对象软件。如果是这样。

我在有关SOLID的帖子中曾经提到SRP，说它并不能真正帮助程序员理解1974年由Larry Constantine提出的古老的“高凝聚力”概念。现在让我们通过示例进行观察并分析如何考虑到SRP以及是否会变得更加面向对象，改进类。

让我们试着类AwsOcket从jcabi-S3 （我已经简化了代码）：

class AwsOcket {boolean exists() { /* ... */ }void read(final OutputStream output) { /* ... */ }void write(final InputStream input) { /* ... */ }
}

如果我错了，请纠正我，但根据SRP，此类负责太多事情：1）检查AWS S3中对象的存在，2）读取其内容，以及3）修改其内容。对？这不是一个好的设计，必须对其进行更改。

为了更改它并使它仅负责一件事，我们必须引入一个getter，它将返回一个AWS客户端，然后创建三个新类： ExistenceChecker ， ContentReader和ContentWriter 。他们将检查，读取和写入。现在，为了阅读内容并将其打印到控制台，我目前正在这样做：

if (ocket.exists()) {ocket.read(System.out);
}

明天，如果我重构类，我将这样做：

if (new ExistenceChecker(ocket.aws()).exists()) {new ContentReader(ocket.aws()).read(System.out);
}

除了一个事实，即这些跳棋，读者和作家都算不上类，但程序纯持有人，这的用法ocket变成了一场噩梦。当我们将其传递到某个地方时，我们真的无法再知道会发生什么。例如，我们不能保证来自其中的内容会被即时解密或解码。我们根本无法装饰它。它不再是一个对象，而是一个AWS客户端的持有者，其他地方的某些类正在使用该客户端。

是的，现在它只负责一件事：封装对AWS客户端的引用。就SRP而言，这是一个完美的课程。但这不再是一个对象。

如果您完全使用SRP原理，则对任何类都将发生相同的情况：它将成为数据或其他对象的持有者，并且在它们之上具有一组setter和getter。也许除了这些之外，还有一种额外的方法。

我的观点是，SRP是一个错误的主意。

使班级小并且具有凝聚力是一个好主意，但是让他们对“一件事情负责”是对“高度凝聚力”概念的误导性简化。它只是将它们变成了其他东西的笨拙的载体，而不是成为较小实体的封装和装饰者，以构造较大的实体。

在为这个假的SRP想法而斗争时，我们失去了一个更重要的原则，那就是关于真正的面向对象的编程和思考：封装。与对象保护其封装的实体的紧密程度相比，对象负责多少事情并不重要。具有一百种方法的怪物对象比具有五对吸气剂和吸气剂的DTO的问题要少得多！这是因为DTO会在整个代码中散布问题，而我们甚至都找不到它，而Monster对象始终就在我们眼前，我们可以将其重构为更小的片段。

如果有的话，封装是第一位的，尺寸是第二位的。