Comment abordez-vous la conception des classes dans les POO?

Lorsque j'essaie de concevoir une solution OO, j'utilise généralement la modélisation CRC dans laquelle je liste les noms de classe (noms), ce qu'ils font (verbes) et comment ils collaborent avec d'autres classes.

Ce blog a la chose ci-dessous à dire sur cette approche nom-verbe

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

Ma question est, existe-t-il une meilleure technique de modélisation pour utiliser l'approche OO?

En toute justice, il a ajouté "In fun" à cette affirmation.

À ce jour, j'ai tendance à commencer par modéliser des systèmes en utilisant l'approche «nom et verbe», mais j'ai constaté au fil des ans que TDD nous apprend que cette approche attire votre attention sur la mauvaise chose. En ce sens, le blogueur a raison. Cependant, je ne suis pas sûr que ce soit l'approche en cause, plutôt que la façon dont nos esprits fonctionnent.

Si vous voulez essayer un petit défi ici, arrêtez de lire et allez essayer de modéliser le jeu Monopoly, en utilisant la langue anglaise, puis revenez ici.

Je soupçonne que la tentation sera de regarder immédiatement les objets avec lesquels nous interagissons beaucoup - le plateau, les espaces, les cartes, les dés, les pièces - mais ce n'est pas là que va la majeure partie de la logique. La plupart de ces objets sont entièrement muets. Des données, si vous voulez.

Mais dès que vous commencez à écrire des tests, vous réalisez quel objet est de loin le plus important dans n'importe quel jeu: les règles.

Rappelez-vous ce petit morceau de papier que vous avez lu une fois lorsque vous avez obtenu le jeu pour la première fois et avec lequel vous n'interagissez plus jusqu'à ce qu'il y ait un différend? La version informatisée ne fonctionne pas de cette façon. Chaque chose que le joueur essaie de faire, un ordinateur consultera les règles et verra s'il est autorisé à le faire ou non.

Quand vous y pensez, vous faites la même chose, mais comme il faut du temps pour lire les règles sur papier et que votre cerveau dispose d'un système de mise en cache raisonnable, vous consultez les règles dans votre tête. Un ordinateur trouvera probablement aussi facile de relire les règles - à moins qu'elles ne soient stockées dans la base de données, auquel cas il pourrait également les mettre en cache.

Et c'est pourquoi TDD est si populaire pour la conception de la conduite. Parce qu'il a tendance à conduire rapidement votre processus de réflexion aux bons endroits:

Quand je pense que je vais écrire des tests pour mon jeu Monopoly. Je pourrais regarder mon ensemble et essayer de trouver les objets. Donc, nous avons ces pièces. J'écrirai quelques tests pour ceux-là.

Peut-être aurai-je une classe de base MonopolyPiece et chaque type de pièce en dérivera. Je vais commencer par le DogPiece. Premier test ... ahh. En fait, il n'y a pas de logique ici. Oui, chaque morceau sera dessiné différemment, donc je pourrais avoir besoin d'un DogDrawer, mais pendant que je développe le jeu, je veux juste écrire "D" sur l'écran. Je vais pimenter l'interface utilisateur à la fin.

Trouvons une logique réelle à tester. Il y a beaucoup de ces maisons et hôtels, mais ils n'ont pas besoin de tests. L'argent, non. Cartes de propriété, non. Etc. Même la carte n'est qu'une machine à états, elle ne contient aucune logique.

Vous constaterez rapidement qu'il vous reste trois choses en main. Les cartes Chance et Community Chest, une paire de dés et un ensemble de règles. Ce seront les éléments importants à concevoir et à tester.

Avez-vous vu cela venir lorsque vous avez écrit les noms et les verbes?

Il y a, en fait, un excellent exemple dans les modèles et pratiques des principes agiles de Robert Martin où ils essaient d'étoffer une application de carte de score de bowling en utilisant TDD et de trouver toutes sortes de choses qu'ils pensaient être des classes évidentes ne valaient pas la peine d'être dérangées.

Je n'ai jamais trouvé de telles méthodes utiles pour moi. En fait, j'ai trouvé que leur utilisation me rend encore plus confus. Découvrez la cafetière de Robert C. Martin , je ne pense pas qu'il utilise ce genre d'approche non plus.

Une chose qui me dérange tout de suite est la solution à laquelle la personne arrive dans l'article du CRC auquel vous vous connectez. La collaboration client / commande n'est pas quelque chose que je considère utile, pas comme écrit de toute façon. Il n'y a rien de particulièrement intéressant dans ce modèle concernant un client qui mérite le statut de classe. La seule chose intéressante à propos d'être un "client" est qu'il y a une ou plusieurs commandes associées à cette personne .

Le modèle collégial aussi. Il y a beaucoup de choses qui peuvent et devraient probablement être partagées entre l'étudiant et le professeur. De plus, que se passe-t-il lorsque vous avez un professeur en cours, comme cela est très souvent autorisé gratuitement sur les campus universitaires?

Je suppose que cela pourrait être une pratique valable, un élément de la boîte à outils de conception. Je ne pense pas que ce devrait être la seule façon d'aborder le design. Franchement, je trouve l'approche d'analyse des points communs / variations plus utile. Il me semble modeler de très près ce que nous faisons pour classer les abstractions au quotidien.

Edit: Il suffit de lire la moitié de ce deuxième blog et je dois dire que je suis assez d'accord avec lui. Je vais devoir lire le reste et voir ce qu'il offre en termes d'apprentissage.

Mon opinion est que les classes devraient être ajoutées (et supprimées) au fur et à mesure que vous codez pour séparer les problèmes et réduire les dépendances. La maîtrise des modèles de conception est probablement un bon pari pour voir les possibilités de refactorisation et de simplification.

Les classes en général, d'après mon expérience, ne tombent pas parfaitement dans les catégories nom / verbe, mais vous vous retrouverez plutôt avec un mélange de classes nom / verbe avec différentes classes de modèles (usines, singletons, modèles de stratégie, etc.) et d'autres classes de gestion qui traite d'un aspect de votre demande.

L'essentiel est que votre objectif soit de pouvoir regarder une classe et de déduire ce qu'elle fait et de la modifier en changeant uniquement cette classe. Plus le code d'un aspect de votre application est réparti entre les classes, plus il devient difficile de le suivre, de le gérer et de l'étendre.