Patrons de conception/Patron de méthode
La technique du patron de méthode est un patron de conception comportemental utilisé en génie logiciel.
Un patron de méthode définit le squelette d'un algorithme à l'aide d'opérations "abstraites" dont le comportement concret se trouvera dans les sous-classes, qui implémenteront ces opérations.
Cette technique, très répandue dans les classes abstraites, permet de:
La technique du patron de méthode a ceci de particulier que c'est la méthode de la classe parent qui appelle des opérations n'existant que dans les sous-classes.
C'est une pratique courante dans les classes abstraites, alors que d'habitude dans une hiérarchie de classes concrètes c'est le contraire : ce sont plutôt les méthodes des sous-classes qui appellent les méthodes de la super-classe comme morceau de leur propre comportement.
L'implémentation d'un patron de méthode est parfois appelée méthode socle parce qu'elle ancre solidement un comportement qui s'applique alors à toute la hiérarchie de classes par héritage.
Pour s'assurer que ce comportement ne sera pas redéfini arbitrairement dans les sous-classes, on déclare la méthode socle final en Java, ou bien non virtuelle en C++.
Les méthodes servant de "briques de comportement" à la méthode "socle" devraient être déclarées abstract en Java, ou bien virtuelles pures en C++.
Diagramme UML.
Le patron de conception Patron de méthode peut être représenté par le diagramme de classes UML suivant :
La méthode codice_1 appelle les méthodes abtraites ou concrètes.
Les méthodes abstraites sont implémentées par les classes dérivées.
Les méthodes concrètes peuvent être redéfinies par les classes dérivées (comportement différent de celui par défaut).
Exemples.
Java.
/**
 * Classe abstraite servant de base commune à divers
 * jeux de société où les joueurs jouent chacun leur tour.
abstract class JeuDeSociété
 protected int nombreDeJoueurs;
 abstract void initialiserLeJeu();
 abstract void faireJouer(int joueur);
 abstract boolean partieTerminée();
 abstract void proclamerLeVainqueur();
 /* Une méthode socle : */
 final void jouerUnePartie(int nombreDeJoueurs)
 this.nombreDeJoueurs = nombreDeJoueurs;
 initialiserLeJeu();
 // Premier joueur :
 int j = 0;
 while( ! partieTerminée() )
 faireJouer( j );
 // Joueur suivant :
 j = (j + 1) % nombreDeJoueurs;
 proclamerLeVainqueur();
On peut maintenant dériver cette classe pour implanter divers jeux :
class Monopoly extends JeuDeSociété
 /* Implémentation concrète des méthodes nécessaires */
 void initialiserLeJeu()
 // distribuer les billets, placer les pions, ...
 void faireJouer(int joueur)
 // lancer le dé, avancer, action selon la case d'arrivée...
 boolean partieTerminée()
 // il y a un joueur ruiné ou nombre de tours prédéfini écoulé, ...
 void proclamerLeVainqueur()
 // ...
 /* Déclaration des composants spécifiques au jeu du Monopoly */
 // Pions, cases, cartes, billets, ...
class Echecs extends JeuDeSociété
 /* Implémentation concrète des méthodes nécessaires */
 void initialiserLeJeu()
 // Placer les pions sur l'échiquier, ...
 void faireJouer(int joueur)
 // Choisir une pièce, l'avancer, prise ou promotion, ...
 boolean partieTerminée()
 // Échec et mat ou abandon, ...
 void proclamerLeVainqueur()
 // ...
 /* Déclaration des composants spécifiques au jeu d'échecs */
 // Pions et échiquier, ...
La technique du patron de méthode fixe un cadre pour toutes les sous-classes.
Cela implique certaines restrictions : dans l'exemple ci-dessus, on ne peut pas faire hériter une classe codice_2 de la classe abstraite codice_3, parce que dans une partie de Tarot, l'ordre des joueurs n'est pas linéaire : il dépend du joueur qui vient de ramasser le pli.
On peut décider de ne pas déclarer la méthode socle comme "final" en Java (ou bien décider de la déclarer "virtual" en C++), afin de la rendre plus souple.
Ainsi la classe codice_2 pourrait parfaitement hériter de la classe codice_3, à condition de redéfinir la méthode codice_6 pour tenir compte des règles du Tarot.
Mais cette pratique est critiquable.
Il est important de se poser la question dès l'écriture de la super-classe : "Les sous-classes auront-elles le droit de redéfinir les comportements fondamentaux codés dans la super-classe ?".
L'avantage est bien sûr une souplesse accrue.
L'inconvénient peut être la perte de la cohérence interne de l'objet, si la surcharge des méthodes socles est mal conçue.
Pour reprendre l'exemple précédent, on pourrait mettre en place une méthode qui retourne le prochain joueur, qui serait implémentée différemment dans la classe codice_2 et dans une classe d'un jeu où chaque joueur joue successivement.

Patrons de conception/Visiteur
Un visiteur est le nom d'une des structures de patron de conception comportemental.
Le "visiteur" est une manière de séparer un algorithme d'une structure de données.
Un visiteur possède une méthode par type d'objet traité.
Pour ajouter un nouveau traitement, il suffit de créer une nouvelle classe dérivée de la classe Visiteur.
On n'a donc pas besoin de modifier la structure des objets traités, contrairement à ce qu'il aurait été obligatoire de faire si on avait implémenté les traitements comme des méthodes de ces objets.
L'avantage du patron visiteur est qu'un visiteur peut avoir un état.
Ce qui signifie que le traitement d'un type d'objet peut différer en fonction de traitements précédents.
Par exemple, un visiteur affichant une structure arborescente peut présenter les nœuds de l'arbre de manière lisible en utilisant une indentation dont le niveau est stocké comme valeur d'état du visiteur.
Exemples.
C++.
Prenons une classe codice_1, de laquelle hériteront codice_2, elles posséderont la méthode codice_3.
void ObjetDeType1::accept( Visitor * v )
 v->visitObjetDeType1( this );
Créons la classe codice_4, dont hériteront codice_5 et codice_6.
Dans chacun de ces objets, on retrouvera une méthode codice_7, codice_8 et codice_9.
void MonVisiteur::visitObjetDeType1( ObjetDeType1 * objet )
 // Traitement d'un objet de type 1

void MonVisiteur::visitObjetDeType2( ObjetDeType2 * objet )
 // Traitement d'un objet de type 2