Question Les classes utilitaires sont mauvaises? [fermé]


J'ai vu ce fil

Si une classe "Utilities" est mauvaise, où puis-je mettre mon code générique?

et pensé pourquoi les classes d'utilité sont mal?

Disons que j'ai un modèle de domaine qui compte des dizaines de classes en profondeur. Je dois pouvoir xml-ify instances. Est-ce que je fais une méthode toXml sur le parent? Dois-je créer une classe d'assistance MyDomainXmlUtility.toXml? Il s’agit d’un cas où les besoins de l’entreprise couvrent l’ensemble du modèle de domaine - s’agit-il réellement d’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?


70
2017-07-27 00:55


origine


Réponses:


Les classes utilitaires ne sont pas exactement mauvaises, mais elles peuvent violer les principes qui composent un bon design orienté 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 y a des moments où vous pouvez utiliser des classes d'utilitaires pour regrouper un certain nombre de méthodes - un exemple étant la java.util.Collections class qui fournit un certain nombre d'utilitaires pouvant être utilisés sur n'importe quelle collection Java. Celles-ci ne sont pas spécifiques à un type particulier de collection, mais implémentent des algorithmes pouvant être utilisés sur n'importe quelle collection.

En réalité, ce que vous devez faire, c'est réfléchir à votre conception et déterminer où il est le plus logique de mettre les méthodes. Habituellement, il s'agit d'opérations à l'intérieur d'une classe. Cependant, parfois, il s’agit en effet d’une classe utilitaire. Lorsque vous utilisez une classe d'utilitaire, ne vous contentez pas de lui envoyer des méthodes aléatoires, organisez plutôt les méthodes par objectif et fonctionnalité.


99
2017-07-27 01:01



Je pense que le consensus général est que les classes d'utilité ne sont pas diaboliques en soi. Vous avez juste besoin de les utiliser judicieusement:

  • Concevoir les méthodes d'utilitaires statiques pour qu'elles soient générales et réutilisables. Assurez-vous qu'ils sont apatrides; c'est-à-dire aucune variable statique.

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

  • N'utilisez pas de classes utilitaires où les méthodes statiques ou d'instance d'une classe de domaine seraient une meilleure solution. Par exemple, considérons si les méthodes d'une classe de base abstraite ou d'une classe d'assistance instanciable seraient une meilleure solution.

  • Pour Java 8 et versions ultérieures, les "méthodes par défaut" dans une interface peuvent constituer une meilleure option que les classes utilitaires.


L’autre façon d’examiner cette question est de constater 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, devrais-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 pourrait mouche.

Typique "xyz c'est le mal" Les énoncés sont des dispositifs rhétoriques destinés à vous faire réfléchir en posant un point de vue extrême. Ils sont rarement (voire jamais) conçus comme des déclarations de faits littéraux.


46
2017-07-27 00:56



Les classes d'utilitaires posent problème car elles ne regroupent pas les responsabilités avec les données qui les prennent en charge.

Ils sont cependant extrêmement utiles et je les construis tout le temps en tant que structures permanentes ou en guise de tremplin lors d'un réaménagement plus approfondi.

De Code propre les classes d'utilité de perspective violent la responsabilité unique et le principe ouvert-fermé. Ils ont beaucoup de raisons de changer et ne sont pas extensibles. Ils ne devraient vraiment exister que lors du refactoring en tant que produits intermédiaires intermédiaires.


12
2017-07-27 00:59



Je suppose que ça commence à devenir méchant quand

1) Ça devient trop gros (regroupez-les simplement en catégories significatives dans ce cas).
2) Des méthodes qui ne doivent pas être des méthodes statiques sont présentes 

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


6
2017-07-27 01:02



Les classes utilitaires sont mauvaises car elles signifient que vous êtes trop paresseux pour trouver un meilleur nom pour la classe :)

Cela dit, je suis paresseux. Parfois, vous avez juste besoin de faire le travail et votre esprit est vide. C'est à ce moment-là que les classes "Utility" commencent à apparaître.


3
2017-07-27 01:41



Il est très facile de marquer quelque chose comme un utilitaire simplement parce que le concepteur ne peut pas penser à un endroit approprié pour mettre le code. Il y a souvent peu de vrais "utilitaires".

En règle générale, je garde habituellement le code dans le paquetage où il est utilisé pour la première fois, puis ne modifie que vers un endroit plus générique si je trouve que plus tard, il est vraiment nécessaire ailleurs. La seule exception est si j'ai déjà un paquet qui exécute des fonctionnalités similaires / connexes, et le code convient le mieux.


2
2017-07-27 01:00



Je ne suis pas tout à fait d'accord avec le fait que les classes d'utilité sont mauvaises.

Bien qu'une classe d'utilitaires puisse violer les principes OO à certains égards, ils ne sont pas toujours mauvais.

Par exemple, imaginez que vous souhaitiez une fonction qui nettoie une chaîne de toutes les sous-chaînes correspondant à la valeur x.

stl c ++ (pour l'instant) ne supporte pas directement cela.

Vous pouvez créer une extension polymorphe de std :: string.

Mais le problème est que voulez-vous vraiment que CHAQUE chaîne utilisée dans votre projet soit votre classe de chaîne étendue?

Il y a des moments où OO n'a pas vraiment de sens, et c'est l'un d'entre eux. Nous voulons que notre programme soit compatible avec les autres programmes, nous allons donc nous en tenir à std :: string et créer une classe StringUtil_ (ou quelque chose).

Je dirais que c'est mieux si vous restez avec un utilitaire par classe. Je dirais que c'est idiot d'avoir un utilitaire pour toutes les classes ou de nombreux utils pour une classe.


2
2018-06-09 13:15



Les classes d'utilitaires contenant des méthodes statiques sans état peuvent être utiles. Celles-ci sont souvent très faciles à tester.


1
2017-07-27 03:44



Avec Java 8, vous pouvez utiliser des méthodes statiques dans les interfaces ... problème résolu.


1
2018-04-12 12:20



En regardant cette question maintenant, je dirais que les méthodes d'extension C # détruisent complètement le besoin de classes utilitaires. Mais toutes les langues n'ont pas une construction aussi géniale.

Vous avez également JavaScript, où vous pouvez simplement ajouter une nouvelle fonction directement à l'objet existant.

Mais je ne suis pas sûr qu'il y ait vraiment une manière élégante de résoudre ce problème dans un langage plus ancien comme C ++ ...

Le bon code OO est assez difficile à écrire et difficile à trouver, car écrire Good OO nécessite beaucoup plus de temps / de connaissances que l'écriture d'un code fonctionnel décent.

Et quand vous êtes sur un budget, votre patron n'est pas toujours content de vous voir passer toute la journée à écrire un tas de cours ...


1
2017-07-21 21:19