HStev

Servus,

ich hab hier ne kleine Denkblockade, ich muss in PHP eine Implementation eines Netzwerkprotolls schreiben.

Dazu benötige ich eine Klasse mit die die Connection zum Server handelt und viele kleine Klassen die einen Befehl an den Server senden und dessen Antwort verarbeiten.

Soweit lässt sich das alles wunderbar über das Verhaltensmuster "Command" lösen.
Jetzt stellt sich mir allerdings die Frage wie ich von außen an die Antworten komme.
Wäre es sinnvoll die Befehle per Factory zu instanzieren wobei die Factory gleichzeitig die Befehle speichert als History oder soll das ganze so bleiben und die Befehle einfach nur um eine weitere Methode erweitert werden welche die Antwort des Servers zurückgibt?

Für ein paar Anregungen das vernünftig umzusetzen wäre ich dankbar.

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

Mister Ad

dr.e.

Hallo HStev,

ich würde in dieser Angelegenheit nicht krampfhaft nach einem Pattern suchen, sondern etwas mehr Pragmatismus walten lassen. Was du brauchst ist:

* Eine Basis-Implementierung, die dir den Rahmen deiner API bereitstellt
* Verschiedene Commands, die über deren API konfigurierbar sind
* Standardisierte Basis-API, mit der man zu jedem Command jeweils ein Answer ziehen kann um die Antwort auf die jeweilige Anfrage abfangen kann

Aussen drum noch ein bischen Exception- und Error-Handling und fertig.

Beispiel:
... oder wie auch immer!

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

HStev

Ja so in der Art hab ich das ja auch nur ich hab das Problem das meine Connection Klasse gleichzeitig die Command History verwaltet ... und da jedes Command die Connection im Construktor mitbekommt hab ich praktisch ein Array was immer auf sich selber zeigt ... beim Debuggen mit print_r oder var_export bekomme ich immer die Meldung das die Verschaltelung zu tief wäre.

Dazu kommt noch das die Connection Class gleichzeitig Connection Handler, Command History Container und Command Factory ist und ich denke mir das in kein gutes Entwicklungskonzept.

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

robo47

Wenn du auf ner Testumgebungs arbeitest, kannst du ja mal deinem php ein xdebug gönnen, var_dump sollte dann imstande sein solche Verschachtelungen zu erkennen und nicht in die Unendlichkeit abzudrifften.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

HStev

xdebug ist drinn nur leider versteht sich das Eclipse Debug Plugin nicht mit dem xdebug

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

phpdummi

__________________
"Nobody is as smart as everybody" - Kevin Kelly
— The best things in life aren't things

HStev

so ist es eingerichtet aber Eclipse hängt bei 19% Launching

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

dr.e.

Warum muss das so sein? Wenn das Command doch der Connection übergeben wird (siehe mein Code), muss dass doch nicht im Konstruktor passieren, sondern der abstrakte Command kann dafür mit einem setConnection() aufwarten.

Anders gesprochen: um wirklich absolut sicher zu gehen, sollte der Command nicht direkt von der Connection abhängen. So ein Design wäre im HTTP-Protokoll z.B. fatal.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

HStev

Ja ich hab das so gemacht da die Connection Klasse die grundsätzliche Kommunikation mit den Server verwaltet. Also die Klasse stellt Methoden bereit die das Command senden und die Raw Daten empfängt die wieder an das Command zurückgegeben werden wo dann die eigentliche Verarbeitung der Antwort stattfindet.

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

HStev

das must du mir noch mal genauer erläutern ich versuche grad das ganze anzupassen und erstelle mir dazu grad erstmal das UML aber mir will nicht so ganz einleuchten wozu das Comm Objekt dient ... wenn das Command die Connection bekommt sagen wir mal durch setConnection dann hängt es doch auch nicht von der Connection ab.

Das einzigste wo ich sage das es ein Fehler war ist die Command History direkt in der Connection feszuhalten.

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.