Voici la suite de cet article.
L’exemple suivant enseigne le modèle de la Factory Method telle qu’elle est expliquée dans le Gof.
Cet exemple montre comment une pseudo-suite d’applications de bureautique peut partager du code et reporter les décisions de création à des sous-classes.
Parmi les Applications de cette suite il y a :
Naturellement pour chaque application de la suite, il y a un type de Document correspondant :
la hiérarchie de l’application ressemble à ceci :
Nous avons notre application générique abstraite ainsi que les sous-classes
EditorApplication et SpreadsheetApplication.
En effet il peut arriver d’avoir beaucoup de code en commun.
Du coup l’utilisation d’une classe parente prend tout son sens.
Pour rappel, cette classe peut être abstraite ou non si un comportement par
défaut est mis en place.
Ainsi on ne laisse que les méthodes qui se distinguent dans les sous-classes.
Mais comment s’assurer que pour chaque sous-classe d’application, le type de
Document est correctement est créé ?
Voici comment faire :
Dans la classe Application, on définit une méthode abstraite,
createDocument(), qui est chargée de s’assurer que les sous-classes créées,
ont le bon type de Document lorsqu’ils implémentent leur copie de
createDocument().
Par exemple, dans EditorApplication, l’implémentation de createDocument()
renvoie un nouveau document EditorDocument.
De même, l’implémentation de createDocument() par SpreadsheetApplication
renverra un SpreadsheetDocument.
En appliquant la puissance du polymorphisme,
nous avons veillé à ce que chaque sous-classe d’application renvoie
correctement la sous-classe Document correspondante.