Idées d'exercices pour la section 6.5

[Olon11]

J'ai plusieurs idées d'exercices pour les patrons GRASP. Si tu es intéressé, je peux en préparer quelques uns avec les réponses.

[fuhrmanator]

Oui, on est intéressé! Fais un pull request. Tu peux installer Quarto (quarto.org) - il n'est pas nécessaire d'avoir LaTeX si tu veux juste faire un "preview" du résultat en HTML.

[Olon11]

Il manque des exercices pour créateur, faible couplage et protection des variations. Je vais réfléchir à cela.

[fuhrmanator]

Créateur : je sais que la tendance est de faire un créateur lorsqu'on a besoin d'une instance (cowboy hacking). P-e un scénario où il y a un petit MDD simple, un code simple où on fait new X() mais ça ne respecte pas créateur. et il faut expliquer les risques sur le plan de conception, et de proposer une solution respectant créateur et pourquoi c'est mieux. Sinon, on peut faire la même chose avec un diagramme de séquence (comme dans une RDCU pour pratiquer les diagrammes, malgré que les RDCU viennent après).

Faible couplage : est un effet secondaire de forte cohésion. P-e reprendre les exemples d'amélioration de cohésion (contrôleur, fabrique) et expliquer pourquoi il y a moins de couplage. Larman donne 1 ou 2 exemples où on a plusieurs possibilités d'un créateur (selon GRASP) et on les évalue sur le plan du couplage. Créateur est bien puisqu'on a 5 possibilités. La raison qu'on favorise la relation d'agrégation est justement que le couplage est plus faible (selon moi en tout cas).

Protection des variations a plusieurs variantes que je trouve intéressantes - le mécanisme des CSS (ou n'importe quelles feuilles de style), l'architecture REST (HATEOAS), la réflexivité (Java), les DSL (conception pilotée par interpréteur), les langages standard (SQL, qui a commencé comme un DSL). Larman donne toute une explication dans le chapitre F22 et il y a de quoi pour faire un exercice plus "théorique".

[Olon11]

Ce sont des bonnes idées. Je vais aussi regarder des travaux étudiants pour identifier les mauvaises pratiques.

[Olon11]

Voici d'autres idées d'exercices.

• Faible couplage, forte cohésion, fabrication pure et protection des variations: Interagir avec un système ou une bibliothèque de code (ex.: API Maps, Météo, SGB, etc.) via une façade. La façade est une fabrication pure et permet de réduire le couplage et la cohésion de la classe qui en a besoin. Utile pour le laboratoire.

• Faible couplage et polymorphisme : Utiliser le polymorphisme pour regrouper plusieurs classes indépendantes afin réduire le couplage.

• Forte cohésion, expert en information: Refactoriser un contrôleur qui converti lui-même un objet d'une classe en JSON. Ajouter une méthode de conversion (ex.: toJSON) dans la classe. Utile pour le laboratoire.

• Faible couplage et haute cohésion : Utiliser l'inversion de dépendances (sans nécessairement nommer ce concept) pour augmenter la cohésion et réduire le couplage. Ex.: https://martinfowler.com/articles/injection.html

• Forte cohésion et expert en information : Une contrôleur qui valide lui-même les propriétés d'une classe conceptuelle. Il faut refactoriser pour le classe conceptuelle se valide elle-même. Utile pour le laboratoire.

[Olon11]

Créateur : je sais que la tendance est de faire un créateur lorsqu'on a besoin d'une instance (cowboy hacking). P-e un scénario où il y a un petit MDD simple, un code simple où on fait new X() mais ça ne respecte pas créateur. et il faut expliquer les risques sur le plan de conception, et de proposer une solution respectant créateur et pourquoi c'est mieux. Sinon, on peut faire la même chose avec un diagramme de séquence (comme dans une RDCU pour pratiquer les diagrammes, malgré que les RDCU viennent après).

Si on prend en exemple le jeu de Monopoly. Selon Créateur, il est préférable que ce soit le Plateau qui créée les cases, car Plateau agrège Case. Donc, on donne le nom de la case à Plateau et il crée les instances. Ça fonctionne bien, car l'objet qui crée Plateau n'a pas de couplage avec Case.

Par contre, ce n'est pas approprié dans tous les cas. Par exemple, en GTI311, les étudiants ont à modifier des fichiers audio à l'aide de filtres. Par contre, on ne veut pas que ce soit les filtres qui créent les fichiers audio à partir du chemin vers le fichier, car cela empêche de tester les filtres avec des tests unitaires. C'est une fabrique (patron monteur et fabrique) qui s'occupe de créer les fichiers fichier audio. Dans les tests unitaires, on utilise un mock créé en mémoire. Donc, on favorise plutôt « B a les données pour initialiser A » (la fabrique a les données [le chemin vers le fichier] pour initialiser le fichier audio).

Je souhaite éviter de présenter un dogme aux étudiants (l'agrégation est toujours meilleure), mais ça me semble compliqué d'expliquer ces subtilités aux étudiants.