Entwurf von Kommando-Klassen

[samosa]

Hi,

ich würde mir mal gerne Eure Meinung zu folgendem Design hören. Ich verwende dazu ein vereinfachendes Beispiel.

Ich habe eine abstrakte Klasse

Command

, die ein Kommando mit Optionen realisiert.

abstract class Command {

    String options;

    Command(String options) {
        // mach was gescheites
    }

    abstract void execute();

    // weitere Methoden
}

Jede Unterklasse ist ein konkretes Kommando mit konkreten Optionen. Als konkrete Kommandos kann man sich beispielsweise Unix Kommandos wie

ls, cp, rm

usw vorstellen, die jeweils verschiedene Optionen besitzen. Beispiel:

class Remove extends Command {

    Remove(String options) {
         super(options);
         // ...
    }

    void execute() {
        // führt rm mit gesetzten Optionen aus
    }

}

In einer Anwendung

App

wähle ich dann das gewünschte Kommando, setze die Optionen, die ich gerade brauche und lass dann das Kommando ausführen. Mal rufe ich in der Klasse

App

das eine mal das andere Kommando mit jeweils unterschiedlichen Optionen auf.

Was mich stört ist, dass ich in der Klasse

App

stets mitten im Code rumschreiben muss. Ich muss also die Zeile

Command c = new Remove(options)

immer mit dem passenden Kommando belegen. Im Grunde ist ja das Kommando selbst eine Option und kann dann zusammen mit den anderen Optionen übergeben werden.

Man könnte doch eine enum-Klasse

CommandType

implementieren, deren Konstanten den realisierten Kommandoklassen entspricht. Dann könnte man eine Klasse

CommandSelector

implementieren, die statische Methoden der folgenden Bauart besitzen:

// Typ des Kommandos und options separat
static Command select(CommandType type, String options);

// Typ des Kommandos in options:
static Command select(String options);

Hierbei wird das im

typ

bzw

options

spezifizierte Kommando-Objekt zurückgeliefert.

Macht man das so? Oder wie würdet Ihr das machen?


Beste Grüße

samosa

 

[Marco13]

Das letzte klang jetzt, als würde das "schöne" Command pattern - Wikipedia, the free encyclopedia durch ein anti-objektorientiertes Gemisch aus static+switch ad absurdum geführt, aber so ganz hab' ich's wohl nicht verstanden: Was meinst du mit
Was mich stört ist, dass ich in der Klasse App stets mitten im Code rumschreiben muss.
?!

 

[samosa]

Das letzte klang jetzt, als würde das "schöne" Command pattern - Wikipedia, the free encyclopedia durch ein anti-objektorientiertes Gemisch aus static+switch ad absurdum geführt, aber so ganz hab' ich's wohl nicht verstanden: Was meinst du mit
Was mich stört ist, dass ich in der Klasse App stets mitten im Code rumschreiben muss.
?!

Ich muss mich erst einmal durch das Command-Pattern durcharbeiten. Aber Deine Frage kann ich schon mal beantworten: Wenn ich in der Klasse

App

ein Kommando ausführen möchte, habe ich eine feste Stelle um die Optionen für dieses Kommando festzulegen. Ich würde gerne das gewählte Kommando ebenfalls als Option an der zentralen Stelle festlegen und vermeiden, dass ich zu einer andere Stelle der Klasse

App

scrollen muss, um

new Remove(), new Sonstwas()

zu schreiben.

EDIT: Beispiel, wir haben das Kommandozeilenargument

commandname opt0 val0 opt1 val1 opt3 val3

Dann sollte aus dem Kommandonamen das entsprechende Kommando-Objekt erzeugt werden.

 

[Marco13]

So ganz check ich's immer noch nicht, aber sowas wie eine Factory könnte eine Alternative zu den static-Methoden sein. Schreib' vielleicht mal anskiziert sowas wie

// So ist es:
... new XCommand()...


// So soll es sein
...doit();...

 

[samosa]

Habe mir mal das factory pattern angeschaut. Wenn ich das richtig verstanden habe ist ja die Klasse

CommandSelector

die Factory und

select()

das

doit()

?

 

[Marco13]

Vielleicht - nur eben nicht static. Aber solange das Problem nicht klar ist, kann man lange über lösungen spekulieren.

 

[samosa]

ok danke für deine hilfe.