Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Quellcode |
|
1 2 3 4 5 6 |
@Override public boolean check(Linkable activePartner, Linkable passivePartner) { Piece piece = (Piece) activePartner; return piece.canMoveTo(((IHasFieldPosition) passivePartner).getField()); } |
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »neido« (05.08.2015, 12:36)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
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.Wieso müssen die Partner beim Check übergeben werden?
Weil Linkable teil der Framework ist, IHasFieldPosition aber Teil eines konkreten Spiels an dem ich gerade arbeite.Man kann sich mit interfaces auch etwas sehr zumüllen. Warum sollte ein Linkable nicht IHasFieldPosition implementieren (also von dem Interface erben)?
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...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...
Quellcode |
|
1 2 3 |
public interface IHasFieldPosition { public Field getField(); } |
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.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.
Werbeanzeige