spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »dot«

Zitat von »babelfish«

Also möchte ich abfragen: Ist diese Einheit ein Krieger? etc. :D

Warum willst du das tun? Wenn du das tun willst heißt das du hast ein Designproblem....

Und wenn man es doch braucht, warum reicht eine einfache Funktion der Art GetUnitType() nicht aus?

Es wurden ja schon Wege genannt aber wie gesagt sind das nur Painkiller und keine Lösungen für das wirkliche Problem. Das verbirgt sich nämlich hinter der Tatsache warum du sowas überhaupt tun willst. Die Lösung heißt virtuelle Methoden wie Sylence schon gesagt hat. Und damit mein ich keine virtuelle GetType() Methode.

Zitat von »TGGC«

Zitat von »dot«

Zitat von »babelfish«

Also möchte ich abfragen: Ist diese Einheit ein Krieger? etc.

Warum willst du das tun? Wenn du das tun willst heißt das du hast ein Designproblem....

Und wenn man es doch braucht, warum reicht eine einfache Funktion der Art GetUnitType() nicht aus?

Eine GetUnitType() Methode ist auch nix Andres als ein selbstgebauter typeid-Operator, da kannst du genausogut einfach den in C++ eingebauten nutzen. Aber wenn man meint sowas zu brauchen steckt praktisch immer ein Designproblem dahinter. Denn überleg mal was es eigentlich bedeutet wenn du den Laufzeit-Typ eines Objektes bestimmen willst um zu entscheiden was damit getan werden muss. Das bedeutet schlicht und einfach dass deine Abstraktion widersprüchlich ist. Wenn du eine Funktion hast die mit Units arbeitet aber für eine bestimmte Art von Unit etwas anderes machen soll als für eine andere Art von Unit dann heißt das: Dein Konzept einer Unit ist unvereinbar mit der Operation die du gerade zu implementieren versuchst. Meistens wird das daran liegen dass die Operation in ihrer Natur spezieller als Unit ist. Aber du musst in jedem Fall entweder die Schnittstelle Unit überdenken oder die Sinnhaftigkeit dessen was du gerade damit vorhast.

Hm, und wie sieht es hier aus?

Sagen wir mal ich habe 2 Entities und habe jetzt festgestellt, dass beide kollidieren. Nun kann ich ja von dem einem eine virtuelle Methode aufrufen onTouch oder so. Damit kann ich für jeden Entity-Typ bestimmen was passiert, wenn er mit irgendwas zusammen stößt, ohne das ich die unterscheiden muss, so weit so gut. Aber sagen wir, ich möchte unterschiedliche Dinge tun, je nachdem, mit was für einem Objekt ich zusammengestoßen bin. Ich müsste dann ja in der onTouch Methode irgendwie zwischen den Typen unterscheiden, weil ich ja bei speziellen Kombinationen auch die speziellen Werte der Typen benötige. Wäre dann für dich ein dynamic_cast immer noch ein Designfehler? Wie würde man es sonst elegant machen, eine Methode in Abhängigkeit von 2 Typen aufzurufen (hört sich irgendwie nach Templates an, aber die Typen sind ja zur Compilierzeit noch unbekannt).

Double Dispatch Pattern

Ich finde diese pauschale aussage dass typüberprüfungen schlechtes desingn sind auch ziemlich platt ausgedrückt. man kann sicherlich komplizierte pattern nutzen aber ich würde mich in zweifel für die typüberprüfung entscheiden - und wenn es ein enumwert ist. in c# macht man auch ohne ende gebrauch davon...

Ich sag auch nicht dass jede Typprüfung zwangsweise immer schlechtes Design ist. Aber ein Typeswitch halte ich rein prinzipiell für schlechtes Design, ganz unabhängig von irgendeiner Sprache. Warum hab ich ja oben schon genau erläutert. Ein Typeswitch weist imo darauf hin dass an deiner Abstraktion was faul ist.

Zitat von »TrommlBomml«

Iin c# macht man auch ohne ende gebrauch davon...

Also ich nicht, außer das Framework zwingt mich dazu. In diesen Fällen ist es aber meistens so dass aufgrund restlichen Struktur meines Programmes der nötige Downcast nur Formalität ist und niemals fehlschlagen kann...