O encadeamento de eventos é considerado uma boa prática?

15

De tempos em tempos, encontrei cenários em que várias condições complexas precisam ser atendidas antes do desencadeamento de um evento. Além disso, a maioria dos ouvintes também executa verificações adicionais para determinar o curso da ação. Isso me fez pensar se uma solução melhor seria pensar em termos de eventos menores e permitir que eles disparassem um dentro do outro.

Eventos de encadeamento me permitiriam tecer mais ouvintes adicionais posteriormente com um esforço bastante baixo (possível violação do YAGNI?). Meu código consistiria em elementos simples e fáceis de entender, o que não deve ser difícil para os outros entenderem.

No entanto, as possíveis desvantagens dessa solução seriam o fato de que algo acontecesse de errado na cadeia (por exemplo, acionamento de evento falso devido a erro humano), seria muito difícil detectar o bug.

É evento acorrentar uma boa idéia ^TM ? Caso contrário, quais são os métodos alternativos para manter o código relacionado a eventos desorganizado?

event-programming

— dourar
fonte

1

Eu tenho trabalhado nos últimos dois anos em uma biblioteca de encadeamento de eventos para JavaScript. kayoub5.github.io/onQuery permite gravar eventos complexos como <br> (A ou B) e depois C e (D e E) como {A + B} > C > {D & E}<br>. Com certeza ajuda a escrever soluções complexas em menos tempo, mas como mencionado anteriormente, teste e depuração ainda são uma dor.

— precisa saber é o seguinte

11

O encadeamento de eventos é uma boa ideia?

É uma daquelas coisas que parece realmente uma boa ideia, até você usá-la.

É muito difícil configurar eventos em cascata sem algum tipo de dependência implícita na ordem. É difícil configurá-los sem causar problemas devido a loops infinitos e vazamentos ocasionais de memória. Eles tornam o design da classe mais difícil devido ao acoplamento causado por eventos que precisam saber onde anexar e onde fazer cascata.

E eles são super difíceis de depurar e raciocinar sobre código.

Agora, às vezes, eles podem ser usados em cenários relativamente limitados, onde a estrutura do código limita alguns desses problemas. Nas UIs, os eventos em cascata podem ser usados para acionar a hierarquia, porque essa estrutura hierárquica ajuda a limitar a propriedade e as preocupações de loop.

Ainda assim, vejo com muito mais frequência hoje em dia que aceito um delegado em um construtor para esse tipo de comportamento extensível do que permitir que o comportamento arbitrário se prenda no tempo de execução.

— Telastyn
fonte

Alguns pontos importantes, especialmente o das hierarquias da interface do usuário.

— 21712 Vaughandroid

2

O encadeamento de eventos é uma boa ideia se

Geralmente é apropriado ao seu cenário. Um exemplo simples é a ação da interface do usuário do usuário que aciona outros eventos visuais.
Cada evento é independente e gerenciável. Você não quer que a solução se torne excessivamente pesada.
O fluxo de controle é fácil de seguir. Ele precisa ser implementado em uma plataforma e em um idioma fácil para o desenvolvedor percorrer. Se você precisar rastrear métodos "mágicos" para rastrear o que está acontecendo, estará seguindo o caminho errado.

É muito importante pensar na solução e generalizar algumas coisas antes de começar a construir o sistema. Por exemplo, em uma linguagem OO, você deve ter uma interface básica ou classe abstrata como base para todos os eventos. Essa classe deve incorporar coisas como log / depuração. Você também pode querer uma classe de gerenciamento de eventos generalizada para lidar com falhas normalmente.

— Matt S
fonte

2

Falando do ponto de vista de alguém que já passou alguns dias rastreando um erro relacionado à cadeia de eventos, essa é uma péssima idéia (sm). Você está ocultando seu fluxo de controle que (como você observou) pode tornar a depuração um pesadelo. A situação em que eu estava surgiu quando alguém adicionou um código de tratamento de erros que redefinia um controle. Isso levou a uma cadeia de onPropertyChangemanipuladores que acabou atualizando o controle com o manipulador de erros, o que levou a redefinir o outro controle novamente e assim por diante. Basicamente, a interface do usuário simplesmente trava com a CPU atrelada a 100%.

Se você tiver alguma maneira de impedir que os manipuladores de eventos sejam acionados mais de uma vez para o mesmo evento raiz, poderá evitar isso, mas posso imaginar situações em que você pode querer várias invocações de manipuladores de eventos.

— TMN
fonte

1

Isso soa como um problema com uma implementação específica, não com o conceito em geral.

— 18712 Matt Smith S

Eu acho que o problema com o fluxo de controle não determinístico é inerente ao design. A menos que você codifique fluxos muito específicos e não use um mecanismo de pub / subtipo de uso geral.

— TMN

2

Implementar bem o encadeamento de eventos é difícil, por todos os motivos mencionados por outros.

No entanto, também é a premissa básica da maioria dos mecanismos de regras. O JBoss Drools, o IBM jRules, o PegaSystems, o Corticon e o FICO Blaze Advisor são todos os principais BRMS (Business Rules Management Systems) que permitem aos usuários declarar regras que disparam com base nos eventos que ocorrem nos sistemas. O encadeamento para frente e para trás é possível e factível.

A linguagem Prolog e seus derivados são baseados na mesma noção.

Os algoritmos envolvidos não são simples, a depuração PODE ser uma dor, mas há muito valor a ser encontrado no modelo.

— Matthew Flynn
fonte

1

Uma desvantagem potencial é que é muito fácil acabar acidentalmente com atualizações em loop. por exemplo, A -> B -> C -> A -> B ...

Outra abordagem é criar eventos compostos responsáveis por disparar uma sequência de eventos. Isso significa que você não deve ficar preso em um loop e oferece um único local para detectar erros / etc. Eu tive algum sucesso com isso, embora, reconhecidamente, ainda não o tenha usado para algo particularmente complicado (ainda!).

— vaughandroid
fonte