Introducing the principle of shared responsibility

Question

If I break my objects to “Single Responsibilities”, is there a fundamental thought, should such objects 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 { ... }; ... 

It smells bad that they all live inside, but are loosely connected to interfaces that own the Employee class:

 class Employee { IEmployee_DataProvider _dataProvider; IEmployee_Details _details; IPayroll _payroll; ILeaveProcessing_Client _leaveProcessing; //My functions call the interfaces above } 

or thinks more about these classes to be completely separate (or at least as separate as possible) in the code? Or are both of these methods a valid use of SRP?

EDIT: I don’t want to critically evaluate the possibility of the object shown in the example, I just did it to illustrate the question. I agree that data processing, vacation and payroll is not an employee class domain.

It appears, although SRP asks me to move away from the object as a representation of the real world to the object as properties and methods around one functional concept.

Answer 1

Although no one has yet examined my actual question about the principle itself, and not about some bad example that I gave, that the Employee object knows too much about the processes that affect it, for those who are clearly interested in the question (there are 2 "selected" stars). I read a little more, although I was hoping for a larger discussion.

I think the two current answers are trying to say that shared responsibilities should be alone and that my example was a great example of what not to do. I am more than happy to accept this.

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 shared) in ModemImplementation, but indicates

However, note that I untied the two responsibilities into a single ModemImplementation Class. This is not desirable, but it may be necessary. Often there are reasons that need to be done with the details of the hardware or OS that make us combine things that got married, not a couple. However, by sharing their interfaces, we have unleashed the concepts since the rest of the application.

We can look at the ModemImplementation class - is it a kludge or wart; However, note that all dependencies leak from it. No one should depend on this class. None but the basic needs that it exists. So an ugly bit behind the fence. this ugliness should not leak out and pollute the rest of the application.

I think that the line “note that all dependencies on it” is important here

Answer 2

Back to the basics of OOP: an Employee object must have methods that reflect what it does, and not what is done with it.