spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Lose Kopplung. Stell Dir folgenden Fall vor:
Du hast eine Klasse A, die eine Datenbankverbindung aufmacht, Zeug lädt und damit irgendwas tut. Dazu erzeugt sie eine Datenbankverbindung. Nun willst Du die Klasse A testen, bzw. das, was sie mit den Daten tut. Aber natürlich willst Du für den Test keine Datenbank. Nun, was tun? Würde Klasse A nicht selbst eine Verbindung erzeugen, sondern z.B. eine Factory nach einer Verbindung fragen, könnte in deinem Test die Factory einen Mock liefern, der zwar Daten ausspuckt und so tut als wäre es eine Datenbank, aber gar keine ist. Damit sind die Tests viel einfacher zu bauen und die Klasse auch ohne Datenbank schon prima testbar.
Factories sind nicht nur für Tests praktisch, sondern auch für diverse andere Dinge. Du bist damit wesentlich flexibler, weil Du eigentlich nur ein Produkt haben willst, was sich so und so verhält. Was genau da unten drunter steckt, ist Dir eigentlich egal. Du kannst bei gutem Einsatz die Kopplung reduzieren, die Abhängigkeiten lösen oder vom Benutzer lauter Dinge verstecken, die er sonst irgendwie kennen müsste.

Zitat von »Julién«

Hat jemand einen Buchtipp wie ich den richtigen Einsatz von Designpattern lernen kann?

http://www.amazon.de/dp/0596007124/sppro-21

Welches Pattern genau meinst du? Factory Method oder Abstract Factory? Welche Beschreibung hast du bisher gelesen?

Meiner Meinung nach sind die Struktur- und Verhaltensmustser die wichtigsten, vielleicht solltest du deinen Fokus eher auf diese Schwenken.

Für das P.S, wenn es spezielle um Spieleprogrammierung geht:
http://gameprogrammingpatterns.com/contents.html

Wurde hier ja schon öfters genannt. Ist ein netter Überblick!

Der Zweck der Factory Method, wenn ich es richtig verstanden habe, ist eine Steigerung der Austauschbarkeit. Denkbar wäre beispielsweise ein Spawner, der bestimmte Objekte in einem Spiel spawnen soll. Der Spawner selbst würde sich darum kümmern, immer den richtigen Zeitpunkt für das Spawnen zu bestimmen und mit Hilfe der Factory würde er das Objekt tatsächlich erzeugen. Gerade wenn die Erzeugung komplex wird, bspw. weil einige Parameter notwendig werden, die von der Factory zwischengespeichert werden können, wäre dieses Pattern überlegenswert. (Es kann auch sein, dass kein Objekt einer abgeleiteten Klasse erzeugt wird, sondern ein Objekt mit einer bestimmten Komposition anderer Objekte.)
Der Spawner benötigt nur eine Factory, die ein "Objekt" bzw. "Spielobjekt" liefert. Die Factory kann dabei eine für "Bogenschützengegner", "leichte Kriegsschiffe" oder "Lebensenergie" sein. dem Spawner ist der konkrete Typ egal, solange es "Spielobjekte" sind, die erzeugt werden.
(Ich muss zugeben, dass es mir schwer fällt, einen Unterschied zwischen den beiden Patterns zu finden, da die Abstract Factory augenscheinlich einfach nur mehrere Produkte unterschiedlichen Basistyps liefern könnte. Entsprechend wirkt dieses Pattern für mich eher wie eine leichte Erweiterung der Factory Method.)

Abgesehen von den Entwurfsmustern gibt es ein paar Prinzipien, die vielleicht noch interessant sein könnten.
Inversion of Control bspw. besagt, dass ein Objekt sich nicht selbst um das Auflösen von Abhängigkeiten kümmern soll, sondern diese von außen zugewiesen bekommen sollte.
Ein "Component Based System" wird häufig verwendet, um "Composition over Inheritance" umzusetzen. Letzteres besagt, man solle keine unnötigen Vererbungsstrukturen erstellen, wenn auch Kompositionen verwendet werden könnten.

Wichtig ist vor allem aber abzuschätzen, wann man tatsächlich ein bestimmtes Pattern anwenden sollte und wann man darauf verzichten kann.

Blue hat es schon umfassend erklärt .

Wenn man es vielleicht vereinfacht ausdrückt: Verschiedene Implementierungen einer Schnittstelle an Hand einer Methode erstellen. Allerdings verwende ich das Pattern bei Spielen auch relativ selten.

Ein Anwendungsfall, der sich bei mir angeboten hatte, war ein Entity Component System. Es gibt eine Menge von Klassen, die von EntityComponent erben und über JSON initialisierbar sind. Dabei wird also ein Objekt speziellen Typs erstellt und immer mit einem JSON-Objekt initialisiert. Das schreit für mich nach einer EntityComponentFactory. Diese hat eine Methode EntityComponent CreateComponent(JsonData data). Das JsonData hat eine ID, die den Typ der EntityComponent erkennt und das Objekt vom richtigen Typ anlegt und dabei das JSON-Objekt übergibt. Dadurch kann man echt elegant ein Entity aus JSON mit einem foreach und der Factory erstellen:



Code habe ich jetzt frei aus dem Kopf getippt.

Ein Praxisbeispiel:
Wir hatten mal den Anwendungsfall, Daten von A nach B transportieren zu müssen, zum Beispiel Artikel, Werbung, und andere Daten, die komplexe Entitäten waren. Wir bekamen über eine Queue lediglich einen Synchronisationsauftrag mit dem Entitätentyp und den Primary Keys.
Basierend auf dem Entitätentyp mussten verschiedene Synchronisationslogiken greifen, denn ein Artikel wurde mit anderer Geschäftslogik transportiert, als eine Werbung. Insgesamt gab es ca. 12 verschiedene Implementierungen für verschiede Business Objekte.
Also gab es Factories, die abhängig vom Entitätentyp passende Implementierungen von uns definierten Interfaces ISynchronizer, IPropertyMapper, etc. zurückgeliefert hat. Eine weitere Factory hat die entsprechenden Datenbankverbindungen zurückgegeben, die basierend auf dem Auftragstyp unterschiedlich sein konnten.

Statt also einen Einstiegspunkt zu haben, der if else if else if else in 12-facher Ausführung macht, gibt dir die Factory die für deinen Fall benötigte Implementierung und die wird nur noch aufgerufen.

So kannst du, wie BlueCobold schon geschrieben hat, in Unit Tests die Queue- und Aufruflogik testen und die Factory mocken, sodass du Aufrufe auf ihr prüfen kannst, oder sie selbst Mocks der Implementierungen zurückgibt, um deren Aufrufe zu testen, usw.

Eine Factory erlaubt dir die Erzeugung von Objekten, die du zur Compile-Zeit noch gar nicht kennst - quasi wie ein Konstruktor, bei dem der Typ des zu erzeugenden Objekts ein Parameter ist.

Praktisches Beispiel aus der Spieleentwicklung: Du liest eine Level-Datei ein, in der die im Level enthaltenen Objekte beschrieben sind. Jetzt steht da in der Datei sinngemäß "erzeuge ein Objekt vom Typ 'EvilClown' an der Position 47, 11". Anstatt nun eine ellenlange Liste von Fallunterscheidungen à la "if(objectType == "EvilClown") addObject(new EvilClown());" zu verwenden (was gar nicht möglich wäre, wenn zur Laufzeit neue Typen dazukommen können, z. B. über Erweiterungen/Plugins), gibst du einfach den String "EvilClown" an eine Factory, die dir dann das Objekt erzeugt und als Zeiger auf die Basisklasse zurückliefert. Der Code, in dem der Level geladen wird, muss also gar nicht wissen, welche Objekttypen es gibt.