spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Doppelpost... keine Ahnung wie das passiert ist...

Zitat von »Chromanoid«

Das stimmt doch einfach nicht.

OK, dann habe ich wohl in meinem Code Dinge, die scheinbar "einfach nicht stimmen", aber trotzdem genau so funktionieren...
In deinem Beispiel sehe ich übrigens nicht, wieso bei instanceof nicht alle anderen bei Erweiterung geändert werden müssen. Das sagst du zwar, widerspricht aber meiner Logik und meiner Erfahrung. Ich kenne das nur so, dass man dann in *jede* dieser Klassen anfängt den neuen Typ mit instanceof zu prüfen. Instanceof führt daher nach meiner Erfahrung dazu, dass man überall verstreut im Code die wildesten Type-Checks macht, strukturlos und völlig vernetzt.
Da brauchst du mich auch nicht versuchen über den Weg der Bücher, die ich lese, zu beleidigen. Das sind Erfahrungswerte. Aber ich bin das Thema Leid. Macht euren Scheiß, wie ihr das wollt und für klug haltet, ich habe die Nase voll mich zu wiederholen und dann auch noch beleidigen lassen zu müssen. Ich war hier um zu helfen und sinnvolle Anregungen zu geben, nicht um mir hier irgendwelche Sprüche anzuhören. Schönen Tag noch.

Sorry, Du hast recht, das war doof. Ich wollte nur etwas intensiver nachhaken, weil ich wirklich mit der "Essenz meines gesamten Seins" nicht nachvollziehen kann, wieso die Variante mit Mediator flexibler ist oder zu weniger Fehlern führt als die Variante mit instanceof...

Ich bezog mich da auf Chromanoid. Aber wie gesagt, ich bin raus. Hab' nur gerade deine Antwort durch meinen Edit noch gesehen.

Zitat von »Architekt«

Ich war & bin bisher noch der Ansicht, dass der Einsatz von instanceof nur zeigt, dass meine Architektur schrott ist. Es gibt eigentlich immer eine bessere Lösung. Dynamich-Cast/Up-Casts - die mit dem Einsatz von instanceof einhergehen - sind immer schlecht/teuer. In manchen Compilern hab' ich eine Art Kompromiss gesehen, so in etwa ein Polymorphes-instanceof/cast:

Quellcode

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

interface CreatureInterface { public function fulfills(ConditionInterface $condition): bool; public function asHuman(): Human; public function asAnimal(): Animal; } abstract class AbstractCreature implements CreatureInterface { public function asHuman(): Human { throw new Exception('Das ist kein Mensch'); } public function asAnimal(): Animal { throw new Exception('Das ist kein Tier'); } } final class Human extends AbstractCreature { public function fulfills(ConditionInterface $condition): bool { return $condition->fulfills($this); } public function asHuman(): Human { return $this; } }

Die Variante ist doch genauso problematisch:
1. Du musst tierisch aufpassen, dass Du nicht die falschen Viecher in eine Condition packst, die eigentlich ein anderes Viech erwartet.
2. Du musst bei einer neuen Viech-Sorte die API anpassen, AbstractCreature anpassen und alle Viech-Klassen anpassen, die nicht von AbstractCreature erben.

instanceof mag bei Sprachen wie C++ verschrien sein, weil das da eben nicht gratis kommt. Bei dynamischen Sprachen wie PHP oder Java ist das doch gratis, kostet auch nicht viel. Warum sollte man das dann nicht nutzen? Durch die Sprache werden andere Architekturstile ermöglicht. Die sind nur weil man sie nicht so schön in C++ abbilden kann deswegen nicht schlechter. Dynamische Sprachen profitieren sehr von Runtime-Type-Informationen und Reflection. Dadurch wird für viele Bibliotheken erst richtig der nutzen "freigeschaltet". In C kann man doch auch nicht richtig OOP programmieren, das heißt doch noch lange nicht, dass die Mittel der OOP schlecht sind.

Zitat von »BlueCobold«

Ich kenne das nur so, dass man dann in *jede* dieser Klassen anfängt den neuen Typ mit instanceof zu prüfen. Instanceof führt daher nach meiner Erfahrung dazu, dass man überall verstreut im Code die wildesten Type-Checks macht, strukturlos und völlig vernetzt.

Würde man die einzelnen Creature-Subtypen in eigenen Modulen oder Packages führen, würde man das natürlich verbieten. Die Klassen in Fish dürfen dann einfach nicht von Human wissen. Das kann man durch Unittests oder durch Modulabhängigkeiten bzw. deren Verbot wunderbar abbilden.

Nur Conditions in Modulen, die mehrere Creature-Typen betreffen, dürften dann auch diese Module einbinden. So kann man alle Abhängigkeiten zwischen den Creatures klar definieren und steuern.