mercredi 24 août 2016

Common Code In Extracted Into Utility Classes Bad Practice? - Java

Recently was working on a project with a lot of duplicated, but simple code. They are mostly for setting, getting and casting values e.g.

@SuppressWarnings("unchecked")
<...>
Map<String,String> dataMap =  (Map<String,String>) tcp().getData().getBodyAs(Map.class);
<...>

I crated utility classes and methods like

public final class DataHelper
<...>
@SuppressWarnings("unchecked")
public Map<String,String> getDataMapFromBody (TCP tcp) {
    return (Map<String,String>) tcp().getData().getBodyAs(Map.class);
}

I think this is better than the old code at least 3 ways:

  • code is not duplicated
  • don't have to use SuppressWarnings everywhere
  • the method name gives some hint about what it does

But was told this is

  • anti pattern and
  • can't be tested

I think with these methods testing is not a problem as just mock the input, that would be needed anyway when testing w/o these utility classes.

They also say use inheritance, but I think in this case it's unpractical as these snippets are everywhere in the code, and introducing sub-classing just for these is overkill.

Am I really wrong about this approach with utility classes? If not how to convince my superiors?

I also read this SO -> Utility classes are evil? question but I think it says I'm right.

EDIT- TCP class is 3rd party - don't have source code.

Aucun commentaire:

Enregistrer un commentaire