Oj, widzę, że się wytworzyło środowisko antystaticowe ;)
Generalnie statyczne utilities wszelkiego rodzaju są OK, pod warunkiem że to rzeczywiście utilities.
Oto dlaczego:
Charakterystyczne cechy metod utilsowych:
a) niewielka złożoność
b) bardzo rzadko się zmieniają
c) pisane są "na bieżąco", wraz z implementacją bardziej skomplikowanej logiki
Jeśli w projekcie jest jakiś mechanizm DI to można się jeszcze kłócić - kwestia gustu, czy ktoś woli coś takiego:
public class BusinessServiceImpl implements BusinessService {
@Inject
private UtilsA utilsA;
@Inject
private UtilsB utilsB;
@Inject
private UtilsC utilsC;
@Inject
private UtilsD utilsD;
@Override
public BusinessResult get(BusinessData businessData){
A a = utilsA.createA(businessData);
B b = utilsB.createB(businessData);
C c = utilsC.createC(businessData);
D d = utilsD.createD(businessData);
// do something
}
}
od:
public class BusinessServiceImpl implements BusinessService {
@Override
public BusinessResult get(BusinessData businessData){
A a = UtilsA.createA(businessData);
B b = UtilsB.createB(businessData);
C c = UtilsC.createC(businessData);
D d = UtilsD.createD(businessData);
// do something
}
}
Moim zdaniem to drugie jest czytelniejsze i dlatego wolę to stosować. Jeśli tylko ludzie trzymają się tego, żeby tylko metody utilsowe nie były złożone oraz żeby zmiana biznesowa nie powodowała zmiany w takiej metodzie to nic złego się nie stanie.
Jak to testować? Jednostkowo. Za tym idzie oczywiście założenie, że w statycznym kontekście nie będzie niczego do mockowania (dane z zewnątrz - pliki, baza danych itp.). Proste wejście-wyjście, bez żadnych udziwnień.
Co do tworzenia instancji klasy takiego utils'a - dziwny pomysł. Niepotrzebnie nadmuchuje to metodę (jeśli utils'y są tworzone wewnątrz metody) lub obiekt (jeśli utils'y są tworzone wewnątrz klasy).