单一职责原则的实施
如果我将我的对象分解为“单一职责”，是否有一个基本的想法，类似的对象应该生活在一起还是分开，例如，如果我有
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 确实要求我从作为现实世界表示的对象转向作为围绕单个功能概念的属性和方法的对象
If I break my Objects down to 'Single Responsibilities', is there a fundamental thought whether like objects should live together or separately, for example if I have
class Employee_DataProvider() : IEmployee_DataProvider { ... };
class Employee_Details() : IEmployee_Details { ... };
class Employee_Payroll() : IPayroll() { ... };
class Employee_LeaveProcessing() : ILeaveProcessing_Client { ... };
...
Is it bad smell to have all these living inside, yet loosely coupled to through interfaces, an owning Employee class:
class Employee
{
IEmployee_DataProvider _dataProvider;
IEmployee_Details _details;
IPayroll _payroll;
ILeaveProcessing_Client _leaveProcessing;
//My functions call the interfaces above
}
or is the thinking more around keeping these classes completely separate (or as least as separate as is posible) in the code? Or are both these methods a valid usage of SRP?
EDIT: I do not want critique on the feasibility of the object given in the example, I just made it up to illustrate the question. I agree data, leave and payroll processing are not the domain of the employee class.
It does appear though that SRP is asking me to move away from the object as real world representation to object as a properties and methods around a single functional concept
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
回到 OOP 基础知识：Employee 对象应该具有反映它所做的事情的方法，而不是反映对其所做的事情。
Go back to OOP basics: the Employee object should have methods that reflect what it does, not what is done to it.
尽管还没有人解决我关于原则本身的实际问题，而不是我给出的有点糟糕的例子，即 Employee 对象对影响它的过程了解太多，对于那些显然对这个问题感兴趣的人（有 2 “最喜欢的”星星）我已经做了更多的进一步阅读，尽管我希望有更多的讨论。
我认为当前的两个答案试图表达的是，分离的责任应该能够独立存在，而我的例子是不该做什么的完美例子。 我非常乐意接受这一点。
ObjectMentor（鲍勃叔叔的网站）中有一段段落，其中有一个示例将 Connection 和 DataReader 对象（以前位于调制解调器类中的两个对象，然后分离出来）合并到 ModemImplementation 中，但声明
我认为“注意所有依赖项都远离它”这一行在这里很重要
Although no one has yet addressed my actual question regarding the principle itself, rather than the somewhat poor example I gave, of an Employee object knowing too much about the processes that affect it, for those who are obviously interested in the question (there are 2 'favourites' stars) I've done a bit more further reading, although I was hoping for more of a discussion.
I think what the two current answers are trying to say is that responsibilities separated should be able to be stand alone, and that my example was a perfect example of what not to do. I am more than happy to accept that.
There is a paragraph from ObjectMentor (Uncle Bob's site) that has an example that combines Connection and DataReader objects (two objects previously living in a modem class then separated out) into a ModemImplementation, but states
I think the line 'notice that all dependencies flow away from it' is an important one here