Existe-t-il une meilleure façon qu'une séquence de si pour gérer les événements?

Question

J'ai récemment couru à travers plusieurs objets mis en œuvre pour gérer les événements avec une cartographie codée en dur utilisant ce modèle:

public void handleEvent(Event event) 
{ 
    if(event.getCode() == SOME_STATIC_EVENT) 
     doSomething(event); 
    if(event.getCode() == ANOTHER_STATIC_EVENT) 
     doSomethingElse(event); 
} 

où les fonctions DoSomething sont mises en œuvre en tant que méthodes de la même classe.

Dans l'espoir de viser un couplage plus lâche, comment suggéreriez-vous d'extraire ce modèle? Aussi, quelle est la meilleure approche pour mapper des fonctions 0..N à un événement déclenché?

Answer 1

Oui, au fond ce que vous voulez faire est de créer une structure de données qui mappe un type d'événement à une interface. Voici un simple implémenté sous forme de carte.

EventHandlerInterface h; 
// eventMap contains a mapping of event codes to 
// implementations of EventHandlerInterface 
h = eventMap.get(event.getCode()); 
if(h != null) 
{ 
    h.handle(event); 
} 

Cela vous donne la possibilité de gérer efficacement un grand nombre d'événements et d'ajouter dynamiquement, supprimer et remapper événements à différents gestionnaires.

Answer 2

Il y avait récemment un poste SOF qui était similaire et assez proche que ma réponse here peut très bien répondre à votre question.

Au lieu d'un runnable, vous feriez votre propre interface:

public abstract interface EventHandler 
{ 
    public void run(Event event); 
} 

Answer 3

Vous pouvez commencer par rendre le code un peu plus propre. Utilisez une variable locale pour supprimer les répétitions event.getCode(). Passez à enums pour pouvoir utiliser switch.

S'il y a un motif répété, vous pouvez décoder à une interface de rappel de la méthode multiple, comme le fait AWT.

Je suggère que l'enregistrement de la même devient plus spécifique. Enregistrez un rappel différent pour chaque type d'événement. Même en supprimant le code d'événement de l'événement, et peut-être en supprimant l'événement. Sous les draps, vous pouvez garder le code d'événement pour un mappage de gestionnaires, mais cela ne devrait être opaque. L'inconvénient de cette approche est que les classes internes anonymes sont actuellement (JDK6) très bavard et la gestion de classe est inefficace (les temps de chargement et perm gen empreinte).