Resolving Inheritance Problems in Object-Oriented Design for SuperCanard

Page 1 sur 10Lecteur de document UniversityLib

Resolving Inheritance Problems in Object-Oriented Design for SuperCanard

Object-Oriented Programming and Software Design · notes

Voir tous les documents en programmation

Joël travaille pour une société qui a rencontré un énorme succès avec un jeu de

simulation de mare aux canards, SuperCanard. Le jeu affiche toutes sortes de canards

qui nagent et émettent des sons.

Les premiers concepteurs du système ont utilisé des techniques OO standard et créé

une superclasse Canard dont tous les autres types de canards héritent.

• L’an passé, la société a subi de plus en plus de pression de la part de la concurrence.

• À l’issue d’une semaine de séminaire résidentiel consacré au brainstorming et au golf, ses

dirigeants ont pensé qu’il était temps de lancer une grande innovation. Il leur faut maintenant

quelque chose de réellement impressionnant à présenter à la réunion des actionnaires qui

Publicité

aura lieu aux Baléares la semaine prochaine.

• Les dirigeants ont décidé que des canards volants étaient exactement ce qu’il fallait pour

battre la concurrence à plate couture. Naturellement, le responsable de Joël leur a dit que

celui-ci n’aurait aucun problème pour bricoler quelque chose en une semaine. “Après tout”, a-

t-il dit, “Joël est un programmeur OO... ça ne doit pas être si difficile !”

Ce qu’il prenait pour une super application de l’héritage dans un but de

réutilisation semble plus problématique quand il s’agit de maintenance

Joël a oublié que toutes les sous-classes de Canard ne doivent pas voler. Quand il a ajouté

le nouveau comportement à la superclasse Canard, il a également ajouté un comportement

qui n’était pas approprié à certaines de ses sous-classes.

Publicité

• Maintenant, il a des objets volants inanimés dans son programme SuperCanard.

• Une mise à jour locale du code a provoqué un effet de bord global (des canards en

plastique qui volent) !

Joël réfléchit à l’héritage...

Et si nous utilisions une interface ?

Joël s’est rendu compte que l’héritage n’était probablement pas la réponse : il vient de

recevoir un mémo annonçant que les dirigeants ont décidé de réactualiser le produit tous les

six mois (ils n’ont pas encore décidé comment). Il sait que les spécifications, vont changer

en permanence et qu’il va peut-être être obligé de redéfinir voler() et cancaner() pour toute

Publicité

sous-classe de Canard qui sera ajoutée au programme...

Il a donc besoin d’un moyen plus sain pour que seuls certains types de canard (mais pas

tous) puissent voler ou cancaner

Par où commencer ? Pour l’instant, en dehors des problèmes de voler() et de cancaner(), la

classe Canard fonctionne bien et ne contient rien qui semble devoir varier ou changer

fréquemment. À part quelques légères modifications, nous allons donc la laisser pratiquement

telle quelle.

• Maintenant, pour séparer les « parties qui changent de celles qui restent identiques », nous

allons créer deux ensembles de classes (totalement distinctes de Canard), l’un pour voler et

l’autre pour cancaner. Chaque ensemble de classes contiendra toutes les implémentations de

Publicité

implémente le

leur comportement respectif. Par exemple, nous aurons une classe qui

cancanement, une autre le couinement et une autre le silence.

• Nous savons que voler() et cancaner() sont les parties de la classe Canard qui varient d’un

canard à l’autre.

Pour séparer ces comportements de la classe Canard, nous extrayons ces deux méthodes de la

classe et nous créons un nouvel ensemble de classes pour représenter chaque comportement.

Implémenter les comportements des canards