Gutes OOP-Design (Dependency_Inversion_Prinzip)
Forumsregeln
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
-
- Establishment
- Beiträge: 147
- Registriert: 26.02.2009, 14:04
- Alter Benutzername: floyd
- Wohnort: Nürnberg
- Kontaktdaten:
Gutes OOP-Design (Dependency_Inversion_Prinzip)
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
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
- Moderator
- Beiträge: 1405
- Registriert: 26.02.2009, 09:42
- Echter Name: Kim Kulling
- Wohnort: Luebeck
- Kontaktdaten:
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
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.:
Deswegen Dependency-Inversion: der konkrete Killme-State hängt vom IState, also in der Hierarchie gesehen von unten nach oben ab.
Gruß Kimmi
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
-
- Establishment
- Beiträge: 147
- Registriert: 26.02.2009, 14:04
- Alter Benutzername: floyd
- Wohnort: Nürnberg
- Kontaktdaten:
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
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
- Moderator
- Beiträge: 1405
- Registriert: 26.02.2009, 09:42
- Echter Name: Kim Kulling
- Wohnort: Luebeck
- Kontaktdaten:
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
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
Gruß Kimmi
-
- Establishment
- Beiträge: 147
- Registriert: 26.02.2009, 14:04
- Alter Benutzername: floyd
- Wohnort: Nürnberg
- Kontaktdaten:
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
Das mit dem Controller klingt gut, ich werd mir das mal näher ansehen. Danke!
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
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.
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.
-
- Establishment
- Beiträge: 147
- Registriert: 26.02.2009, 14:04
- Alter Benutzername: floyd
- Wohnort: Nürnberg
- Kontaktdaten:
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
Hey, danke für die Tipps!
- Schrompf
- Moderator
- Beiträge: 4869
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
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^^°
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^^°
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
Ja das stimmt.Schrompf hat geschrieben: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.
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.
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.Tejio hat geschrieben: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^^°
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.
Zuletzt geändert von odenter am 08.02.2012, 21:46, insgesamt 1-mal geändert.
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
"Gang of 4"? Fande ich persönlich sehr sehr gut, und immernoch gut als Nachschlagewerk!Tejio hat geschrieben: Was haltet ihr von diesem Buch? => Entwurfsmuster von der Gang
- kimmi
- Moderator
- Beiträge: 1405
- Registriert: 26.02.2009, 09:42
- Echter Name: Kim Kulling
- Wohnort: Luebeck
- Kontaktdaten:
Re: Gutes OOP-Design (Dependency_Inversion_Prinzip)
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
Dazu habe ich sehr viel über Designs in fremden Lib's gelernt, sprich durch das Lesen von Sourcecode.
Gruß Kimmi