Dependency between multiple classes

Question

I am confuse between the best way to organize dependency between multiple classes
assume i have the following classes Employee, Salary, DataAccess

Should i go for: Option1

Employee emp = new Employee();
Salary sal = new Salary();
DataAccess data = new DataAccess();

sal.Calculate(emp);
data.Save(emp);

or Option2

Employee emp = new Employee();
Salary sal = new Salary();

sal.Calculate(emp); //once salary has been calculated salary object will initialize  data access class to do the actual saving.

or Option 3

Employee emp = new Employee();
emp.Calculate(); // employee object will encapsulate both the salary and data access object

Answer 1

Seems to me that 'CalculateSalary' should be something that happens as part of some other object, and it is given various information about the employee. Some sort of 'SalaryCalculator' object, perhaps ... Something like:

employee.Salary = SalaryCalculator.CalculateFor(employee); 

As to how the saving happens; well I'd leave that up to the ORM you use, personally.

Answer 2

The short answer is "It Depends".

For most scenarios like salary calculation, my guideline would be to look at what data is needed by the computation. If a majority of inputs belong to ClassA, then it indicates that it should be a method of ClassA.

Persistence is however a special case. Persistence is a 'service' ; you tell someone to go write this to disk for later retrieval. There is no state of any one object that is being accessed. So create a stateless service that accepts the input that needs to be serialized/deserialized

DAO_Service.Save(anEmployee);
DAO_Service.Save(preferences);
DAO_Service.Save(taxRecord);

Answer 3

Agree with It depends answer.

If you want to keep your domain model clean (logic is quite complicated) you can ask object to calculate value (in case it doesn't need some external data from another sources) and use another service for persistance.

However, you can put DataAcccess into your objects (if logic looks simple) and use them as some kind of Proxy between other services and persisted version but don't forget to inject DataAccess to your objects as a interface (in a setter or constructor) to have an easy ability to test or change.

Answer 4

Usually Employee HAS-A salary. So I'd go with something like:

Employee emp = new Employee();
emp.Salary = new Salary();

You can create a generic class that would fetch all of the salary calculation business rules in it(from a data source), and calculate salary for employees based upon employee attributes.

SalaryCalculator.CalculateSalary(emp); //I'd agree with Silky
DataAccess.Save(emp); //This shall save changes in emp as well as in salary.

--EDIT--

This is in response to your comment.

Your hrms object(if any) should then encapsulate the Employee, and provide a CalculateSalary option.

How about something like:

yourHrms.Employees.Add(new Employee(Age, Name, DateOfBirth, EmployedSince, TotalExperience, IsManager, new Salary(someStartPointForSalaryIfAny));

Here your Salary class would inherit from your abstact BaseSalary class, that would contain the business rules, and would perform the Calculate()ions. Therefore, the new Salary(someStartPointForSalaryIfAny) would perform the calculation internally.

To save your object you can have:

yourHrms.Employees.Save();//Saves all employees.
yourHrms.Employees[0].Save();//Save this.

Answer 5

You can implement ActiveRecord pattern for Employee, to look like this:

Employee emp = new Employee();
emp.Salary = SalaryManager.CalculateSalary(emp);
emp.Save(); //Save to some IDataStore logic.