Y at-il une meilleure façon qu'une séquence de cas est de 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 mise en correspondance 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 des méthodes de la même classe.

Dans l'espoir de l'effort pour le couplage plus lâche, comment suggérez-vous abstraire ce modèle? De plus, quelle est la meilleure approche pour les fonctions de 0..n de cartographie à un événement tiré?

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 une simple mise en œuvre comme une 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 les événements remapper à différents gestionnaires.

Answer 2

Il y avait récemment un poste de SOF qui était assez semblable et proche que ma réponse ici peut répondre à votre question tout à fait bien.

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 faire le code un peu plus propre. Utilisez une variable locale pour prendre le event.getCode() répété. Passer à énumérations afin que vous puissiez 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. Enregistrer un rappel différent pour chaque type d'événement. Même jusqu'à prendre le code d'événement de l'événement, et peut-être retirer 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).