¿Las clases de utilidad son malas? [cerrado]

Vi este hilo

Si una clase de "Utilidades" es mala, ¿dónde pongo mi código genérico?

y pensé ¿por qué son malvadas las clases de servicios públicos?

Digamos que tengo un modelo de dominio que tiene decenas de clases de profundidad. Necesito poder xml-ify instancias. ¿Hago un método toXml en el padre? ¿Hago una clase auxiliar MyDomainXmlUtility.toXml? Este es un caso en el que la necesidad empresarial abarca todo el modelo de dominio: ¿realmente pertenece como método de instancia? ¿Qué pasa si hay un montón de métodos auxiliares en la funcionalidad xml de la aplicación?

Las clases de utilidad no son exactamente malas, pero pueden violar los principios que componen un buen diseño orientado a objetos. En un buen diseño orientado a objetos, la mayoría de las clases deberían representar una sola cosa y todos sus atributos y operaciones. Si está operando en una cosa, ese método probablemente debería ser miembro de esa cosa.

Sin embargo, hay ocasiones en las que puede usar clases de utilidades para agrupar varios métodos; un ejemplo es la java.util.Collectionsclase que proporciona una serie de utilidades que se pueden usar en cualquier colección de Java. Estos no son específicos de un tipo particular de colección, sino que implementan algoritmos que se pueden usar en cualquier colección.

Realmente, lo que debe hacer es pensar en su diseño y determinar dónde tiene más sentido colocar los métodos. Por lo general, es como operaciones dentro de una clase. Sin embargo, a veces, es una clase de utilidad. Sin embargo, cuando utilice una clase de utilidad, no se limite a incluir métodos aleatorios en ella, sino que organice los métodos por propósito y funcionalidad.

Creo que el consenso general es que las clases de servicios públicos no son malas per se . Solo necesita usarlos con prudencia:

• Diseñe los métodos de utilidad estática para que sean generales y reutilizables. Asegúrese de que sean apátridas; es decir, sin variables estáticas.

• Si tiene muchos métodos de utilidad, divídalos en clases de manera que sea más fácil para los desarrolladores encontrarlos.

• No use clases de utilidad donde los métodos estáticos o de instancia en una clase de dominio serían una mejor solución. Por ejemplo, considere si los métodos de una clase base abstracta o una clase auxiliar de la que se pueden crear instancias serían una mejor solución.

• Para Java 8 en adelante, los "métodos predeterminados" en una interfaz pueden ser una mejor opción que las clases de utilidad. (Consulte Interfaz con métodos predeterminados frente a la clase abstracta en Java 8, por ejemplo).

La otra forma de ver esta Pregunta es observar que en la Pregunta citada, "Si las clases de utilidad son" malas "" es un argumento de paja. Es como si yo preguntara:

"Si los cerdos pueden volar, ¿debo llevar un paraguas?".

En la pregunta anterior, en realidad no estoy diciendo que los cerdos puedan volar ... o que estoy de acuerdo con la proposición de que podrían volar.

Las declaraciones típicas de "xyz es malvado" son recursos retóricos que tienen la intención de hacerte pensar planteando un punto de vista extremo. Rara vez (si es que alguna vez) se intentan como declaraciones de hechos literales.

Las clases de servicios públicos son problemáticas porque no agrupan las responsabilidades con los datos que las respaldan.

Sin embargo, son extremadamente útiles y los construyo todo el tiempo como estructuras permanentes o como peldaños durante una refactorización más completa.

Desde la perspectiva del Código Limpio , las clases de servicios públicos violan la Responsabilidad Única y el Principio Abierto-Cerrado. Tienen muchas razones para cambiar y, por diseño, no son extensibles. Realmente solo deberían existir durante la refactorización como cruft intermedio.

Supongo que empieza a volverse malvado cuando

1) Se vuelve demasiado grande (solo agrúpelos en categorías significativas en este caso).
2) Existen métodos que no deberían ser estáticos

Pero mientras no se cumplan estas condiciones, creo que son muy útiles.

Regla de oro

Puede ver este problema desde dos perspectivas:

• Los *Utilmétodos generales son a menudo una sugerencia de un mal diseño de código o una convención de nomenclatura lenta.
• Es una solución de diseño legítima para funcionalidades sin estado entre dominios reutilizables. Tenga en cuenta que para casi todos los problemas comunes existen soluciones.

Ejemplo 1. Uso correcto de utilclases / módulos. Ejemplo de biblioteca externa

Supongamos que está escribiendo una aplicación que administra préstamos y tarjetas de crédito. Los datos de estos módulos se exponen a través de servicios web en jsonformato. En teoría, puede convertir objetos manualmente en cadenas que estarán dentro json, pero eso reinventaría la rueda. La solución correcta sería incluir en ambos módulos una biblioteca externa utilizada para convertir objetos Java al formato deseado. (en la imagen de ejemplo he mostrado gson )

Ejemplo 2. Uso correcto de utilclases / módulos. Escribir el tuyo utilsin excusas a otros miembros del equipo

Como caso de uso, supongamos que necesitamos realizar algunos cálculos en dos módulos de aplicación, pero ambos necesitan saber cuándo hay días festivos en Polonia. En teoría, puede realizar estos cálculos dentro de los módulos, pero sería mejor extraer esta funcionalidad en un módulo separado.

Aquí hay un detalle pequeño, pero importante. La clase / módulo que ha escrito no se llama HolidayUtil, pero PolishHolidayCalculator. Funcionalmente es una utilclase, pero hemos logrado evitar la palabra genérica.

Las clases de servicios públicos son malas porque significan que eras demasiado vago para pensar en un nombre mejor para la clase :)

Dicho esto, soy un vago. A veces solo necesitas hacer el trabajo y tu mente está en blanco ... ahí es cuando las clases de "Utilidad" comienzan a aparecer.

Mirando hacia atrás en esta pregunta ahora, diría que los métodos de extensión de C # destruyen por completo la necesidad de clases de utilidad. Pero no todos los lenguajes tienen una construcción tan genial.

También tiene JavaScript, donde puede agregar una nueva función directamente al objeto existente.

Pero no estoy seguro de que realmente haya una forma elegante de resolver este problema en un lenguaje más antiguo como C ++ ...

Un buen código OO es un poco difícil de escribir y es difícil de encontrar, ya que escribir Good OO requiere mucho más tiempo / conocimiento que escribir un código funcional decente.

Y cuando tienes un presupuesto limitado, tu jefe no siempre está feliz de ver que has pasado todo el día escribiendo un montón de clases ...

No estoy del todo de acuerdo con que las clases de servicios públicos sean malas.

Si bien una clase de utilidad puede violar los principios de OO de alguna manera, no siempre son malos.

Por ejemplo, imagina que quieres una función que limpie una cadena de valores coincidentes de todas las subcadenas x.

stl c ++ (a partir de ahora) no es compatible directamente con esto.

Podría crear una extensión polimórfica de std::string.

Pero el problema es, ¿realmente quieres que CADA cadena que uses en tu proyecto sea tu clase de cadena extendida?

Hay momentos en los que OO realmente no tiene sentido, y este es uno de ellos. Queremos que nuestro programa sea compatible con otros programas, así que nos quedaremos std::stringy crearemos una clase StringUtil_(o algo).

Yo diría que es mejor si te quedas con una utilidad por clase. Yo diría que es una tontería tener una utilidad para todas las clases o muchas utilidades para una clase.

Es muy fácil calificar algo como una utilidad simplemente porque el diseñador no pudo pensar en un lugar apropiado para colocar el código. A menudo hay pocas "utilidades" verdaderas.

Como regla general, generalmente guardo el código en el paquete donde se usa por primera vez, y luego solo lo refactorizo ​​a un lugar más genérico si descubro que más tarde realmente se necesita en otro lugar. La única excepción es si ya tengo un paquete que realiza una funcionalidad similar / relacionada, y el código encaja mejor allí.

Las clases de utilidad que contienen métodos estáticos sin estado pueden resultar útiles. Suelen ser muy fáciles de realizar pruebas unitarias.

Con Java 8 puedes usar métodos estáticos en interfaces ... problema resuelto.

La mayoría de las clases de Util son malas porque:

1. Amplían el alcance de los métodos. Hacen público el código que de otro modo sería privado. Si varias personas que llaman necesitan el método util en clases separadas y es estable (es decir, no necesita actualización), en mi opinión, es mejor copiar y pegar métodos auxiliares privados en la clase de llamada. Una vez que lo expone como una API, hace que sea más difícil entender cuál es el punto de entrada público a un componente jar (mantiene un árbol estructurado llamado jerarquía con un padre por método. Esto es más fácil de segregar mentalmente en componentes, lo cual es más difícil cuando tiene métodos llamados desde varios métodos principales).
2. Resultan en código muerto. Los métodos de utilidades con el tiempo dejan de utilizarse a medida que su aplicación evoluciona y termina con un código no utilizado que contamina su base de código. Si hubiera permanecido privado, su compilador le diría que el método no está en uso y que podría simplemente eliminarlo (el mejor código es ningún código). Una vez que haga que este método no sea privado, su computadora no podrá ayudarlo a eliminar el código no utilizado. Se puede llamar desde un archivo jar diferente para todo lo que la computadora sabe.

Hay algunas analogías entre bibliotecas estáticas y dinámicas.

Cuando no puedo agregar un método a una clase (digamos, Accountestá bloqueado contra cambios por Desarrolladores Jr.), simplemente agrego algunos métodos estáticos a mi clase de Utilidades así:

public static int method01_Account(Object o, String... args) {
    Account acc = (Account)o;
    ...
    return acc.getInt();
}  

Las clases de utilidad no siempre son malas. Pero solo deben contener los métodos que son comunes en una amplia gama de funciones. Si hay métodos que solo se pueden utilizar entre un número limitado de clases, considere la posibilidad de crear una clase abstracta como un padre común y coloque los métodos en ella.