单一职责原则实现

Question

如果我将我的对象分解成“单一职责”，是否有一个基本的想法，即类似的对象应该放在一起还是分开，例如，如果我有：

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要求我将对象从现实世界的表示转变为围绕单个功能概念的属性和方法。

- lagerdalek

Answer 1

回归面向对象编程的基础：员工对象应具有反映其功能的方法，而不是对其进行操作的方法。

- Mark Brittingham

---

+1：所有额外的东西都不是Employee的一部分。它们是与Employee相关的某些应用程序的一部分。 - S.Lott

“不想对示例中给出的对象的可行性进行批评”这句话有什么意思吗？ - johnc

Answer 2

尽管没有人回答我关于原则本身的问题，而不是我提供的有些糟糕的例子，即一个Employee对象过多地了解影响它的过程，但对于那些显然对这个问题感兴趣的人（有2个“收藏”星），我做了更多的阅读，尽管我希望能够进行更多的讨论。

我认为两个当前答案试图表达的是，分离的责任应该能够独立存在，并且我的例子是不应该做的完美例子。我非常乐意接受这一点。

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

“然而，请注意，我已经重新将这两个职责耦合成一个单独的ModemImplementation类。这是不可取的，但可能是必要的。通常有各种各样的原因，与硬件或操作系统的细节有关，迫使我们将我们不想耦合的东西耦合起来。但是，通过分离它们的接口，我们已经在应用程序的其余部分中将概念解耦。”

“我们可以将ModemImplementation类视为一个修补程序或一个缺陷；但是，请注意，所有依赖项都从它流出。没有人需要依赖于这个类。除了main之外，没有人需要知道它的存在。因此，我们把丑陋的东西放在了围栏后面。它的丑陋不需要泄漏出来污染应用程序的其余部分。”

我认为“请注意，所有依赖项都从它流出”这一行在这里很重要。

- lagerdalek