1

I am working on a java class for parsing HTML and generating RDF (which I think I will eventually split into two classes - one for parsing and one for generating RDF).

At the moment I am creating a lot of methods for checking HTML data and converting it into a more uniform representation. Some of the methods I have created so far are:

public boolean isInteger(String str) { }
public boolean isTime(String str) { }
public boolean isDate(String str) { }
public String dateConverter(String[] date) { } //Converts a Norwegian date into mmddYYYY

Should I put methods like these into a util class? At the moment they are only being used by this specific class, but I think that they might need to be use them by more than this one class at a later point in time.

Jea
  • 484
  • 2
  • 5
  • 17
  • Why not.. Do you have a more specific question? –  Oct 13 '13 at 18:56
  • No not really, I guess I just wanted to know if my thoughts about putting these methods into a utils class was correct. I want to better my OOP skills! – Jea Oct 13 '13 at 19:06

4 Answers4

3

Well, yes, the methods you listed look like good candidates for public static methods in a util class. (The last 2 or 3 would fit nicely in a class called "DateUtils", for example.)

Of course, if you only use them in one place, they can just as well remain "private helpers" there, but as soon as you have multiple places using them, a util class makes sense.

(Edit: overuse of static methods can be problematic, but I think these methods could well be static utils because they are pure functions.)

Community
  • 1
  • 1
Jonik
  • 80,077
  • 70
  • 264
  • 372
1

They seem generic enough to be appropriate to put in a util class. I would, at the very least. Basically any class that parses String in your code would need to use those methods. I would make them static before adding them to the class though to avoid unnecessary construction.

Decomposition is a good habit to get into. If you are unsure about whether or not you need to use them, then go ahead and do so. It will give you practice with using utility classes.

Skylion
  • 2,696
  • 26
  • 50
1

It is a good practice to collect such methods in a utility class. Even if they are called from a single class at the moment, these kind of methods will be potentially reused by other clients in a near feature.

However, you must pay attention to make this utility class easy to be reused. To do this, the method signatures, actually their arguments, must be as generic as possible. They should not take inputs specific to a class.

Another advice of mine is dividing this utility class into more than one classes, if it begins to contain many incoherent methods. You can do this by grouping the relevant methods in a separate class. For example, methods you wrote can be moved to TypeUtils class and you can collect conversion related methods in Html2RdfUtils class for instance.

Finally, if you feel that these utility classes can be benefical to your other projects, you can collect them in a distinct library.

ovunccetin
  • 8,443
  • 5
  • 42
  • 53
0

if you eventually want to split them into two classes, you may want to define the baseclass as interface or abstract class.

Base on your requirement, abstract class should be the right choose. Put something in common from the child class to the abstract class.(You can implement method in the abstract class)

from another answer, I want to ask a question? the answer suggest putting static in front of the method to avoid unnecessary construction, it very make sense.

I know the abstract class does not require to be instantiated to call its method. it also can avoid construction.

There is the question? Which way is more legit? or better? or just same.

SCV
  • 406
  • 2
  • 14