Les classes d'utilité publique sont-elles diaboliques ?

Question

J'ai vu cette question : Si une classe "Utilities" est mauvaise, où dois-je mettre mon code générique ?

Et je me suis dit : pourquoi les classes d'utilité sont-elles mauvaises ?

Supposons que j'aie un modèle de domaine comportant des dizaines de classes. J'ai besoin de pouvoir xml-ifier les instances. Dois-je créer une méthode toXml sur le parent ? Dois-je créer une classe d'aide MyDomainXmlUtility.toXml ? Il s'agit d'un cas où le besoin métier s'étend à l'ensemble du modèle de domaine - est-ce vraiment une méthode d'instance ? Qu'en est-il s'il y a un tas de méthodes auxiliaires sur la fonctionnalité XML de l'application ?

Answer 1

Les classes utilitaires ne sont pas vraiment diaboliques, mais elles peuvent violer les principes qui composent une bonne conception orientée objet. Dans une bonne conception orientée objet, la plupart des classes doivent représenter une seule chose et tous ses attributs et opérations. Si vous opérez sur une chose, cette méthode devrait probablement être un membre de cette chose.

Cependant, il est parfois possible d'utiliser des classes utilitaires pour regrouper un certain nombre de méthodes. java.util.Collections qui fournit un certain nombre d'utilitaires pouvant être utilisés sur n'importe quelle collection Java. Ces utilitaires ne sont pas spécifiques à un type particulier de collection, mais mettent en œuvre des algorithmes qui peuvent être utilisés sur n'importe quelle collection.

En fait, ce que vous devez faire, c'est réfléchir à votre projet et déterminer où il est le plus judicieux de placer les méthodes. En général, il s'agit d'opérations à l'intérieur d'une classe. Cependant, il arrive parfois que ce soit en tant que classe utilitaire. Lorsque vous utilisez une classe utilitaire, ne vous contentez pas d'y placer des méthodes au hasard, mais organisez plutôt les méthodes en fonction de leur objectif et de leur fonctionnalité.

Answer 2

Je pense que le consensus général est que les classes d'utilité ne sont pas mauvaises en soi . Il suffit de les utiliser judicieusement :

• Concevoir les méthodes utilitaires statiques pour qu'elles soient générales et réutilisables. Veillez à ce qu'elles soient sans état, c'est-à-dire sans variables statiques.

• Si vous avez beaucoup de méthodes utilitaires, répartissez-les dans les classes de manière à ce que les développeurs puissent les trouver facilement.

• N'utilisez pas de classes utilitaires lorsque des méthodes statiques ou d'instance dans une classe de domaine seraient une meilleure solution. Par exemple, examinez si les méthodes d'une classe de base abstraite ou d'une classe d'aide instanciable seraient une meilleure solution.

• À partir de Java 8, les "méthodes par défaut" d'une interface peuvent être une meilleure option que les classes utilitaires. (Voir Quand l'utiliser : Méthode par défaut de l'interface Java 8+, vs. méthode abstraite par exemple).

---

L'autre façon d'examiner cette question est d'observer que dans la question citée, "Si les classes d'utilité sont "mauvaises"" est un argument de paille. C'est comme si je demandais :

"Si les cochons peuvent voler, dois-je porter un parapluie ?

Dans la question ci-dessus, je ne dis pas que les cochons peuvent voler... ou que je suis d'accord avec la proposition selon laquelle ils peuvent voler... pourrait voler 1 .

Typique "xyz est le mal" sont des procédés rhétoriques qui visent à faire réfléchir en présentant un point de vue extrême. Elles sont rarement (voire jamais) considérées comme des énoncés de faits littéraux.

---

1 - Et vous ne devriez PAS interpréter cette question de paille comme conseil sur la question de savoir s'il faut toujours emporter un parapluie lorsqu'on est à l'extérieur.

Answer 3

Les classes d'utilité sont problématiques parce qu'elles ne regroupent pas les responsabilités avec les données qui les soutiennent.

Ils sont cependant extrêmement utiles et je les construis constamment, soit comme structures permanentes, soit comme tremplins lors d'un remaniement plus approfondi.

A partir d'un Code propre Les classes d'utilité en perspective violent le principe de la responsabilité unique et le principe de l'ouverture-fermeture. Elles ont de nombreuses raisons de changer et ne sont pas extensibles de par leur conception. Elles ne devraient exister que lors d'un remaniement, en tant qu'éléments intermédiaires.

Answer 4

Je suppose que le mal commence à se manifester lorsque

1) Il devient trop grand (dans ce cas, il suffit de les regrouper dans des catégories significatives).
2) Des méthodes qui ne devraient pas être des méthodes statiques sont présentes

Mais tant que ces conditions ne sont pas remplies, je pense qu'ils sont très utiles.

Answer 5

Règle empirique

Ce problème peut être abordé sous deux angles :

• Dans l'ensemble *Util sont souvent le résultat d'une mauvaise conception du code ou d'une convention de dénomination paresseuse.
• Il s'agit d'une solution de conception légitime pour des fonctionnalités sans état réutilisables dans plusieurs domaines. Veuillez noter que pour presque tous les problèmes courants, il existe des solutions existantes.

---

Exemple 1. Utilisation correcte de util classes/modules. Exemple de bibliothèque externe

Supposons que vous écriviez une application qui gère les prêts et les cartes de crédit. Les données de ces modules sont exposées par l'intermédiaire de services web dans le module json format. En théorie, vous pouvez convertir manuellement des objets en chaînes de caractères qui seront dans le format json mais cela reviendrait à réinventer la roue. La bonne solution serait d'inclure dans les deux modules une bibliothèque externe utilisée pour convertir les objets Java dans le format souhaité. (dans l'image d'exemple, j'ai montré gson )

---

Exemple 2. Utilisation correcte de util classes/modules. Écrire ses propres util sans excuses aux autres membres de l'équipe

Supposons que nous devions effectuer des calculs dans deux modules de l'application, mais que tous deux aient besoin de savoir quand il y a des jours fériés en Pologne. En théorie, il est possible d'effectuer ces calculs à l'intérieur des modules, mais il serait préférable d'extraire cette fonctionnalité dans un module distinct.

Voici un petit détail, mais qui a son importance. La classe/module que vous avez écrite ne s'appelle pas HolidayUtil mais PolishHolidayCalculator . Sur le plan fonctionnel, il s'agit d'un util mais nous avons réussi à éviter le mot générique.