Pourquoi est-ce que je vois autant de classes instanciables sans état?

Je vois beaucoup de classes instanciables dans le monde C ++ et Java qui n'ont aucun état.

Je ne peux vraiment pas comprendre pourquoi les gens font cela, ils pourraient simplement utiliser un espace de noms avec des fonctions libres en C ++, ou une classe avec un constructeur privé et uniquement des méthodes statiques en Java.

Le seul avantage auquel je peux penser est que vous n'avez pas à modifier la plupart de votre code si vous décidez plus tard que vous souhaitez une implémentation différente dans certaines situations. Mais n'est-ce pas un cas de conception prématurée? Il pourrait être transformé en classe plus tard, quand / si cela devient approprié.

Suis-je en train de me tromper? N'est-ce pas de la POO si je ne mets pas tout dans des objets (ie des classes instanciées)? Alors pourquoi y a-t-il tant d'espaces de noms et de classes d'utilitaires dans les bibliothèques standard de C ++ et Java?

Mise à jour: J'ai certainement vu beaucoup d'exemples de cela dans mes emplois précédents, mais j'ai du mal à trouver des exemples open source, donc ce n'est peut-être pas si commun après tout. Pourtant, je me demande pourquoi les gens le font et à quel point c'est courant.

Je vois beaucoup de classes instanciables dans le monde C ++ et Java qui n'ont aucun état.

Quelques raisons possibles de créer des classes sans ivars propres:

• L'État est ou pourrait être contenu dans une superclasse.

• La classe implémente une interface et doit être instanciable pour que les instances puissent être passées à d'autres objets.

• La classe est destinée à être sous-classée.

• Manière pratique de grouper les fonctions liées. (Oui, il peut y avoir des façons meilleures ou différentes de faire de même.)

Suis-je en train de me tromper? N'est-ce pas de la POO si je ne mets pas tout dans des objets (ie des classes instanciées)?

La POO est un paradigme, pas une loi de la nature. Il y a des langues où tout est un objet, donc vous n'avez vraiment pas le choix. D'autres langages (par exemple C) ne fournissent aucun support pour la POO, mais vous pouvez toujours programmer dans un style orienté objet. Je dirais que vous pouvez avoir la POO si vous ne faites pas tout en classe ... vous pourriez dire que vous avez juste moins de POO dans ce cas.

Caleb et Robert Harvey ont déjà souligné ce que sont les classes d'utilité et certaines raisons légitimes d'avoir des classes "sans données". Ces descriptions sont parfaites, mais traitent des aspects positifs.

Je voudrais juste mentionner que l' abus des classes d'utilité peut certainement être un anti-modèle OO (voir la description de c2wiki ). Cette citation résume bien:

Un grand nombre de ces classes (en particulier celles qui n'ont qu'une seule méthode) indiquent que les concepteurs pensent à l'envers, c'est-à-dire. penser à ce qui peut être fait à un objet plutôt qu'à ce qui peut être fait par l'objet.

Si vous prétendez pratiquer la conception orientée objet, mais que votre base de code se compose presque entièrement de classes utilitaires, je dirais que vous faites définitivement quelque chose de mal. Cela dit, une approche fonctionnelle a autant de mérites et peut aussi être excellente. Ne prétendez tout simplement pas suivre l'un, tout en appliquant sans enthousiasme l'autre.

Les classes utilitaires en Java et C ++ sont utilisées pour maintenir une bibliothèque de méthodes qui acceptent un ou plusieurs paramètres d'entrée et renvoient un résultat. Ils n'ont pas besoin de conserver l'état, s'ils renvoient simplement une valeur. À cet égard, ces méthodes peuvent être considérées comme une forme brute de programmation fonctionnelle, avec tous ses avantages (pas de problème de concurrence, pour une chose).

Dans tous les cas, ces classes servent simplement à regrouper des méthodes connexes dans un seul conteneur, des méthodes qui ne nécessitent pas l'instanciation d'un objet pour fonctionner correctement. Un exemple d'une telle classe est une classe Math contenant des fonctions SINE et COSINE (et d'autres mathématiques).

Un grand nombre de ces classes interagissent avec les données, même si elles ne les contiennent pas explicitement, et doivent le faire de manière à nécessiter plusieurs instances simultanées pour être actives. Par exemple, un bean de session sans état qui interagit avec une procédure stockée de base de données, transmettant les données entrantes à un package PL / SQL et renvoyant les résultats à l'application appelante. Cette chose doit exister dans plusieurs instances, mais elle-même ne contient aucun champ de données.

Dans les langages orientés objet où les classes ne sont pas des objets, vous pouvez faire beaucoup plus avec un objet qu'avec une classe.

Vous pouvez passer un objet comme paramètre, vous pouvez remplacer un objet compatible avec le type, vous pouvez implémenter une interface (j'imagine qu'il y a des langages dans lesquels les classes sont des objets mais vous pouvez faire certaines de ces choses, mais en tout cas ...) . Toutes ces choses sont assez importantes, donc la décision par défaut est généralement de rendre une classe instanciable.

Pour certaines classes, les capacités accordées par l'instanciation semblent peu nécessaires. Vous n'aurez probablement pas besoin d'échanger une implémentation de Cosine pour une autre, par exemple. Il s'avère que ce sont principalement des fonctions utilitaires qui n'ont pas besoin de ces capacités, donc ce sont principalement des fonctions utilitaires qui ont des classes qui ne sont pas instanciables.