Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

two approaches for a common Helper class

 
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?

Thanks.
 
Marshal
Posts: 8107
571
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 8107
571
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
Marshal
Posts: 5136
321
IntelliJ IDE Python Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 4682
183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 5136
321
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I couldn't agree more with Tim. I avoid static utility class methods like the plague mostly because of testing.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic