?
this->that schrieb:
@Optimizer: Ob es überbewertet wird oder nicht weiß ich nicht. Aber Fakt ist nun mal, dass es viele Vorteile bietet um gewisse Dinge auszudrücken und große System zu designen.
Vererbung ist ein praktisches Mittel um Hierarchien zu beschreiben. Das einzige was ich schlecht finde, sind tiefe Vererbungshierarchien wie z.B. in Java. Aber so Hierarchien der Stufe 2 oder grade noch 3 können sehr angenehm sein.
Gerade ein paar Klassenhierarchien sind viel zu "klein" für große Systeme. Klassen sind gut, wenn ich sowas wie eine Bruchrechnen-Klasse schreibe, aber von daher kann man noch lange nicht darauf schließen, wie man eine ganze Anwendung baut. Hierarchien müssen auch nicht immer was mit Vererbung zu tun haben, sondern lassen sich öfter als der Durchschnittsprogrammierer glaubt ohne Vererbung besser realisieren.
Und ich sehe schon einen kleinen Unterschied zwischen einem Handle, das im Grunde nix weiter ist als eine Zahl, und einem Objekt, das Daten und Fähigkeiten kapselt.
Ja, kann man machen wie man will. In beiden Fällen ist es noch nicht objektorientiertes Design. Es ist nur nie schlecht, sich bewusst zu machen, dass es mehrere Möglichkeiten gibt.
Dein letzter Punkt ist teils richtig, teils auch wieder nicht. Auch wenn ich eine Engine schreibe, muss ich mich mit der API auseinandersetzen. Und dann ist es doch angenehmer, wenn die API einigermaßen angenehm aufgebaut ist (und ich empfinde Klassen wie einen Buffer, der alle Buffer-Sachen kapselt, wesentlich angenehmer als hunderte globale Funktionen).
Wieder, es hat noch nichts mit Objektorientierung zu tun. D3D ist zwar sogar ein bisschen Objektorientiert, zum Beispiel weil das meiste Zeug von IUnknown erbt, aber das macht noch kein gutes objektorientiertes Design. Sachen wie IDirect3DSurface9** machen es auch nicht gerade besser. Hier denk ich mir schon manchmal, so schlimm wäre ein Handle jetzt auch nicht.
Desweiteren braucht man nicht immer gleich eine Engine. Ich habe z.B. noch nie eine Engine geschrieben - ich schreibe direkt Anwendungen auf D3D.
Eine Engine schreibst du im gewissen Sinne immer mit, ist halt die Frage, wie gut man sie weiterverwenden kann. Aber du wirst doch sicherlich zwischen dem Grafik-API und deinen Game-Objekten eine Abstraktionsschicht haben. Normalerweise gibt es die Spielwelt aus mehreren Sichten, z.B. KI-Sicht, Grafik-Sicht, Physik-Sicht, ...
Und selbst wenn man eine Engine plant dann wird die, da wirste mir mit Sicherheit zustimmen, mit sehr hoher Wahrscheinlichkeit objektorient aufgebaut sein;)
Ich würde nicht eine "ganze" Engine objektorientiert aufbauen. Natürlich verwende ich Klassen, natürlich gibt es ab und zu eine Ableitung. Das meiste ist aber nicht objektorientiert (die Verwendung von Klassen macht noch kein OO-Design), sondern Komponentenbasiert.
Vor allem im Entitätenmanagement halte ich das für die bessere Wahl. Jedes Objekt ist erstmal nur eine ID und man weiß nicht so wirklich, aus was es eigentlich besteht. Wenn ich ein Objekt dann anremple, schau ich beispielsweise nach, ob es eine Physik-Komponente für diese ID gibt und lass es vom Tisch runterfallen, oder zum Rendern hole ich mir alle Renderable-Komponenten. Da ist praktisch keine Vererbung im Spiel. Der große Vorteil davon ist, ich kann jederzeit ändern, aus was ein bestimmtes Objekt besteht und muss nicht eine riesige Hierarchie (u.U. mit Mehrfachvererbung auch noch) refactoren.