two approaches for a common Helper class

[Linwood Hayes]

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

public CompanyEval {

   private Company company;

   public CompanyEval(Company c) {
        this.company = c;
   }
   ...

   public String getCompanyGrade() {

       if(company.getBalance() > xxxx) {
          return "EXCELLENT";
       } else {
          return "OK";
       }
    }

    public boolean isCompanyStartup() {
       return true if it has < 1 year history
       ...
     }
}

2) create class like

public class CompanyEval {

   public static getCompanyGrade(Company c) {

      // do the same logic as approach 1...
 
   }

   public static isCompanyStartup(Company c) {
      // do the same logic as approach 1...
   }


}

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 ?

Thanks.

[Liutauras Vilda]

2nd.

Such classes are often called Utility classes.

Check this Campbell's post (<- link), and see if it falls to those strange his categories. He got some cows from me on that post

[Liutauras Vilda]

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.

Grade companyGrade = CompanyEval.getCompanyGrade(sunMicrosystems);

And seems you forgot to add return data type to your methods (2nd class).

[Tim Cooke]

Given your example I would propose a third option: Include those two methods in the Company interface itself.

public interface Company {
  BigInteger getBalance();
  int getYearsInOperation();
  String getCompanyGrade();
  boolean isStartUp();
}

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.

[Piet Souris]

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.

[Tim Cooke]

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.

[Gregg Bolinger]

I couldn't agree more with Tim. I avoid static utility class methods like the plague mostly because of testing.