Designframe - Befehlsklassen

Hallo,

ich habe ein Programm, welches Befehle entgegen nimmt. Um das möglichst einfach erweiterbar zu halten, habe ich folgende Klassenstruktur:

Command (BasisKlasse)
 CommandHello (Hello-Befehl)
 CommandList (List-Befehl)

CommandManager

Nun sieht es so aus, dass der CommandManager eine Funktion ParseCommand hat.

Dieser guckt einfach nach, ob der Befehl bereits ausgeführt wird, usw.

Command::Create()
{
if (text == "hello")
{
 return new CommandHello();
}
else if (text == "list")
{
 return new CommandList();
}
return NULL;
}

// ParseCommand

Command *cmd = Command::Create(msg);

if (!cmd)
 return false;

cmd->Execute();

// ...

Mir scheint es aber so, als wäre das Vorgehen noch nicht optimal. Wie würdet ihr das realisieren?

Ach scheisse, bin irgendwie im falschen Forum gelandet. Hatte mich wohl verlesen, sorry.

C++ Forumbot

Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C (C89 und C99) in das Forum C++ (auch C++0x und C++11) verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

cooky451

Viel zu kompliziert. Nimm einfach ein enum mit Funktionen zum Wandeln von/zu Strings und ein switch. Fertig.

knivil

cmd->Execute();

Execution in the Kingdom of Nouns

Immer wenn ich eine Klasse xxxManager nennen wuerde, habe ich das Gefuehl, dass irgendwas mit meinem Design nicht stimmt. Sachen wie execute verstaerken das noch ungemein. Meist hat sich dann eine bessere Loesung gefunden, zumindestens bei der Namensgebung.

In deinem Fall handelt es sich um eine CommandQueue . Ein andere Klasse kann das Ausfuehren der Kommandos uebernehmen (Listener). So sind Verwaltung und Ausfuehrung sauber getrennt, Producer/Consumer laesst sich auch ausserhalb von Multithreading gut verwenden ... Es kann mehrere Queues geben, manche speichern nur das zuletzt eingefuegte Element, manche nur das erste, manche Queues sind Ringbuffer ... Ueber Templates kann auch bestimmt werden, welche Kommandos sie entgegen nehmen. Designtechnisch war das immer der beste Ansatz.

Beispielsweise hier eine Queue im Einsatz bei Multithreading: http://bartoszmilewski.com/2011/11/13/c11-concurrency-series-9-condition-variables/ . Parameterisiert man noch ueber den verwendeten Container, dann koennen schoene einfache Queues fuer Message passing/commands entworfen werden, die auf den Einsatzzweck zugeschnitten sind.

PS: Wenn deine Kommandos sich so leicht kopieren lassen, dann benutze bitte kein new . Auch gibt es move-Konstruktoren. Dein Ansatz sieht mehr nach Java aus als nach C++.

Ein Commando erbt immer von meiner Thread-Klasse und lässt sich daher natürlich nicht kopieren.

Ich schaue mir den Link mal an, danke

knivil

fghfgh schrieb:

Ein Commando erbt immer von meiner Thread-Klasse und lässt sich daher natürlich nicht kopieren.

1.) Befehl und Aktion wuerde ich trennen. Ein Befehl ist kein Thread. Einige Tutorials zeigen ja, wie man von Threads erbt, aber ich halte das grundsaetzlich fuer eine schlechte Idee.
2.) Ein std::thread laesst sich moven ...
3.) Wenn du das willst, dann kannst du gleich einen std::future nehmen und std::async benutzen.

Und wenn du dir die Tutorials zum C++11 Mutlithreading ansiehst, ist es wohl besser du faengst bei Folge 1 an.