Gutes OOP-Design (Dependency_Inversion_Prinzip)

[shadow]

Hallo,

inspiriert von diesem Thread: http://zfx.info/viewtopic.php?f=7&t=2146&p=28219#p28219
hab ich mir einmal folgenden Wikipedia-Artikel durchgelesen: http://de.wikipedia.org/wiki/Dependency ... on_Prinzip

Zu dem Beispiel im Wikipedia-Artikel habe ich eine Frage. Das Prinzip ist mir klar. Der Schalter ist die "mächtigere" Instanz und kann nach Anwendung des Dependency_Inversion_Prinzips jetzt über das Interface nicht nur eine Lampe, sondern beliebige Objekte an- und ausschalten. Nur wer erzeugt z. B. die Lampe? Bzw. wo ist eine Referenz zur Lampe hinterlegt?

Ich komme auf die Frage, weil ich in meinem aktuellen Spiele-Projekt mein OOP-Design verbessern möchte. Da wird dann zwischen verschiedenen Spiel-Stati hin- und hergewechselt. Wenn es ein Rollenspiel wäre kann man mit Charaktern renden (Dialog), sieht sich sein Inventar an (Inventory), oder kann seine Spielfigur durch die Welt steuern (Moving). All diese Stati (Dialog, Inventory, Moving, etc...) implementieren ein Interface IMissionState, das von einer höheren Instanz (Mission) angesprochen wird. Aber die Mission-States müssen doch irgendwo erzeugt werden, momentan bei mir in Mission, und schon ist die entkoppelung von der Detail-Implementierung wieder futsch!

Ideen?

shadow

[kimmi]

Der jeweilige Client sieht immer nur das Interface, nie die konkrete Klasse. Nun Kannst du beliebige States von der Basisklasse ableiten, ohne dass der Client diese zu Gesicht kriegt. Er sieht immer nur das Interface und weiß nichts von den Internas der reingereichten State-Instanzen, Details bleiben ihm verborgen. Die jeweiligen States erzeugst du dann beispielsweise in einer Factory, z.B.:

Code: Alles auswählen

class IState
{
   ...
   virtual void onState( Client *pClient ) = 0;
};

class KillMeState : public IState 
{
  void onState( Client *pClient ) 
  {
    pClient->release();
  }
};

class Client
{
  ...
  void onUpdateState( IState *pState )
  {
    // Client weiss nicht von der Tötungsabsicht, wenn KillMe hinein gereicht wird ^^
    pState->onState( this );
  }
};

StateFactory 
{
  IState *createKillmeState() { return new KillMeState );
}

int main( int argc, char argv )
{
  Client myClient;
  StateFactory fac;
  IState *pState = fac.createKillmeState();

  // myClient sieht nur das Interface
  myClient.onUpdateState( pState );

  return 0;
}

Deswegen Dependency-Inversion: der konkrete Killme-State hängt vom IState, also in der Hierarchie gesehen von unten nach oben ab.

Gruß Kimmi

[shadow]

Ok, soweit klar. Einziges Problem ist, dass ich das Erzeugen und evtl. auch umschalten von den States gerade auch im Klienten mache... es gibt da zwar auch ein "IState currentState", das ich immer benutze. Was da gerade dahintersteckt ist mir verborgen und das ist ja auch so gewollt. Nur ich krieg irgendwie die Trennung zwischen Erzeugen/Umschalten der States, und Klienten nicht hin...

[kimmi]

Du solltest das Erzeugen der States aus dem Klienten heraus ziehen. Der Klient darf ja von den weiteren States und der dahinter steckenden Logik ja nichts wissen. Für so etwas kann man einen Controller / Visitor nehmen ( auf die Schnelle getippt ), schau dir einfach mal die Designmuster an.

Gruß Kimmi

[shadow]

Das mit dem Controller klingt gut, ich werd mir das mal näher ansehen. Danke!

[odenter]

Ganz allgemein lassen sich auch folgende zwei Bücher empfehlen wenn Du Deine Entwürfe verbessern willst, oder vor dem Problem stehst Entwürfe anderer zu verändern
http://www.amazon.de/Head-First-Design- ... 0596007124
und
http://www.amazon.de/Head-First-Object- ... d_sim_eb_7
Die Bücher gibt es auch in deutscher Sprache.

[shadow]

Hey, danke für die Tipps!

[Schrompf]

Das "Head First Design Patterns" habe ich. Ist gut geschrieben, durchaus unterhaltsam trotz seiner anfangs penetranten Eigenwerbung. Aber wenn Du schon ne Weile beruflich programmierst, hat das Buch nicht mehr so viel Neues zu erzählen. Und es ist etwas Java-zentrisch - als C++-Programmierer hatte ich den Eindruck, dass ein Teil der Weisheiten in dem Buch ohne die Beschränkungen von Java gar nicht existieren würde.

[Tejio]

Im Hinblick auf passende Literatur zu dem Thema:

Was haltet ihr von diesem Buch? => Entwurfsmuster von der Gang

Angenehm zu lesen fand ich auch "Clean Code", "Clean Coder", "Der Termin" und "Refactoring" von Martin Fowler, aber das ist mehr offtopic^^°

[odenter]

Das "Head First Design Patterns" habe ich. Ist gut geschrieben, durchaus unterhaltsam trotz seiner anfangs penetranten Eigenwerbung. Aber wenn Du schon ne Weile beruflich programmierst, hat das Buch nicht mehr so viel Neues zu erzählen. Und es ist etwas Java-zentrisch - als C++-Programmierer hatte ich den Eindruck, dass ein Teil der Weisheiten in dem Buch ohne die Beschränkungen von Java gar nicht existieren würde.

Ja das stimmt.
Das mit den Entwurfsmustern sehe ich auch eher als Nachschlagewerk.

Als richtig gut empfinde ich das andere (Objektorientierte Analyse und Design von Kopf bis Fuß, hier noch das Link zum deutschen: http://www.amazon.de/Objektorientierte- ... 3897214954).
Gut geschrieben und gute Beispiele.
Es wird zum Beispiel aufgezeigt wie Anforderungen aufgenommen werden, umgesetzt werden und am Ende doch nicht so richtig das herauskommt was der Kunde wollte. Und was dann zu tun ist, bzw. was vorher schon zu tun ist.
Ist auch für ehrfahrenere Leute gut zu gebrauchen denke ich, mir hats jedenfalls einiges gebracht.

Im Hinblick auf passende Literatur zu dem Thema:

Was haltet ihr von diesem Buch? => Entwurfsmuster von der Gang

Angenehm zu lesen fand ich auch "Clean Code", "Clean Coder", "Der Termin" und "Refactoring" von Martin Fowler, aber das ist mehr offtopic^^°

Ich empfinde diese ganze Clean-Code-Nummer als gut. Ich habe ein paar Kollegen die reden immer noch von einem Software-Lebenszyklus, also entwickeln, pflegen dann irgendwann neu von vorne.
Diese Clean-Code-Nummer verfolgt ja eher den Ansatz immer wieder die vorhandene Software zu pflegen bzw. pflegbar zu halten, jedenfalls habe ich mir das dabei gemerkt und versuche mich halt daran zu halten.

[joggel]

Was haltet ihr von diesem Buch? => Entwurfsmuster von der Gang

"Gang of 4"? Fande ich persönlich sehr sehr gut, und immernoch gut als Nachschlagewerk!

[kimmi]

Das hier hat auch Potential, besonders, wenn man alten Code warten darf: http://www.amazon.de/Working-Effectivel ... 0131177052 .

Dazu habe ich sehr viel über Designs in fremden Lib's gelernt, sprich durch das Lesen von Sourcecode.

Gruß Kimmi