Perché imlpement il pattern di progettazione di Command come questo?

4

Cerco di imparare il pattern di progettazione Command, so già come funziona e dove viene usato, ma sono un po 'confuso riguardo all'implementazione.

Quindi so che è necessario impostare il contesto passando l'oggetto al costruttore o come argomento alla funzione execute() . Quello che non capisco è perché abbiamo bisogno di definire tutti i comandi come classi separate e non come classi nidificate della classe su cui vogliamo eseguirle. Dal momento che abbiamo già bisogno di sapere qual è l'oggetto durante la creazione del comando (se impostiamo il contesto nel costruttore) qual è il punto di avere così tante classi separate?

Ad esempio:

Questa è l'implementazione tipica che di solito vedo ( da questo tutorial , I semplificato un po '):

public class Television {
    public void on() {
        System.out.println("TV is on");
    }
}

public interface Command {
    public void execute();
}

public class TurnTVOn implements Command {

    ElectronicDevice theDevice;

    public TurnTVOn(ElectronicDevice newDevice){
        theDevice = newDevice;
    }

    public void execute() {
        theDevice.on();
    }   
}

//somewhere in main

Television newDevice = TVRemote.getDevice();

Command onCommand = new TurnTVOn(newDevice);

onCommand.execute()

Perché non farlo in questo modo:

public interface Command {
    public void execute();
}

public class Television {
    public void on() {
        System.out.println("TV is on");
    }

    public class TurnTVOn implements Command {
        public void execute() {
            on();
        }   
    }
}

//somewhere in main

Command onCommand = TVRemote.getDevice().TurnTVOn;

onCommand.execute()

La risposta è probabilmente ovvia, ma sono un principiante e faccio domande "stupide" quando non capisco completamente qualcosa invece di limitarmi ad aiutarmi molto.

    
posta Wojtek Wencel 28.09.2018 - 01:06
fonte

1 risposta

8

What I don't understand is why do we need to define all the commands as separate classes and not as nested classes of the class we want to execute them on.

Può essere un'opzione valida, quando disponibile.
I comandi tendono ad essere accoppiati alla cosa su cui stanno operando [il ricevitore ]. Ho implementato i comandi come classi nidificate, che consentono ai comandi di avere accesso ai "privati" della classe esterna.
(Scrivo C #. Se scrivessi C ++, potrei dichiarare comandi come friend di classi su cui eseguono.)

Ma l'opzione di implementare comandi come classi nidificate in un ricevitore non è sempre disponibile. I comandi possono essere sviluppati da un gruppo diverso rispetto a quello che ha sviluppato il ricevitore. Possono o non possono avere il permesso di modificare il codice sorgente per il ricevitore, se hanno accesso ad esso.

    
risposta data 28.09.2018 - 02:12
fonte