spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo!

Gerade habe ich diesen elends langen Beitrag geschrieben und als ich dann auf absenden klickte, war ich plötzlich ausgeloggt und alles war umsonst Also nochmal...

Ich erstelle gerade eine Framework, die verschiedene Objekte (Linkable) miteinander verlinkt (Mittels einer Link Klasse, die zwischen dem active-partner und dem passive-partner unterscheidet). Ein Linkable kann darüber auskunft geben ob und mit wem es verlinkt ist, sowie welcher Link.Typ (enum) dabei verwendet wurde. Das besondere daran ist jetzt die Verwendung von Conditions, die diese Links selbständig verwalten. Diese Conditions werden von Triggern (Die gegebenenfalls verschiedene Informationen liefern können) angestoßen, woraufhin die Condition die ihr zugeordneten Links und Linkables überprüft - mit einer eigenen Condition.check(Linkable active, Linkable passive) methode - und löscht daraufhin Links bzw erstellt neue.

Das Ganze habe ich bereits programmiert und es funktioniert auch, nur finde ich, dass ich das Ganze sehr unschön gelöst habe, da ich nun um geeignete, spezialisierts Conditions zu erstellen, immer die Linkables casten muss. Ich zeige mal ein Stück Code. Dies ist die check methode von einer konkreten PieceCanMoveToFieldCondition, die von Condition ableitet
(Sprache ist Java)


Die Frage ist nun: Wie kann ich das Ganze ohne diese obskuren Castings lösen? Ihr stimmt mir da doch zu, dass das kein optimaler code ist. canMoveTo() oder getField() in Linkable zu verschieben ist natürlich ausgeschlossen, da dies ja eine allgemeine Framework sein soll. Mein Anspruch ist darauf, dass die Conditions sowie die Linkables beliebig erweiterbar sein sollen und trotzdem sehr spezialisierte Bedingungen möglich sein sollen.

//Edit: Eine Condition soll auch viele unterschiedliche Arten von Linkables verwalten können. ZB eine Counter Condition, die Linkables nach einer bestimmten Anzahl von Runden verlinkt oder unlinkt, unabhängig von ihrer konkreten Implementierung.

Also erstmal danke für die guten Antworten!

Zitat von »BlueCobold«

Wieso müssen die Partner beim Check übergeben werden?

Eine Condition verwaltet viele verschiedene Links und auch Linkables (die möglicherweise mehrfach oder auch noch gar nicht verlinkt sind). Das war mein Ansatz, um eine zentrale Logik zu definieren, die feststellt ob die zugrundeliegende Bedingung für 2 beliebige Linkables erfüllt ist oder nicht.

Zitat von »TrommlBomml«

Man kann sich mit interfaces auch etwas sehr zumüllen. Warum sollte ein Linkable nicht IHasFieldPosition implementieren (also von dem Interface erben)?

Weil Linkable teil der Framework ist, IHasFieldPosition aber Teil eines konkreten Spiels an dem ich gerade arbeite.

Zitat von »Sacaldur«

Wie das Casting vermieden werden kann kommt auch darauf an, wie die Anwendung insgesamt aufgebaut ist. Will man bspw. alle möglichen Arten von Objekten (in deinem Fall bspw. Conditions, in einem anderen waren es Events) an einer zentralen Stelle sammeln und "verwalten", dann wird man ohne Casting kaum auskommen, befinden sich diese aber bereits in einem bestimmten Kontext, könnte die Notwendigkeit für's Casten entfallen, da die entsprechenden Typen eindeutig bekannt sind.
Um letzteres zu erreichen, wäre Generik wohl erforderlich. So kann man nicht nur eine Klasse definieren, die eine Bedingung für "Linkable"s sind, die aber nur mit ganz bestimmten Linkables funktioniert, sondern eine Bedingung für aktive "Piece"s und passive "IHasPosition"s.

Abgesehen gibt man den Schnittstellen in Java kein I-Präfix. Statt "IHasPosition" wäre es eher "Placeable", "Locatable" o. ä. (Und Schnittstellen definieren das Verhalten von Objekten, nicht aber eventuell vorhandene Daten. "IHasPosition" klingt sehr nach einem Workaround, dennoch Daten zu beschreiben.)

Und mich würde interessieren, wofür das Ganze überhaupt gedacht ist. Was heißt bei dir "Verlinken"? Bisher habe ich am ehesten das Gefühl, dass es sich sehr stark um Over Engineering handelt...

Dann ist Casten hier tatsächlich ein notwendiges Übel also... Generik ist mal ein sehr interessanter Hinweis, da werd ich mir mal ein paar Gedanken dazu machen...

Danke auch für den Hinweis für den falschen Einsatz von Interfaces, das sieht nämlich tatsächlich so aus:

Wenn ich das jetzt in Locateable umbenenne, wäre das Problem dann gelöst? Weil in Wahrheit beschreibt es tatsächlich das Vorhandensein einer Field-Instanz, nur dass es eben auch selbst diese Field-Instanz sein kann (this pointer wird zurückgegeben). Ich fand es in einigen Teilen meines Codes bereits recht hilfreich, da eine Field Instanz stets Zeiger auf die Objekte enthält, die sich auf ihr befinden. zB kann ich mit IHasFieldPositiondings.getField().getPiece() das darauf befindliche Piece erhalten, ohne berücksichtigen zu müssen, ob IHasFieldPositiondings jetzt eben dieses Piece ist oder das Feld oder ein anderes Objekt, dass sich gerade auf diesem Feld befindet.

Und es handelt sich in der Tat um OverEngineering. Ich habe das Projekt gestartet weil mich plötzlich ein unwiderstehliches Interesse gepackt hat und nicht weil ich dessen sinnhaftigkeit beschwören kann. Es würde mich selbst interessieren, was genau am Ende dabei herauskommt. Die Idee ist im Prinzip ein "Sich selbst verwaltendes Spielfeld". Eine Art alternative Programmierung in der man die Regeln durch eine begrenzte Anzahl von Conditions festlegt und die Logik darin dann zentral verwaltet. Eine starke abstrahierung, die vielleicht irgendwo sinn machen könnte, wo ich mir aber selber noch nicht sicher bin wie genau

Zitat von »LetsGo«

Ja also das sind zu wenig Informationen, um dir da genau zu sagen, wie du das besser lösen kannst.
Aber ich kann mal soviel sagen. Beim Programmieren von Frameworks ist es oft so, dass man nicht alles super schön designen kann, weil dann Flexibilität verloren geht. Die Casts sind jetzt noch im Rahmen, aber ich könnte mir vorstellen, dass du das mit Generics lösen könntest. Aber dazu müsste man halt mehr wissen.

Das projekt ist glaube ich sehr komplex, ich hab es absichtlich überblicksmäßig gehalten, weil ich euch nicht seitenlange Diagramme und Abhämgigkeiten zumuten wollte, bevor jemand in der Lage ist eine Antwort zu verfassen. Die Antworten waren bereits aber sehr hilfreich und ich danke euch sehr! Vielleicht trudelt ja noch das eine oder andere weitere kommentar ein, das ich mit Spannung erwarte.