Melhor maneira de separar negócios de Apresentação Logic?

Question

Eu quero criar um jogo que vai trabalhar tanto localmente como online.

Meu primeiro pensamento foi para criar uma interface que teria todos os métodos que serão necessários pelo GUI para a lógica de negócios e, em seguida, ter uma implementação de rede e uma implementação local.

Esta multa funciona para mensagens de solicitação-resposta. Mas o que sobre as mensagens que o servidor envia, onde eu tenho que atualizar alguns componentes GUI (ou seja JLabels)?

Minha primeira solução para este foi implementar ouvintes, onde cada mudança na implementação irá disparar um evento. A GUI iria registar e alterar seus componentes adequadamente. No entanto, as chamadas para eventos de incêndio na lógica de negócio parece um pouco errado.

Am I no caminho certo? Porque eu acho que eu não sou. Alguma sugestão?

Obrigado.

NOTA:. O cliente é um simples GUI Swing Java

Answer 1

O que você descreveu servirá o objetivo de manter o modelo independente de questões de apresentação, que é uma coisa boa. Isso também irá ajudá-lo durante o projeto, desenvolvimento e manutenção do modelo, porque você pode escrever testes de unidade na base de que certas mudanças no modelo deve disparar eventos específicos, sem se preocupar com o que pode parecer em uma tela.

E, claro, ele libera-lo para ter diferentes designs GUI para diferentes ambientes.

A chave é que os eventos devem ser sobre mudanças no estado do modelo, e não sobre destinados ações / representações ao nível de apresentação. Deixe o negócio camada de apresentação com se / como responder a um evento modelo.

Answer 2

Eu vou admitir que eu faço desenvolvimento web, então eu não tenho muita experiência com Swing.

Mas eu sempre pensei que a maneira como eu abordá-lo seria quebrar o aplicativo em pacotes / vista, / modelo, e / controlador. As relações seria unidirecional:. Controller / saberia sobre tanto o modelo / e / vista, mas também não iria importar as classes de / controlador ou outro

Os componentes da camada / vista nunca seria JFrames; eles sempre estaria JPanel ou outro recipiente adequado que poderia ser composto juntos em JFrames conforme necessário. Cada um teria referências às interfaces ouvinte, inicializados em construtores, e seria adiar para estes para o tratamento de eventos:

public class ExamplePanel extends JPanel implements ActionListener
{
    private JButton button;
    private ActionListener buttonListener;

    public ExamplePanel(ActionListener buttonListener)
    {    
        this.button = new JButton("Do Something");
        this.buttonListener = buttonListener;
        this.button.addListener(this.buttonListener);
    }

    public void actionPerformed(ActionEvent e)
    {
        this.buttonListener.actionPerformed(e);
    }
}

Este arranjo funciona bem com injeção de dependência, porque agora o controlador pode optar por usar uma implementação local ou remota do que a interface Listener, mudando o comportamento de uma forma que não afeta o cliente em tudo.

Eu vou admitir que eu nunca seguiu todo o caminho.

O pessoal da Primavera tem um módulo rico cliente Swing, mas parece ter caído em desuso. Parece que eles decidiram que uma direção BlazeDS é uma escolha melhor para os clientes ricos. Mas, talvez, você pode recolher algumas idéias de projetos de sua abordagem.