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