gegenseitiger Zugriff von zwei abgeleiteten Klassen

[r2c2]

Ja das geht auch, ich würde das so aber nicht machen. Aus mehreren Gründen. Der Hauptgrund ist, dass es letztendlich unübersichtlich wird. Wenn das Programm wächst hast du viele Objekte, die sich nur in den zugewiesenen Events unterscheiden. Wenn du jetzt mehr als nur eine Stelle hast, die sich für verschiedene Gegner ändert (Bewegung, Aussehen, Kampftaktik, was weiß ich), wird es schwer noch durch zu blicken, weil nicht klar ist, welche Events zusammengehören also dem selben Gegnertyp zuzurechnen sind. Außerdem kannst du so nicht so einfach mehrere gleichartige Gegner erstellen (der Aufwand hält sich in Grenzen, aber du müsstest extra ne Funktion dafür schreiben).

Zudem sind so die Variationen an Gegnern beschränkt.

Events haben den Vorteil, dass du sie zur Laufzeit wechseln und zuweisen kannst. Das nutzt du hier aber nicht. Und selbst wenn du das bräuchtest, könntest du das besser per Delegation lösen...

Events verwendet man normalerweise nur da, wo es wirklich um Ereignisse geht (ja es gibt diverse Ausnahmen). Also um Schnittstellen zu anderen Klassen. Als Ersatz für Vererbung sind sie IMHO eher nicht sinnvoll.

Sry, aber IMHO hat deine Lösung mehr Nach- als Vorteile.

mfg

Christian

P.S.: Nimm properties. Public fields sind bööse...

[Memnarch]

Zitat:

Außerdem kannst du so nicht so einfach mehrere gleichartige Gegner erstellen (der Aufwand hält sich in Grenzen, aber du müsstest extra ne Funktion dafür schreiben).

Also ich kann eine Funktion für XBelibig viele gegner nutzen.
Ich glaube du hast DoEntityAction nicht verstanden. Der MY parameter wird auf das aktuell zu nutzende objekt gesetzt.

Zitat:

Zudem sind so die Variationen an Gegnern beschränkt.

Wieso den dass?

Bitte nicht vergessen, Es wird auch nicht spezielle eine Angriffsfunktion geschrieben, sondern generell eine Angreif funktion die verschiedene werte von EntityA und EntityB auswertet.

[r2c2]

Zitat von Memnarch:

Also ich kann eine Funktion für XBelibig viele gegner nutzen.

Klar geht das. Hab ich auch geschrieben. Du musst nur einen Konstruktor emulieren. Aber warum denn emulieren, wenn man einen richtigen haben kann?

Zitat:

Ich glaube du hast DoEntityAction nicht verstanden. Der MY parameter wird auf das aktuell zu nutzende objekt gesetzt.

Hier emulierst du den Self-Parameter. Durch Nutzung der OO-Features hast du sowas ohne das alles selbst machen zu müssen. Du kommst ja teilweise auf die richtigen Ideen (Konstruktor, Self), baust das aber selbst nach anstatt das Vorhandene zu nutzen.

Zitat:

Zitat:

Zudem sind so die Variationen an Gegnern beschränkt.

Wieso den dass?

Ich geb zu, das hätte ich genauer darlegen können. Der Punkt ist folgender: Du hast unterschiedliche Arten von "Gegnern", die du definieren willst. Dabei sind die Arten unterschiedlich genug, dass du unterschiedlichen Code brauchst (das spräche eigentlich für Vererbung, die du aber wieder nur emulierst). Durch die Events definierst du einzelne Möglichkeiten, wie du Gegner variieren kannst. Das beschränkt dich aber in den Möglichkeiten, die du hast um Gegner zu variieren:
- du kannst auf keine privaten Felder zugreifen
- damit kannst du auch keine Methoden (bzw. bei dir Events) über einen internen Zustand koppeln. Alles, was deine Events tun, muss nach außen sichtbar sein.
- du kannst auch keine neuen Methoden und Eigenschaften hinzufügen

Das alles (und vielleicht noch mehr) schränkt dich ein.

Auf der anderen Seite hast du diverse Nachteile auf Seiten der Lesbarkeit:
- du verstößt gegen das Prinzip der geringsten Überraschung: Man erwartet eine solche Verwendung von Events nicht. Man kann so etwas tun, sollte dann aber einen sehr guten Grund dafür haben.
- zusammengehöriger Code (Code für Gegner A) ist nicht in einer Klasse gruppiert. Damit fehlt Übersicht
- du bietest diverse Möglichkeiten deinen Code falsch zu benutzen. Beispielsweise durch falsche oder fehlende Eventzuweisungen. Guten Code kann man intuitiv richtig benutzen, aber nur schwer falsch.

Das alles sind Nachteile. Gravierende Nachteile. Echte Vorteile bringt dein Ansatz aber keine. Zumindest hab ich keine entdecken können.

Auf weitere Probleme in deinem Code (Skill1..Skill10 uaahhh...) gehe ich aus Zeitgründen jetzt nicht weiter ein.

Sei mir nicht böse, aber dein Ansatz ist wirklich nicht so gut. Überdenke ihn nochmal.


mfg

Christian

[Memnarch]

Zitat:

- du kannst auch keine neuen Methoden und Eigenschaften hinzufügen

Das ist so halb und halb. Viele Funktionen/Methoden sind in der engine klasse enthalten, weil sie sich auch auf Engine interne abläufe beziehen.
So z.B. Move, was eine Entity zum gegebenen Punkt bewegt und dabei kollision ausführt.

Aber stimmt für reines OOP ist das nicht unbedingt was
Rührt noch aus alten Tagen diese Angewohnheit

Is jetzt Ca 3/4 MOnate alt der Code, seitdem einiges mehr gemacht in Delphi.

Trotzdem gäbe es bei mir immer einige Funktionen die absolut nicht in der Entity landen würden(siehe move).

Ich bin als Zentrum TEngine orientiert die alles andere Steuern kann(Bzw, deren funktionen werden von dene ntities genutzt. Enginen verwaltet halt alles)

Und was SKill1-X angeht..naja, wirklich nichts feines

[r2c2]

Zitat von Memnarch:

Zitat:

- du kannst auch keine neuen Methoden und Eigenschaften hinzufügen

Das ist so halb und halb. Viele Funktionen/Methoden sind in der engine klasse enthalten, weil sie sich auch auf Engine interne abläufe beziehen.
So z.B. Move, was eine Entity zum gegebenen Punkt bewegt und dabei kollision ausführt.

[...]

Ich bin als Zentrum TEngine orientiert die alles andere Steuern kann(Bzw, deren funktionen werden von dene ntities genutzt. Enginen verwaltet halt alles)

Das ist auch nicht so toll. Nennt sich Gottklasse...

mfg

Christian