Einzelnen Beitrag anzeigen

r2c2

Registriert seit: 9. Mai 2005
Ort: Nordbaden
925 Beiträge
 
#15

AW: gegenseitiger Zugriff von zwei abgeleiteten Klassen

  Alt 15. Nov 2010, 21:03
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
Kaum macht man's richtig, schon klappts!
  Mit Zitat antworten Zitat