违反单一责任原则的最佳例子是什么？

Question

我正在寻找一些违反单一职责原则的良好代码示例。不要向我展示鲍勃叔叔的书籍或网站中的任何示例，因为这些示例在互联网上随处可见，例如：

interface Modem
{
    public void dial(String pno);
    public void hangup();
    public void send(char c);
    public char recv();
}

Answer 1

面向对象设计的粒度取决于个人喜好，可能不适合其他人。因此，我不会在某些业务逻辑类中寻找打破单一责任原则的例子，讨论它是否有太多或太少的事情要做。

在我看来，最好的例子（具有最严重的副作用）来自于打破应用程序的分层。 F.ex.：

• 在数据访问层中执行业务逻辑（其唯一的职责应该是提供对应用程序的持久访问）
• 从（通过）域模型访问业务服务（其唯一的职责应该是存储大部分应用程序的状态）
• 在视图层执行复杂的业务逻辑（负责数据呈现和用户输入）

Answer 2

以下是我必须承担的 PHP 项目中的一些代码：

class Session
{
    function startSession()
    {
        // send HTTP session cookies
    }

    function activateUserAccount()
    {
        // query the DB and toggle some flag in a column
    }

    function generateRandomId()
    {}

    function editAccount()
    {
        // issue some SQL UPDATE query to update an user account
    }

    function login()
    {
        // perform authentication logic
    }

    function checkAccessRights()
    {
        // read cookies, perform authorization
    }
}

我相信这个类确实做了很多事情。

Answer 3

关于 SRP 的线索是定义职责，以便您的实现能够完成该任务。这就像您正在制定规则（通过为类指定名称和职责）然后尝试遵循它。

因此，如果您不遵循它，那么您要么没有正确定义规则，要么在实现规则时不一致（或两者兼而有之，这实际上可能是最常见的情况）。

我通常发现那些在定义单一主要责任或好名字方面没有做出半体面尝试的类是最好的违规行为。然后你只需要阅读整个课程来尝试确定是否有任何明确定义的职责。

Answer 4

实际上，在我使用过的大多数面向对象语言中，顶级 Object 类就是一个很好的例子。例如，在 Ruby 中，Object 类（或更准确地说，Kernel mixin，它被混合到 Object 中）有 45 个公共实例方法。现在，其中一些是化名，但仍然至少有 20 个，而且他们来自世界各地。我可以轻松识别至少 5 项职责。

现在，我并不是要挑衅 Ruby。这是我最喜欢的编程语言。这就是为什么我用它作为例子：因为它是我最熟悉的语言。我有理由确信我所写的有关 Ruby 的内容至少也 100% 适用于 Java 和 .NET。

Answer 5

确定类的“责任”是一个定性问题。
仅查看给定的类代码，绝不能让我们了解它处理其职责的情况。
至少根据我的经验，非常有必要考虑对类的需求更改将如何传播到其他模块（或者其他类的更改将如何传播到此类）。

正如@schmeedy对“打破系统的分层”给出了很好的解释，我认为这只是分析“责任域”的方法之一。

我试图进一步展开讨论。我的尝试是以定量的方式定义“责任”。
我博客上的一些讨论： http://design-principle -pattern.blogspot.in/2013/12/single-responsibility-principle.html

Answer 6

#import <Foundation/Foundation.h>
#import <CoreGraphics/CoreGraphics.h>

@interface Spreadsheet : NSObject

- (void)loadFromURL:(NSURL *)url;
- (void)saveToURL:(NSURL *)url;
- (void)drawTo:(CGRect*)targetArea withContext:(CGContextRef *)context;

@end

我认为上面的例子违反了 SRP。

从表面上看，很明显该类负责一件事：电子表格。它与文档管理问题域中的其他实体（例如文字处理）不同。

但是，请考虑电子表格对象可能发生变化的原因。

电子表格的基础模型可能会发生变化。这会影响加载和保存代码，但不会影响电子表格的绘制方式。因此加载/保存职责与绘图职责是分开的。我们班有两个职责。

因此，如果我们考虑更改类的所有合理可预见的原因，并且看到只有类上的特定方法会受到影响，我们就会看到一个机会来分解责任以获得更集中的类。

修改后的类将是：

@interface SpreadsheetEncoder

- (NSData *)encodedSpreadsheet:(Spreadsheet *)spreadsheet;
- (Spreadsheet *)spreadsheetFromEncodedData:(NSData *)data;

@end

@interface Spreadsheet2 : NSObject

- (NSData *)data;
- (instancetype)initSpreadsheetFromData:(NSData *)data;
- (void)drawTo:(CGRect*)targetArea withContext:(CGContextRef *)context;

@end

随着产品开发的进展，我们可以再次问自己“可能会发生什么变化”，然后重构这些类，使它们只负责一个问题。 SRP 仅与问题域以及我们在给定时间对它的理解相关。

在我看来，SRP 归结为问“什么可以改变？”以及“会受到什么影响”。当“可以更改的内容”仅映射到受影响的一件事时，您就拥有了实现 SRP 原则的类。