Erweitertes Kommandomuster und ekliger dynamic_cast...
-
knivil schrieb:
Naja, bei Command::execute( Context ) braeuchte man keine Henker ... aeh Executor.
Aber das ist natuerlich vom uebergeordnetem Problem abhaengig.Jo, aber das widerspricht, wie bereits gesagt, den Kommandomuster. Kommandos führen nichts aus, sondern werden ausgeführt.
-
Das sind doch nur Begrifflichkeiten aus der "realen" Welt. Dort muss es immer jemanden geben, der den Befehl ausfuehrt. Aber meist ist es nicht entscheidend, wer den Befehl ausfuehrt. Auch wuerde ich die Serialisierung, Deserialisierung und globale Verteilung der Nachrichten nicht von einem (extra) Executor machen lassen, sondern es quasi als built-in des Nachrichtensystems realisieren. Ein Executor kann ja prinzipiell nur Messages/Commands verarbeiten, jedoch keine neuen generieren oder in einen lokalen Buss einspeisen. Wenn er es doch koennen soll, dann waere er kein Henker mehr sondern eher ein Geraet, aus dem "Executor" wuerde ein "Device" (wobei das zu sehr an Technik angelehnt waere) werden.
aber das widerspricht, wie bereits gesagt, den Kommandomuster
Damit kann ich leben.
-
knivil schrieb:
Wenn er es doch koennen soll, dann waere er kein Henker mehr sondern eher ein Geraet, aus dem "Executor" wuerde ein "Device" (wobei das zu sehr an Technik angelehnt waere) werden.
Wieso das? Wer sagt denn, dass ein Ausführer nicht selbst wieder Kommandos erzeugen kann? Mal davon abgesehen, generiert der "RemoteExecutor" auch kein neues Kommando. Er verarbeitet Kommandos. Die Verarbeitung besteht in der Serialisierung und dem anschließenden Verschicken von Daten.
Weiterhin soll das "Framework" nichts davon wissen, ob es ein Netzwerk gibt, oder nicht.
Ebenso wären lokale Verbindungen über Pipes/Shared Memory denkbar. Oder auch andere Verbindungsarten. Oder auch mehrere davon parallel.
Wenn ich das alles hart ins Messagesystem rein codiere, wird das Teil immer dicker und schwerer wartbar. Wenn das Versenden aber lediglich über einen weiteren Executor geregelt wird, bleibt das ganze System sehr flexibel.
Auf der Gegenseite ist es natürlich auch kein Executor, der in den lokalen Bus einspeist, sondern eine Fabrik, die wieder konkrete Kommandos aus serialisierten Kommandos erzeugt. Als Auslöser dient hier das Ereignis des Empfangs.Inzwischen bin ich doch recht überzeugt von der Lösung.
-
Wer sagt denn, dass ein Ausführer nicht selbst wieder Kommandos erzeugen kann?
Weil ein Henker normalerweise keine neuen Verurteielten produziert (dann waere er auch Richter und Klaeger).
Wenn ich das alles hart ins Messagesystem rein codiere, wird das Teil immer dicker und schwerer wartbar.
Von hart reinkodieren sagt niemand was. Ich meine eher eine nette Schichtenarchitektur. Ganz unter: Sachen wie Pipes, Netzwerk. Mitte: Buss. Oben Geraete mit Messages.
Auf der Gegenseite ist es natürlich auch kein Executor, der in den lokalen Bus einspeist, sondern eine Fabrik, die wieder konkrete Kommandos aus serialisierten Kommandos erzeugt. Als Auslöser dient hier das Ereignis des Empfangs.
Willkommen in der Industrialisierung!
Inzwischen bin ich doch recht überzeugt von der Lösung.
Ja, sie hat schon was. Ich bin auch garnicht so abgeneigt, wie es auf den ersten Blick scheinen mag.