Forum: Algorithmen, Datenstrukturen und Klassendesign
by r2c2,
15. Nov 2010
Das ist auch nicht so toll. Nennt sich Gottklasse...
mfg
Christian
Forum: Algorithmen, Datenstrukturen und Klassendesign
by r2c2,
15. Nov 2010
Klar geht das. Hab ich auch geschrieben. Du musst nur einen Konstruktor emulieren. Aber warum denn emulieren, wenn man einen richtigen haben kann?
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...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by r2c2,
15. Nov 2010
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...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by r2c2,
12. Nov 2010
Das kommt drauf an, ob Waffen relevant sind, d.h. ob der Spieler/das Monaster die Waffe wechseln kann, etc. Wenn ja, hast du Recht. Ansonsten ist eine Waffenklasse unnötig.
mfg
Christian
Forum: Algorithmen, Datenstrukturen und Klassendesign
by r2c2,
12. Nov 2010
Class helpers hier zu nutzen ist ne interessante Idee. Gefällt mir. Aber es löst das Problem nicht. Zusätzlich ist immer noch eine is-Verzweigung oder das Visitor-Pattern nötig. Beispiel:
var
a, b: TThing;
begin
a := TAsteroid.Create;
b := TShip.Create;
a.CollideWith(b);
Forum: Algorithmen, Datenstrukturen und Klassendesign
by r2c2,
11. Nov 2010
Genau. Bzw. besser noch als Methode:
procedure TMovableObject.Fight(AOther : TMovableObject);
begin
Self.Leben := Self.Leben - AOther.Staerke;
AOther.Leben := AOther.Leben - Self.Staerke;
end;
Das ist ziemlich straightforward.