Is the relation between Salary, Earnings and Deductions composition, aggregation or generalization?

Question

In a payroll system I have a class called Salary. To prepare salary we need Earnings and Deduction details of employees.

For eg:

Earnings may be: Basic Salary, Overtime, Allowances etc. Deductions may be: Fines, Loan installments, Welfare contributions etc.

I just want to know what's the relationship between these Salary, Deduction and Earning classes. It seems that the Deduction and Earning is a part of salary so it may have a composition/aggregation relationship.

However you calculate salary as : [Salary = Earnings - Deductions].

Also SalaryID, EmployeeID and Date fields may be common for both Earning and Deduction classes which could be inherited from Salary.

So that could you please clarify what relationships the above classes have in this scenario? I'd also appreciate if you could show an example of how those relationships are implemented in classes.

EDIT: Im trying to develop a win forms system employing MVP pattern and my language is C#.net. Basically I have employee attendance in the database so using two SPs I generate earnings and deductions. Then the user is give an UI to edit figures or to enter random figures like special allowances, fines etc. Finally all deduction and earning details will be saved in a single table called SalaryTrans [sal_id, emp_id, pay_period, basic_salary,overtime_payment, allowances, fines , other_deductions, ..., gross_salary].

Answer 1

How about the following structure:

Earnings and Deductions are abstract classes and inherited by concrete concepts.

In order to calculate a Salary for a month, you just need to create a set of Earnings and Deductions and to assign them to a corresponding Salary. The Salary's amount is calculated automatically (therefore "derived" att), so no worry about that.

The most important decision is how to create Earning and Deduction objects for a month. A possible way is to add a method in Salary that creates Earnings and Deductions according to a well defined algorithm and connects them with itself. Salary object has all the info needed to calculate this (Person, month). I like this method, because all the knowledge remains localized, the whole structure remains nicely closed and encapsulated.

Answer 2

I'd model payments (I say payment rather than earning because paychecks have positive numbers which aren't earnings) and deductions as a single class hierarchy: an interface or superclass PayrollAmount with subclasses like SalaryPayment, ReimbursementPayment, FederalTaxDeduction, MedicalInsuranceDeduction, etc. Each Amount has the pay period as an attribute.

The Salary you refer to above doesn't need to be a class as far as I can see; it's just a number calculated by summing all of the Amounts. There might be a Paycheck class; that would aggregate the Amounts, and it could have a method that returned the salary.

Answer 3

One way of approaching this problem would be to think of the situation as this: At the time constructing a Salary object, do you need to have all Deduction(s) and Earnings(s), AND they need to be calculated once, at that time? If so, then it is probably a composition. However, if Earnings and Deductions can be added and removed from Salary, at random times, then it is probably Aggregation.

In general, First, try to derive this relationship from the business domain. See in that domain how they are related. Secondly, it also makes a difference how you are implementing your system, what technology you use. For example, some implementations (e.g. for object-relational or other database storage purposes) may require IDs, while some others don't. The bottom line is that it depends a lot on your particular situation.

Answer 4

This kind of questions should be asked to the "business" near you. I think not the World Wide programmers community. Ask your "business" and write it down in a document so you can discuss with them.

To code before knowing how that "business" should work should lead to a disaster. My approach with be making a entity-relationship diagram.

Pencil and eraser is cheaper then carving in code.