# Unterschied Command und Strategy pattern



## frager (3. Aug 2006)

hi, ich frag mich gerade, wo GENAU der unterschied liegt. im prinzip macht man doch bei command sowas:


```
interface Command{

    public void execute();
}

class Command1 implements Command{

    public void execute(){
        //....
    }
}

class Command2 implements Command{

    public void execute(){
        //....
    }
}
```


wenn ich jetzt ans klassendiagramm von strategy denke, ist das doch genau so?



```
interface MyReader{

    public void read();
}

class XMLReaderimplements MyReader{

    public void read(){
        //....
    }
}

class ZIPReader implements MyReader{

    public void read(){
        //....
    }
}
```

liegt der unterschied darin, dass in der execute methode vom command nicht die funktionalität ist? eigentlich könnte man ja aber sagen, sie ist da, denn was ich da mache, ist ja auch funktionalität?

noch ein beispiel: 


```
class Light{
    public void on(){
    }
}

class LightCommand implements Command{
   
     public LightCommand(Light light){...}
     public void execute(){
         light.on();
    }
}

//oder eben per strategy

class LightStrategy implements Strategy{
     public LightStrategy(Light light){...}
     public void switchOn(){
         light.on();
    }
}
```

ist doch das gleiche, oder? bei beiden ist wäre funktionalität vom invoker gekapselt?!


vielen dank


----------



## Anmeldeboykotierer (4. Aug 2006)

Hi,
obwohl sie einander (auf den ersten Blick) stark ähneln, verfolgen sie natürlich schon unterschiedliche Ziele. 
Beim Strategie Pattern geht es darum, dass du eine bestimmte Operation auf verschiedene Arten und Weisen ausführen kannst. Ein ganz typisches Beispiel könnten hier die Sortieralgorithmen sein. 
Du hast unterschiedliche Algorithmen, die auch bei unterschiedlich großen Mengen unterschiedlich geeignet sind. Hast du immense Datenmengen wird sich in-place wohl anbieten, natürlich arbeitet der Quicksort auch nur auf großen Menge wirklich schnell, bei einem Feld mit 2 Elementen ist Insertionsort um einiges schneller...
Jedenfalls verfolgen alle Algorithmen das gleiche Ziel, arbeiten intern aber völlig anders. Schon die verwendeten Variablen unterscheiden sich. Diese würdest du mit einem Strategie pattern einfach zusammenfassen können und die konkrete Strategie wäre leicht austauschbar.

Bei dem Command Pattern geht es darum, dass du den Aufrufer vom Aufruf entkoppelst. Dazu wird der Aufruf in einem eigenen Objekt gekapselt. 
Ein Beispiel wäre ein Button und ein Shortcut, die beide das Gleiche tun sollen. 
Würdest du am Anfang nur einen Button einplanen und hier einfach die auszuführende Aktion einfach in seiner Ereignisbehandlung implementieren, so hättest du ein Problem wenn nun ein Shortcut eingeführt wird. Soll dieser auch wie der Button reagieren, kannst du also hier nichts anderes tun als auch in dieser Ereignisbehandlung das selbe zu tun. Änderungen an der Ereignisbehandlung müssten also an allen Stellen im Code angepasst werden.
Die Lösung ist hier halt das Command Pattern. Du lagerst einfach das eigentliche Kommando aus. Auf dieses ausgelagerte Objekt haben dann alle Zugriff und Änderungen müssen nur noch an dieser Stelle vorgenommen werden. Zudem kannst du dieses Kommando Objekt noch leicht um Methoden erweitern, die den Aufruf protokollieren (was dann auch für ein Undo/Redo) verwendet werden kann.

Ich hoffe der Unterschied (der Ziele!) ist halbwegs klar. Dass die in der Implementierung einander etwas ähneln kann ja auch sein, aber das ist bei Pattern ja auch nicht ausgeschlossen, weswegen auch?

Gruß


----------



## frager (4. Aug 2006)

danke erstmal, werd mal drüber nachdenken und evtl. nochmal posten


----------



## frager (4. Aug 2006)

ich denke ich habs jetzt geschnallt. ist ja bei swing auch schon mit drinnen. wenn man eine action anlegt, kapselt diese ja auch die funktionalität und kann mehrmals verwendet werden, indem man sie mittels setaction() an einen button etc bindet. außerdem sieht das state pattern ja noch viel mehr aus wie strategy (eigentlich 100%ig)...von daher ist die ähnlichkeit wohl kein problem. ich danke dir ,  

gruß


----------



## Anmeldeboykotierer (4. Aug 2006)

Gerne wieder! Freut mich wenn ich mal helfen konnte!


----------

