Existe uma maneira melhor do que uma sequência de IF para lidar com eventos?
-
23-09-2019 - |
Pergunta
Recentemente, encontrei vários objetos implementados para lidar com eventos com um mapeamento de codificação dura usando este padrão:
public void handleEvent(Event event)
{
if(event.getCode() == SOME_STATIC_EVENT)
doSomething(event);
if(event.getCode() == ANOTHER_STATIC_EVENT)
doSomethingElse(event);
}
onde as funções do dosomething são implementadas como métodos da mesma classe.
Na esperança de buscar o acoplamento mais frouxo, como você sugeriria abstrair esse padrão? Além disso, qual é a melhor abordagem para mapear 0..n funciona para um evento demitido?
Solução
Sim, basicamente o que você deseja fazer é criar uma estrutura de dados que mapeie um tipo de evento para uma interface. Aqui está um simples implementado como um mapa.
EventHandlerInterface h;
// eventMap contains a mapping of event codes to
// implementations of EventHandlerInterface
h = eventMap.get(event.getCode());
if(h != null)
{
h.handle(event);
}
Isso oferece a capacidade de lidar com um grande número de eventos e adicionar, remover, remover e remapar dinamicamente os eventos para diferentes manipuladores.
Outras dicas
Recentemente, houve um post SOF que era semelhante e próximo o suficiente para que minha resposta aqui Pode responder muito bem à sua pergunta.
Em vez de um executável, você faria sua própria interface:
public abstract interface EventHandler
{
public void run(Event event);
}
Você pode começar tornando o código um pouco mais limpo. Use uma variável local para tirar o repetido event.getCode()
. Mude para enumes para que você possa usar switch
.
Se houver um padrão repetido, você poderá decodificar para uma interface de retorno de chamada de vários métodos, como o AWT.
Eu sugeriria que o registro do ainda se torne mais específico. Registre um retorno de chamada diferente para cada tipo de evento. Mesmo assim, retirar o código do evento do evento e talvez remover o evento. Sob as folhas, você pode manter o código do evento para um mapeamento para os manipuladores, mas isso deve ser opaco. A desvantagem dessa abordagem é que as classes internas anônimas são atualmente (JDK6) altamente detalhadas e o manuseio de classe é ineficiente (tempos de carregamento e a pegada perm gen).