Wie schreibe ich solide Pure Aggregation (Komposition) Spielobjekte in Java?
Ich schreibe gerade erst ein Spiel auf Java und schreibe meine Spielobjekte. Jetzt habe ich hier in Evolve Your Hierarchy gelesen, dass Sie Ihre Spiele als Kompositionen erstellen sollten und nicht als eine große Klassenhierarchie. Wie dieses Bild vom vorherigen Link zeigt:
Wenn ich jedoch zur Implementierung übergehe, habe ich eine kleine Frage, wo ich die Schnittstellen anwenden soll.
Nehmen wir an, Sie haben eine Klasse namens Player und die Interfaces Moveable und Renderable. Implementieren Sie dies mithilfe von öffentlichen Schnittstellenvariablen:
%Vor%Oder versuchen Sie dies, indem Sie die Schnittstellen direkt auf das Objekt anwenden:
%Vor%Jetzt fühle ich, dass die zweite Methode besser ist. Der Hauptgrund dafür ist, dass ich die folgenden Listen erstellen kann:
%Vor%Ich will nur bestätigen, dass ich auf dem richtigen Weg bin. Ich bin mir ziemlich sicher, dass Sie bei der Erstellung von Spielobjekten durch Komposition für Spiele in Java die Schnittstellen direkt auf das fragliche Spielobjekt anwenden und dann private Schnittstellen verwenden möchten, wenn Sie sie benötigen, und Implementierungen dieser Funktionen für den Rest ausführen. Ist das richtig? Und was sind die positiven und negativen Aspekte dessen, was ich tue?
Worauf muss ich bei der Implementierung von Compositional Game Objects in Java noch achten, während wir hier sind? Was soll ich anders machen? Danke für alle Antworten im Voraus, ich schätze jede Hilfe.
2 Antworten
Das ist ein interessanter Link. Ich nehme an, was Sie für Ihre Player -Klasse im Sinn haben, ist, was dieser Artikel einen Komponentencontainer aufruft. Das Anwenden der Interfaces auf die Klasse klingt für mich wie die Art zu gehen. Es ist der einzige Weg, der Sie zu einer reinen Aggregationsstruktur führt (wo es in Ihrem System nicht mehr eine Player class pro se gibt.
Übrigens ist die Struktur, die Sie vorschlagen, im Grunde eine Anwendung des Entwurfsmusters für Delegationen . Ein Player setzt Delegaten auf ein Movement -Objekt für alle Bewegungsoperationen und es ist egal, mit welcher Art von Movement -Objekt es arbeiten soll.
Ich habe ein paar Spiele mit Java erstellt und habe auch die Quelle für ein paar sehr gute Spiele gesehen und es scheint die gebräuchlichste Art dies zu tun mit der zweiten Methode. Von dem, was ich sagen kann, ist der beste Grund, die zweite Methode zu verwenden, weil es einfacher wird, Ihre Objekte mithilfe von Listen zu verfolgen und es Ihnen ermöglicht, mit weniger Zeilen zu zeichnen. Es scheint, dass Sie auf dem richtigen Weg sind und der Artikel "Evolve Your Hierarchy" ist eine großartige Lektüre für neue Spieleentwickler.
Tags und Links java interface composition game-engine