Est-il bon d'avoir une classe "Utils" dans votre projet logiciel ?

Question

En général, pendant le développement d'un logiciel, il y a toutes sortes de fonctions utilitaires dont j'ai besoin. Comme le fichier zippé, l'extraction du fichier zip, le lancement du navigateur Web, l'obtention d'une image à l'échelle...

Ce que j'ai fait, c'est que j'ai placé toutes ces fonctions utilitaires comme des fonctions statiques dans une seule classe nommée "Utils".

https://github.com/yccheok/jstock/blob/master/src/org/yccheok/jstock/gui/Utils.java

Est-ce une bonne pratique ? Les choses deviendront-elles ingérables lorsque le nombre de fonctions sera de plus en plus important ?

Answer 1

C'est absolument une bonne pratique ! Vous ne voulez pas mélanger toutes ces fonctions utilitaires avec le reste de la logique métier de votre application. Cependant, à mesure que vos fichiers et/ou classes d'utilitaires se développent, il est recommandé de les regrouper en fonction de la fonction qu'ils fournissent.

Par exemple, dans une application Web, vous pourriez vous retrouver avec une structure de paquetage comme celle-ci.

org.sample.web.model
org.sample.web.utils
org.sample.web.validators
org.sample.web.validators.utils

Answer 2

Oui, les classes utilitaires sont une bonne idée, mais, comme avec l'ensemble de la programmation orientée objet, vous devriez viser pour un maximum de cohésion, un minimum de couplage.

Une cohésion signifie que tout dans une seule classe devrait être fortement liés les uns aux autres. Minimes de couplage signifie qu'il devrait être pas inutile de dépendances entre les classes.

En d'autres termes, la formation de grumeaux ensemble de compression avec la manipulation de l'image ou le lancement d'un processus externe, dans une classe unique est une mauvaise idée. Par tous les moyens d'avoir un utilitaire de compression de classe et une image de l'utilitaire de manipulation de cours, mais ne pas les mettre ensemble.

Cela est semblable à l'utilisation d'un singleton comme un dieu objet, un ghetto où vous venez de vider tous vos déchets doit être mieux organisée. Je dirais que c'est correct d'utiliser un uber-utilitaire de la classe pendant le développement, mais assurez-vous que votre code est mieux organisé avant l'expédition. L'entretien sera beaucoup plus facile.

Est-ce une bonne pratique?

Non, pas dans le long terme bien que c'est utile quand fait temporairement.

Les choses vont grandir ingérable quand le nombre de fonctions de croître plus en plus grandes?

Oui, aucun doute à ce sujet.

Answer 3

Non, je ne pense pas que les classes d'utilités soient une bonne pratique. D'un point de vue psychologique, le mot "Utilités" est trop large et même si vous le divisez en plusieurs classes, *Util deviendra juste une décharge pour les choses qui sont "trop difficiles" pour être intégrées dans un design de classe approprié.

Prenons par exemple une classe StringUtils pseudo-fictive. Vous pourriez avoir des centaines de méthodes d'encodage/décodage pour différents schémas, des transformations de casse, la gestion des espaces blancs, etc. Une meilleure approche, je pense, est d'utiliser le pattern de stratégie pour gérer ces transformations, ce qui permettrait même potentiellement au code client d'introduire de nouvelles transformations sans avoir besoin de modifier/recompiler le code original. Vous obtenez un système plus puissant, plus flexible et plus facile à maintenir.

Answer 4

Si c'est au moins statique alors cela a du sens dans un Util classe. C'est facile ! La cohésion et le couplage sont destinés à vous rendre la vie plus facile. plus facile mais il s'agit d'une situation claire dans laquelle ils ne le feraient pas, donc je vous suggère de continuer comme vous le faites.

Answer 5

S'agit-il d'une bonne pratique ?

Dans la plupart des cas, j'utilise cette méthode.

comme pour toute programmation orientée objet, vous devez viser une cohésion maximale et un couplage minimal.

Ne tuez pas votre productivité en suivant strictement ces règles, vous pouvez voir de nombreux cadres excellents les enfreindre.