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 sont mauvaises parce qu'elles signifient que vous étiez 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 alors que les cours "d'utilité publique" commencent à s'insinuer.

Answer 2

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

Bien qu'une classe utilitaire puisse violer les principes de l'OO à certains égards, elle n'est pas toujours mauvaise.

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 prend pas directement en charge cette fonction.

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

Mais le problème est que vous voulez vraiment que CHAQUE chaîne que vous utilisez 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 le cas ici. Nous voulons que notre programme soit compatible avec d'autres programmes, nous nous en tiendrons donc à std::string et créer une classe StringUtil_ (ou quelque chose comme ça).

Je dirais qu'il est préférable de s'en tenir à un util par classe. Je dirais qu'il est idiot d'avoir un util pour toutes les classes ou plusieurs utils pour une classe.

Answer 3

En y repensant aujourd'hui, je dirais que les méthodes d'extension de C# éliminent complètement le besoin de classes utilitaires. Mais tous les langages ne disposent pas d'une construction aussi géniale.

Il y a aussi le JavaScript, qui permet d'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 le C++...

Un bon code OO est assez difficile à écrire, et il est difficile à trouver car l'écriture d'un bon code OO demande beaucoup plus de temps et de connaissances que l'écriture d'un code fonctionnel décent.

Et quand on a un budget serré, le patron n'est pas toujours content de voir que l'on a passé la journée à rédiger des cours...

Answer 4

Il est très facile de qualifier quelque chose d'utilitaire simplement parce que le concepteur n'a pas trouvé d'endroit approprié pour placer le code. Il y a souvent peu de véritables "utilitaires".

En règle générale, je garde le code dans le paquet où il est utilisé pour la première fois, et je ne le remanie vers un endroit plus générique que si je découvre plus tard qu'il est vraiment nécessaire ailleurs. La seule exception est si j'ai déjà un paquetage qui exécute une fonctionnalité similaire/relative, et que le code s'y adapte le mieux.

Answer 5

Les classes utilitaires contenant des méthodes statiques sans état peuvent être utiles. Elles sont souvent très faciles à tester à l'unité.