L'utilisation des classes *** Helper ou *** Util contenant uniquement des méthodes statiques est-elle un AntiPattern
Je suis souvent confronté à des classes auxiliaires ou utilitaires en Java ou tout autre type de langage. Je me demandais donc s'il s'agissait d'une sorte d'Anti Pattern et l'existence de ce type de classes n'est qu'un absence de lacunes dans la conception et l'architecture d'un logiciel.
Souvent, ces classes sont confinées en utilisant uniquement des méthodes statiques, qui font beaucoup de choses. Mais la plupart du temps, cela dépend du contexte et de l'état.
Ma question est, quelle est votre opinion sur ce type de classes d'aide/utilitaire statiques, car l'avantage est bien sûr l'invocation rapide en utilisant uniquement le nom de la classe.
Et à quel type de niveau d'abstraction éviteriez-vous d'utiliser ce genre de classes?
À mon avis, le mot clé "statique" devrait simplement être autorisé dans la déclaration d'une classe (Java) et non pour les méthodes. À mon avis, en l'utilisant de cette façon, cela pourrait être une bonne alternative et un moyen terme pour pouvoir combiner les paradigmes procu-dural et OO dans Java et éviter une mauvaise utilisation du mot-clé.
Ajouts dus aux réponses:
Au début, je pense qu'il est tout à fait légal de pouvoir combiner différents paradigmes et même d'utiliser des langages de script interprétés au moment de l'exécution dans du code compilé machine ou vm.
D'après mon expérience, au cours du processus de développement d'un projet, ce type d'aides et d'utilitaires ou quel que soit le nom, grandit et grandit et est utilisé dans tous les coins oubliés de la base de code, qui était à l'origine conçue pour être modulaire et flexible. Et en raison du manque de temps pour effectuer des refactorisations ou repenser le design, vous ne faites qu'empirer les choses au fil du temps.
Je pense que static devrait être supprimé de Java. Surtout maintenant où il est possible d'utiliser des éléments de langage fonctionnel encore plus sophistiqués.
Eh bien, Java manque de fonctions libres, donc vous êtes obligé de les mettre en tant que fonctions statiques dans une classe pro-forma. Un contournement nécessaire n'est jamais un anti-modèle, bien qu'il puisse manquer d'élégance .
Ensuite, il n'y a rien de mal avec les fonctions gratuites. En fait, l'utilisation de fonctions gratuites réduit le couplage, car elles n'ont accès qu'à l'interface publique au lieu de tous les détails sanglants.
Bien sûr, l'utilisation de fonctions libres/statiques n'atténue en aucun cas les dangers d'un état partagé mutable, en particulier global.
Les fonctions utilitaires ou d'assistance statiques ne sont pas un anti-modèle si elles respectent certaines directives:
Ils devraient être exempts d'effets secondaires
Ils sont utilisés pour un comportement spécifique à l'application qui n'appartient pas à la classe ou aux classes sur lesquelles ces fonctions opèrent
Ils ne nécessitent aucun état partagé
Cas d'utilisation courants:
- Formatage des dates d'une manière spécifique à l'application
- Fonctions qui prennent un type en entrée et retournent un type différent.
Par exemple, dans une application sur laquelle j'ai travaillé, les utilisateurs conservent des entrées de journal pour leurs activités. Ils peuvent spécifier une date de suivi et télécharger un rappel d'événement. Nous avons créé une classe utilitaire statique pour prendre une entrée de journal et renvoyer le texte brut d'un fichier .ics.
Cela ne nécessitait aucun état partagé. Il ne modifiait aucun état et la création d'un événement iCal était certainement spécifique à l'application et n'appartenait pas à la classe d'entrée de journal.
Si les fonctions statiques ou les classes utilitaires ont des effets secondaires ou nécessitent un état partagé, je recommanderais de réévaluer ce code, car il introduit un couplage qui peut être difficile à simuler pour les tests unitaires.
Cela dépendra de votre approche. De nombreuses applications sont écrites avec un état d'esprit plus fonctionnel, contrairement à l'état d'esprit classique (y compris une grande partie de la suite de sites sur laquelle vous vous trouvez).
Avec cet état d'esprit, il y aura beaucoup méthodes utilitaires sur les classes de travailleurs qui peuvent être regroupées en tant que méthodes statiques. Ils sont nourris/utilisés plus près d'objets simples qui ne contiennent que des données et sont transmis.
C'est une approche valable et peut très bien fonctionner, surtout à grande échelle.
Personnellement, je pense que la seule partie importante de ces classes d'assistance est qu'elles soient rendues privées. En plus de cela - ils sont strictement une bonne idée (appliqués avec parcimonie).
La façon dont je pense à cela - c'est si dans l'implémentation d'une classe (ou d'une fonction) - quelque chose comme ça est utile, et rend cette implémentation plus claire, comment cela pourrait-il être mauvais? Et souvent, il est essentiel de définir ces classes d'assistance privées pour permettre l'intégration et l'utilisation d'autres algorithmes qui dépendent de la forme particulière des données.
Que ce soit pour l'étiqueter "aide" est une petite question de goût personnel, mais cela implique qu'il aide à la mise en œuvre et qu'il ne présente aucun intérêt/utilisation pour un public plus large. Si c'est ce qui a du sens - allez-y!
La prévalence de static classes d'assistance est basée sur une idée fausse. Ce n'est pas parce que nous appelons des classes avec uniquement des méthodes static "classes utilitaires" qu'il n'est pas autorisé d'écrire un comportement courant dans les POJO.
static les classes d'assistance sont anti-pattern pour trois raisons:
L'accès statique à ces méthodes d'assistance masque les dépendances . Si ces "classes utilitaires" étaient des POJO, vous pourriez les injecter dans une classe dépendante en tant que paramètres constructeur ce qui rendrait la dépendance évidente pour tout utilisateur d'une classe dépendante.
L'accès statique à ces méthodes d'assistance provoque un couplage serré . Cela signifie que le code en utilisant les méthodes d'assistance est difficile à réutiliser et (comme effet secondaire) difficile à tester.
Surtout s'ils maintiennent état ce ne sont que variables globales . Et j'espère que personne ne prétend que les variables globales sont bonnes ...
Les classes auxiliaires statiques font partie du code STUPID anti pattern.
L'état global n'est pas lié à la question, - max630
L'OP a écrit:
Mais la plupart du temps, cela dépend du contexte et de l'état.
Constructions statiques statiques sont états globaux.
tout type de code peut l'utiliser. - max630
Oui, de cause. Et presque toutes les applications ont besoin d'une sorte de état global.
Mais état global! = variable globale.
Vous pouvez créer état global avec OO techniques via injection de dépendances Mais vous ne pouvez pas éviter l'état global avec des structures statiques pleines d'état qui sont variables globales en bas.