Es el uso de las clases *** Helper o *** Util que solo contienen métodos estáticos un AntiPattern

14

A menudo me confrontan con clases de ayuda o utilidad en Java o cualquier otro tipo de lenguaje. Así que me preguntaba si esto es algún tipo de Anti Pattern y la existencia de este tipo de clases es solo una falta de errores en el diseño y la arquitectura de un Software.

A menudo, estas clases se limitan usando solo métodos estáticos, que hacen mucho de cosas. Pero en su mayoría, es de hecho dependiente del contexto y de estado.

Mi pregunta es, ¿cuál es su opinión sobre este tipo de clases estáticas de helper / util porque la ventaja es, por supuesto, la rápida invocación usando solo el nombre de la clase?

¿Y a qué nivel de abstracción evitaría usar este tipo de clases?

En mi opinión, la palabra clave "estática" debería permitirse dentro de la declaración de una clase (Java) y no por métodos. En mi opinión, usarlo de esta manera, podría ser una buena alternativa y una alternativa para poder combinar los Paradigmas Procuedural y OO en Java y evitar el mal uso de la palabra clave.

Adiciones debidas a las respuestas:

Al principio, creo que es completamente legal poder combinar diferentes paradigmas e incluso usar lenguajes de script interpretados en tiempo de ejecución dentro de la máquina o código compilado vm.

Mi experiencia es que durante el proceso de desarrollo de un proyecto, este tipo de ayudantes y empleados, o como se llame, crecen y se utilizan en cada rincón olvidado de la base de código, que originalmente fue diseñado para ser modular y flexible. Y debido a la falta de tiempo para hacer refactorizaciones o volver a pensar en el diseño, lo empeorará mucho con el tiempo.

Creo que static debería eliminarse de Java. Especialmente ahora donde es posible utilizar elementos del lenguaje funcional aún más sofisticados.

    
pregunta Diversity 18.07.2018 - 21:50

5 respuestas

19

Bueno, Java carece de funciones libres, por lo tanto, se ve obligado a ponerlas como funciones estáticas en alguna clase pro-forma. Una solución de trabajo necesaria nunca es un antipatrón, aunque puede carecer de elegancia.

A continuación, no hay nada malo con las funciones gratuitas. En realidad, el uso de funciones gratuitas reduce el acoplamiento, ya que solo tienen acceso a la interfaz pública en lugar de todos los detalles sangrientos.

Por supuesto, el uso de funciones libres / estáticas no alivia de ninguna manera los peligros de un estado mutable compartido, especialmente global.

    
respondido por el Deduplicator 18.07.2018 - 23:12
15

La utilidad estática o las funciones de ayuda no son un patrón anti si se ajustan a algunas pautas:

  1. Deben estar libres de efectos secundarios

  2. Se utilizan para el comportamiento específico de la aplicación que no pertenece a la clase o clases en las que operan estas funciones

  3. No requieren ningún estado compartido

Casos de uso común:

  • Formateo de fechas en una aplicación específica
  • Funciones que toman un tipo como entrada y devuelven un tipo diferente.

Por ejemplo, en una aplicación en la que trabajé, los usuarios guardan entradas de diario para sus actividades. Pueden especificar una fecha de seguimiento y descargar un recordatorio de evento. Creamos una clase de utilidad estática para tomar una entrada de diario y devolver el texto en bruto para un archivo .ics.

No requiere ningún estado compartido. No mutó ningún estado, y la creación de un evento de iCal ciertamente fue específica de la aplicación y no pertenecía a la clase de entrada de diario.

Si las funciones estáticas o las clases de utilidad tienen efectos secundarios o requieren un estado compartido, recomendaría volver a evaluar este código, ya que introduce un acoplamiento que puede ser difícil de simular para las pruebas unitarias.

    
respondido por el Greg Burghardt 19.07.2018 - 14:21
4

Dependerá de su enfoque. Muchas aplicaciones se escriben con una mentalidad más funcional, a diferencia de la mentalidad clásica (incluida gran parte del conjunto de sitios en los que se encuentra).

Con esta mentalidad, habrá muchos métodos de utilidad en clases de trabajadores que pueden unirse como métodos estáticos. Se alimentan / usan más cerca de objetos simples que solo contienen datos y se pasan.

Es un enfoque válido y puede funcionar muy bien, especialmente a escala.

    
respondido por el Tracker1 18.07.2018 - 22:34
2

Personalmente, creo que la única parte importante de estas clases de ayuda es que se hagan privadas. Además de eso, son estrictamente una buena idea (aplicada con moderación).

La forma en que pienso de esto, es si al implementar una clase (o función), algo como esto es útil y hace que la implementación sea más clara, ¿cómo podría ser malo? Y a menudo es crítico definir tales clases de ayudantes privados para permitir la integración y el uso de otros algoritmos que dependen de que los datos estén en una forma particular.

La etiqueta de "ayudante" es una cuestión de gusto personal, pero implica que ayuda en la implementación y no es de interés / uso para un público más amplio. Si eso es lo que tiene sentido, ¡adelante!

    
respondido por el Lewis Pringle 18.07.2018 - 22:24
1

La prevalencia de static clases de ayuda se basa en una idea falsa. El solo hecho de que llamemos a las clases con solo los métodos static "clases de utilidad" no significa que no se permita escribir un comportamiento común en los POJO.

Las clases de ayuda static son antipatrón por tres razones:

  1. El acceso estático a estos métodos de ayuda oculta las dependencias . Si estas "clases de utilidad" fueran POJO, podría inyectarlas int a una clase dependiente como parámetros del constructor , lo que haría que la dependencia sea evidente para cualquier usuario de una clase dependiente.

  2. El acceso estático a estos métodos de ayuda causa acoplamiento apretado . Esto significa que el código que usa los métodos de ayuda es difícil de reutilizar y (como efecto secundario) hart para probar.

  3. Especialmente si mantienen estado , estas son simplemente variables globales . Y espero que nadie diga que las variables globales son buenas ...

Las clases de ayuda estática forman parte del código STUPID .

  

El estado global no está relacionado con la pregunta, - max630

El OP escribió:

  
    

Pero en su mayoría es de hecho dependiente del contexto y de estado.

  

Las construcciones de estado estáticas son estados globales.

  

Cualquier tipo de código puede usarlo. - max630

Sí, de causa. Y casi todas las aplicaciones necesitan algún tipo de estado global .

Pero estado global ! = variable global .

Puede crear estado global con técnicas OO a través de inyección de dependencia , pero no puede evitar el estado global con estructuras estáticas de estado completo que son variables globales en la parte inferior.

    
respondido por el Timothy Truckle 18.07.2018 - 22:57

Lea otras preguntas en las etiquetas