I need to have a helper type class that may be used by many classes. This class checks a company's financial status and determine some results or grading for the company. I am thinking about 2 approaches and want to see which makes better sense.
1) create a class like
2) create class like
If I use approach 1), it doesn't need to pass "company" as method parameter everytime but need to create "CompanyEval" instance everytime.
If I use approach 2), it doesn't need to create "CompanyEval" instance everytime but need to pass "company" to each method call.
What is the best practice for such Helper class design ?
Moreover, add private constructor to your 2nd option. In that sense you won't let instantiate your utility class. Having said that, user of the class will be able to use method by prefixing class name.
And seems you forgot to add return data type to your methods (2nd class).
Given your example I would propose a third option: Include those two methods in the Company interface itself.
I suggest this because the helper method functionality is dependent entirely on the data contained in the Company object, so who better to expose that functionality than the Company object.
To address your original question, assuming that moving them into the Company interface isn't the right approach, then I'd say it depends.
For me it all comes down to testing. Say the functionality of the 'helper' class is predictable and only makes decisions based on the Company object passed to it and maybe some constant class data, such as the value of xxxx in your example. In that case I'd be happy enough for it to be a static call and include it in the scope of my Unit Testing.
However, if the functionality of the 'helper' class is non deterministic or reliant on some external influence, such as a database or some System or application property, then I would prefer to make it an instance class so that I can replace it with a test double within my Unit Tests.
Tim Cooke wrote:Given your example I would propose a third option: Include those two methods in the Company interface itself. (...)
I would not leave that up to a company, since there are many ways a company can form a balance (and does so, for instance: DAP, IFRS, SolvencyII, own economic framework, USGAAP, ...). To get to some rating, you have to think of the things that are important for this. Have a look at some official rating agencies (like S&P, Moody's), and then decide how you would model this.
There are three kinds of actuaries: those who can count, and those who can't.
None of the things that Piet mentions there were presented by the OP as requirements so it's unfair to suggest any previous advice based on it is incorrect. Given the originally proposed functionality of the CompanyEval helper/utility class only depends on the passed Company class and some static values I maintain that those functionality would be better moved into the Company class.
To take into consideration the additional requirements Piet mentions would fall into the second part of my response categorised as "assuming that moving them into the Company interface isn't the right approach". Now your helper/utility class has dependencies on multiple external systems which means you would want to mock out those dependencies in your Unit Tests. In this case, as previously discussed, I would prefer to have the helper/utility class an instance class rather than static.