Il modo migliore per separare il commercio dal Presentazione Logic?

Question

Voglio creare un gioco che funziona sia in locale che online.

Il mio primo pensiero è stato quello di creare un'interfaccia che avrebbe tutti i metodi che saranno necessari per la GUI per la logica di business e quindi avere un'implementazione di rete e l'implementazione locale.

Questo funziona bene per i messaggi di richiesta-risposta. Ma per quanto riguarda i messaggi che il server invia, in cui devo aggiornare alcuni componenti GUI (cioè JLabels)?

La mia prima soluzione a questo è stato quello di implementare gli ascoltatori, in cui ogni cambiamento nella realizzazione scatterà un evento. La GUI registrerebbe e cambiare i suoi componenti in modo appropriato. Tuttavia, le chiamate per generare gli eventi nella logica di business sembra un po 'sbagliato.

Sono nella strada giusta? Perché penso che io non sono. Qualche suggerimento?

Grazie.

. NOTA: Il client è un semplice GUI swing Java

Answer 1

Quello che avete descritto servirà l'obiettivo di mantenere il modello indipendente da problemi di presentazione, che è una buona cosa. Questo vi aiuterà anche durante la progettazione, lo sviluppo e la manutenzione del modello, perché si può scrivere unit test sulla base del fatto che alcuni cambiamenti nel modello dovrebbero generare eventi specifici, senza preoccuparsi di ciò che potrebbe apparire come su uno schermo.

E, naturalmente, si libera fino ad avere disegni diversi GUI per diversi ambienti.

La chiave è che gli eventi dovrebbero essere di circa cambiamenti nello stato del modello, e la non circa destinati azioni / rappresentazioni a livello di presentazione. Lasciate che l'affare presentazione layer con se / come rispondere a un evento di modello.

Answer 2

devo ammettere che faccio lo sviluppo del web, quindi non ho molta esperienza con Swing.

Ma ho sempre pensato che il modo in cui mi piacerebbe avvicino sarebbe di rompere l'applicazione in pacchetti / vista, / il modello, e / regolatore. I rapporti sarebbero unidirezionale: / regolatore avrebbe informato sia / modello e / vista, ma nessuno dei due sarebbe importare tutte le classi da / controller o l'altro

.

I componenti / view strato non sarebbero mai JFrames; avevano sempre essere JPanel o altro contenitore adatto che potrebbe essere composto insieme in JFrames come necessario. Ogni avrebbe riferimenti alle interfacce Listener, inizializzati nei costruttori, e sarebbe rinviare a questi per la gestione degli eventi:

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);
    }
}

Questa disposizione funziona bene con l'iniezione di dipendenza, perché ora il controllore può scegliere di utilizzare un'applicazione locale o remoto di tale interfaccia Listener, cambiare il comportamento in modo che non pregiudica il cliente a tutti.

Devo ammettere che non ho mai seguito tutto il percorso attraverso.

La gente di primavera hanno una ricca modulo client Swing, ma sembra essere caduto in disgrazia. Sembra che hanno deciso che una direzione BlazeDS è una scelta migliore per i clienti ricchi. Ma forse si può raccogliere alcune idee progettuali da loro approccio.