Bonjour,
 
Ce post traite de l'implémentation du pattern State et de son extensibilité.
 
Dans de très nombreux articles, la classe State est une interface. Dans de plus rares, elle est une classe abstraite.
 
Dans le premier cas (interface State), toutes les classes concrètes représentant un état implémentent l'interface State. Elles doivent donc impémenter toutes les méthodes de cette interface.
A cela je vois deux inconvénients :
 1. Tous les états ne réagissent pas obligatoirement à tous les événements. Un état qui ne réagit pas à un événement l'ignore.
 2. Si l'on souhaite faire évoluer la machine par l'ajout d'un nouvel événement, il faudra l'ajouter à l'interface State et donc modifier toutes les classes concrètes (qui, voir point 1., ne réagissent pas obligatoirement à ce nouvel événement).
 
Dans le deuxième cas (classe abstraite State), on pourrait envisager l'implémentation suivante :
 - Chaque événement est défini dans la classe abstraite State par une méthode, non abstraite, mais qui ne réalise rien (corps vide).
 - Chaque état (classe concrète) surcharge les méthodes correspondant aux événements auxquels elle réagit.
 
Ainsi :
 1. Dans le cas où un événement est reçu par un état qui n'est pas censé y réagir, le code de la classe abstraite State sera exécuté, ne réalisant rien (ce qui est le comportement souhaité).
 2. Dans le cas où un événement est reçu par un état qui est censé y réagir, le code de la classe concrète sera exécuté.
 3. Si l'on souhaite faire évoluer la machine par l'ajout d'un nouvel événement, il suffira d'ajouter une méthode vide à la classe abstraite et de surcharger cette méthode uniquement dans les états réagissant à cet événement. Il ne sera pas nécessaire de modifier toutes les classes concrètes.
 
 
Qu'en pensez-vous ?
Merci.

effectivement la classe abstraite semble  présenter des avantages non négligeables sur l'interface
 
 
dsl de déterrer ce topic mais bon  

J'ai l'impression qu'il n'attire pas foule