Design question : having trouble with identifing my classes

Question

I am halfway through an OOP project in the finance industry, and I'm looking back at my design decisions. I've solved some problems using patterns, and I'm particularly proud of those, but elsewhere I seem to lack a bit of rigor. My own use cases are extremely high level, since the actual input done by the user doesn't even compare to the complexity of the calculations done underneath the hood. To give you an idea, I've had to both integrate a third-party mathematical solver AND a whole parser to allow the user to enter his own formulas.

It just happens that I have a good two dozen classes, all called in the same way : Calculator-whatever

My initial problem was that I had no clear and distinct domain objects to work from (except for the parsing module, for example). I had a great deal of difficulty thinking in terms of objects - it would have been far easier to write the program procedurally, since essentially we're just working with either money or percentages to arrive at new amounts and...percentages. I. couldn't think of any other entity other than Calculators ... calculating various weights or amounts. Everything seemed like a huge algorithm involving $$

My question is how does one think in objects when objects can't be found naturally in the domain model or the use cases ?

Answer 1

I've always found the most natural way is to try to understand in what way you can generalize like (or similar) objects. In a way, you've done the hard work by making the special cases, now you just need to look for similarities.

For example, in what way are all of your calculator classes similar (aside from the name)? Are they initialized similarly? Do they all have a "calculateTax" method? Do they all share a set of lower-level calculations? If you can abstract the structure of your calculations your multiple classes will naturally model as special cases of those.

Answer 2

You could think of the Calculator itself as an abstract entity in your domain model. Next apply the Strategy design pattern to take care of the various calculating algorithms. Once the CalculatorStrategy is in place, U could use other patterns like Decorators,Builders to get what you want.