2

I want to implement a database driven payroll system using CSharp. I already did it once, but the implementation sucks so I want to do it again and do it right.

My first thought is to create a static class calculator which would simply hold all the formulas, one private method per formula. One main public method "Calculate" which would take a ref Employee type object as a parameter. Take data from the object, apply the formulas and set the objects properties, but my guess is this would probably suck.

One class with a bunch of properties for holding all the "(algebraic) constants". One class containing and managing the object. This class would deserialize the class holding all the data and serialize on app exit. The calculator would use this class to get data and apply the formulas to make changes to the "Employee". These "constants" would be changable from inside the application.

Thoughts ?

I am not good when it comes to structuring applications and a lot of my implementations end up sucking... I realize that I hate it when I need to make changes to the application.

Thanks

  • I'm not sure if I follow you correctly, but it sounds like you may be thinking of using the Visitor Pattern. What do you think? – Dan Pichelman Nov 4 '15 at 14:58
  • That's interesting and sounds like a good solution. I have to revisit those damn patterns. – Orvel Nov 4 '15 at 16:50
  • Note that it's not necessary to use ref just to change an object's properties. Objects are passed by reference in C# anyway. The only thing extra that ref allows you to do is assign a entirely different Employee to the passed-in Employee. f.ex. public void MyMethod(ref Employee employee) { employee = new Employee(...); } – Kasey Speakman Nov 4 '15 at 22:00
  • A more formal definition of suck would help. What, other than "sucks," is actually wrong with your current implementation? Why would your proposed solution suck? – Caleb Aug 14 '18 at 19:37
-1

Here are a couple suggestions to help you think in new directions:

First, it seems like you're trying to tie your calculation functionality specifically to your Employee class. That seems unnecessarily specific. Why should your calculator class care whether the object it's working on represents an employee or something else? This seems like a natural place to use an interface to define the functionality that your calculator needs to apply a formula, without caring what the thing that implements the interface actually represents. And the functionality that your calculator needs is probably pretty simple: it just needs to be able to get named values and possibly also set named values. If you have a formula like:

annualVacationDays = 10 + yearsOfService + bonusDays

then it seems like you might need a Calculable interface that has a function like valueForkey(key) where key is a string, so that the calculator can fetch values for yearsOfService and bonusDays in order to do its work. And the interface should also have a setValueForKey(value, key) method so that it can store the result of the formula for the annualVacationDays key. But the only things the calculator needs to do its work are those methods -- it shouldn't care what kind of object it is.

Second, given that the point of OOP is that you can combine data and the operations on that data, separating the formulas from the class that applies them doesn't make a lot of sense to me. Let each formula be able to apply itself to an object that implements the Calculable interface.

  • I disagree that calculations should take objects as parameters. Mathematical formulas as much more readable when they take in primitives. I might not object to struct wrappers around primitives if you’re aiming for type safety though. – RubberDuck Aug 14 '18 at 23:51
  • @RubberDuck Not so much objects as parameters to the formula, but as the source of values for the variables in a formula. E.g. you might have a formula like area = base * height, and you'd tell the formula to evaluate itself in the context of some object that can supply values for base and height, just as a formula in a spreadsheet pulls values from other cells. I'm not suggesting objects as parameters to a formula, but rather one or more objects as context that supplies parameter values. Also, I don't think the OP is concerned with human readability of the formulae in question. – Caleb Aug 15 '18 at 1:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.