单一职责原则的实现答案

【问题标题】：Implementation of Single Responsibility Principle单一职责原则的实现
【发布时间】：2009-01-17 02:06:12
【问题描述】：

如果我将我的对象分解为“单一职责”，是否有一个基本的想法是应该一起生活还是分开生活，例如，如果我有

class Employee_DataProvider() : IEmployee_DataProvider { ... };
class Employee_Details() : IEmployee_Details { ... };
class Employee_Payroll() : IPayroll() { ... };
class Employee_LeaveProcessing() : ILeaveProcessing_Client { ... };
...

将所有这些都存在于内部，但通过接口松散耦合到拥有的 Employee 类，这是不是很糟糕：

class Employee
{
    IEmployee_DataProvider _dataProvider;
    IEmployee_Details _details;
    IPayroll _payroll;
    ILeaveProcessing_Client _leaveProcessing;

    //My functions call the interfaces above

}

还是更多地考虑在代码中将这些类完全分开（或尽可能地分开）？或者这两种方法都是 SRP 的有效用法？

编辑：我不想批评示例中给出的对象的可行性，我只是为了说明问题而编造出来的。我同意数据、休假和工资单处理不是员工类的领域。

尽管 SRP 确实要求我从作为现实世界表示的对象转移到作为围绕单个功能概念的属性和方法的对象

【问题讨论】：

标签： oop solid-principles single-responsibility-principle

【解决方案1】：

回到 OOP 基础知识：Employee 对象应该有方法来反映它做了什么，而不是对它做了什么。

【讨论】：

+1：所有额外的东西都不是员工的一部分。它是一些涉及 Employee 的应用程序的一部分。
'不想批评示例中给出的对象的可行性'意味着什么？

【解决方案2】：

虽然没有人回答我关于原则本身的实际问题，而不是我给出的有点糟糕的例子，但对于那些显然对这个问题感兴趣的人来说，一个 Employee 对象对影响它的过程了解太多（有 2 颗“最喜欢”的星）我已经做了更多的进一步阅读，尽管我希望有更多的讨论。

我认为当前的两个答案试图说明的是，职责分离应该能够独立存在，而我的示例是不做什么的完美示例。我很乐意接受这一点。

ObjectMentor（Bob 叔叔的网站）中有一个段落，其中有一个示例将 Connection 和 DataReader 对象（两个对象以前存在于调制解调器类中，然后分离出来）组合成 ModemImplementation，但声明

但是，请注意我已经重新耦合两个职责合二为一 Modem 实现类。这不是可取，但可能是必要的。往往有原因，不得不做带有硬件的详细信息或操作系统，这迫使我们将事物结合起来我们宁愿不结婚。然而，通过分离它们的接口，我们有将概念解耦至应用程序的其余部分。

我们可以查看 ModemImplementation 阶级是杂物，或疣；然而，请注意所有依赖项都流走了从中。没有人需要依赖这个班级。除了主要的没有人需要知道它存在。因此，我们把栅栏后面的丑陋部分。它的丑不必外泄污染应用程序的其余部分。

我认为“注意所有依赖项都远离它”这一行在这里很重要

【讨论】：