De acuerdo con una interpretación rígida de Object Oriented Design, una clase de utilidad es algo que debe evitarse.
El problema es que si sigues una interpretación rígida, entonces deberás forzar a tu clase a algún tipo de objeto para lograr muchas cosas.
Incluso los diseñadores de Java crea clases de utilidad (java.lang.Math viene a la mente)
Las opciones son:
double distance = Math.sqrt(x*x + y*y); //using static utility class
vs:
RootCalculator mySquareRooter = new SquareRootCalculator();
mySquareRooter.setValueToRoot(x*x + y*y);
double distance;
try{
distance = mySquareRooter.getRoot();
}
catch InvalidParameterException ......yadda yadda yadda.
Incluso si tuviéramos que evitar el método detallado, todavía podríamos terminar con:
Mathemetician myMathD00d = new Mathemetician()
double distance = myMathD00d.sqrt(...);
en este caso, .sqrt() sigue siendo estático, entonces, ¿qué sentido tiene crear el objeto en primer lugar?
La respuesta es crear clases de utilidad cuando su otra opción sería crear algún tipo de clase "Trabajador" artificial que no tenga o tenga poco uso para las variables de instancia.
'java.lang .Math' es 100% de métodos estáticos con un constructor 'privado' (no se puede crear una instancia). – Asaph
No estoy seguro de si esta pregunta ha sido formulada en este foro. ¿Pero es una mala práctica para una clase tener solo campos estáticos? He visto muchas de esas clases y, en mi opinión, no encajan en OOP. – ka3ak
@ ka3ak Las clases que solo tienen campos estáticos se tratan parcialmente en algunas respuestas a esta pregunta. –