Tratamento de comandos ou eventos que aguardam a conclusão de uma ação posteriormente

7

Digamos que você tenha dois eventos: Ação1 e Ação2. Ao receber o Action1, você deseja armazenar alguns dados arbitrários a serem usados na próxima vez que o Action2 for lançado. Idealmente, o Action1 normalmente é um comando, mas também pode ser outros eventos. A ideia ainda é a mesma.

A maneira atual de implementar isso é armazenando o estado e simplesmente verificando quando o Action2 é chamado, se esse estado específico estiver lá. Obviamente, isso é um pouco confuso e gera muitos códigos redundantes. Aqui está um exemplo de como estou fazendo isso, na forma de pseudocódigo (e dividido bastante, obviamente):

void onAction1(event) {
    Player = event.getPlayer()
    Player.addState("my_action_to_do")
}

void onAction2(event) {
    Player = event.getPlayer()

    if not Player.hasState("my_action_to_do") {
        return
    }

    // Do something
}

Ao fazer isso para muitas outras ações, fica um pouco feio e eu queria saber se há algo que eu possa fazer para melhorar isso.

Eu estava pensando em algo assim, que não exigiria a transmissão de dados, mas isso também não é a direção certa?

void onAction1(event) {
   Player = event.getPlayer()
   Player.onAction2(new Runnable() {

       public void run() {
           // Do something
       }

   })
}

Se alguém quisesse ir ainda mais longe, você não poderia simplesmente fazer isso?

void onPlayerEnter(event) { // When they join the server
    Player = event.getPlayer()
    Player.onAction1(new Runnable() {

       public void run() {

           // Now wait for action 2
           Player.onAction2(new Runnable() {
               // Do something
           })

       }

    }, true) // TRUE would be to repeat the event,
             // not remove it after it is called.
}

Qualquer contribuição seria maravilhosa.

java events

— virulento
fonte

4

Procure o padrão Lista de ações (também fila de comandos). Em geral, porém, espere que ocorra alguma negligência; a lógica do jogo geralmente não é capaz de ser levada a padrões puros.

— Sean Middleditch

1

Eu acho que seu exemplo inicial é o mais simples. Se eu fizesse alguma coisa, teria um ActionManager central. As ações podem postar dados para que outras ações sejam coletadas posteriormente. Eu quase seria como um sistema de eventos, exceto que "Mensagens" não são entregues a uma entidade, elas simplesmente ficam sentadas, esperando uma Ação buscá-las.

Isso ajudaria a desacoplar o Action1 do Action2, de modo que, se você quisesse conectar o Action3 ao Action2, também poderia. A Action2 não sabe nem se importa com 1 ou 3, tudo o que importa é procurar uma Action2Message.

— Michael
fonte

0

É difícil encontrar uma solução sem saber como é o seu ActionListener / Handler / Manager ..

da maneira que eu faria isso (eu sou um desenvolvedor # #, mas acho que o mesmo é possível em java):

em vez de registrar o estado

Player.addState("my_action_to_do")

eu teria uma pilha de eventos ActionListeners for Action2, aos quais o evento void onAction1 () adicionaria um manipulador que será chamado se Action2 for chamado:

(vou tentar em java, talvez não seja executável):

Stack<ActionListener> onAction2Events = new ...;

void onAction1(event) {
    Player = event.getPlayer();
    onAction2Events.add(new ActionListener() {
      public void actionPerformed(ActionEvent e) { 
          // this code will be called if onAction2 is invoked
      }
    });
}

void onAction2(event) {
    Player = event.getPlayer()

    InvokeEvent(onAction2Events); // calls all ActionListeners / states that ware added

    // ...
}

void InvokeEvent(Stack<ActionListener> listenerStack) {

    while(listenerStack not empty)
    {
        listenerStack.pop().actionPerformed(...);
    }
}

— cppanda
fonte