"Namespace" innerhalb einer Klasse

[shmia]

Zitat von s.h.a.r.k:

...und bin gerade dabei das class helper Konstrukt zu nutzen, da es sich hier echt wunderbar anbietet

Ich denke, es wäre besser dies über eine eigene Klasse zu lösen.
Hier mal eine Klasse, die im Konstruktor ein Control übergeben bekommt
und dann dieses Control animiert.

Delphi-Quellcode:

TAnimateControl = class(TObject)
private
  Fcontrol : TControl;
public
  constructor Create(AControl:TControl);
  procedure Animate;
  
  property Muster:TAnimateMuster; // linksrum, rechtrum, oben-nach-unten, wasauchimmer
  property MaxCycles:integer;  // max. Anzahl von Schritten
  property ScaleFactor:double; // "Stärke" der Bewegung
  property TimeStep:integer;  // Zeitdauer zwischen den Animationsschritten
  ...
end;

Der Einsatz eines Class-Helpers würde ich nicht in Betracht ziehen.

[s.h.a.r.k]

@shmia: Genau das wollte ich ja hier vermeiden Finde es etwas direkter, wenn ich Object.MachWas() aufrufe, als Controller.MachWasMit(Object) . Mir ist schon klar, dass das Geschmackssache ist, aber alles muss gehen

@himitsu: Es wird nur ein Animator verwendet, der sich um alles kümmert. Das habe ich schon. Nur ist diese Lösung mit einer weiteren Klasse nicht optimal, da der Benutzer immer noch blöde Sachen machen kann...

Aber ich sehe schon, nachdem ihr beide auch keine direkte Lösung kennt, gibt es wohl keine. Dann muss ich es wohl doch etwas anders lösen.

[shmia]

Zitat von s.h.a.r.k:

@shmia: Genau das wollte ich ja hier vermeiden Finde es etwas direkter, wenn ich Object.MachWas() aufrufe, als Controller.MachWasMit(Object) . Mir ist schon klar, dass das Geschmackssache ist, aber alles muss gehen

Deine gesuchte Lösung geht in Richtung "Vererbung"; wobei du nicht wirklich ableiten möchtest, sondern mit einem Class-Helper Funktionalität hinzufügen möchtest.
Eigentlich braucht du sogar eine Mehrfachvererbung, da du nicht nur die Methode Animate haben willst,
sondern auch noch ein (privates) Feld in dem der Animator steckt.
Ein Class-Helper ist dazu aber grundsätzlich nicht in der Lage, weil sich dadurch das Objekt um 4 Bytes verlängern müsste.
Delphi müsste schon das Konzept von partiellen Klassen beherschen um das umzusetzen, was Dir vorschwebt.

Ich kann dir nur sagen, dass du mit Vererbung hier nicht weiterkommst.
Richtig wäre "Komposition"; also so wie ich das oben gezeigt habe.
Es ist auch weniger eine Geschmacksfrage, ob man lieber Vererbung oder eher Komposition verwendet, sondern die Komposition hat handfeste Vorteile:
http://www.cleancodedeveloper.de/Rot...ritance_FCoI_3

[s.h.a.r.k]

Hm, magst zwar irgendwie recht haben, aber ich sträube mich noch etwas gegen den Gedanken So wie ich das haben will, ists halt irgendwie schöner imho (wobei Schönheit halt immer relativ ist, ich weiß)

Wenn ich meine Komponente allerdings für frühere Delphi-Versionen veröffentlichen will, dann muss ich wohl oder übel auf diese class helper verzichten... Daher wird es wohl darauf hinauslaufen eben die Komposition zu verwenden, schade drum!

[mkinzler]

Du könntest auch den Originaltyp überdecken

[stahli]

Hier ging es auch um die class helper.

Du kannst dort alles machen, wie in einer Funktion, der Du das Objekt übergibst. Diese Funktion wird allerdings an das Objekt "angepappt" und hat Zugriff auf dieses als "Self".
Überschreiben von Methoden ist nicht möglich.

[s.h.a.r.k]

Zitat von stahli:

Du kannst dort alles machen, wie in einer Funktion, der Du das Objekt übergibst. Diese Funktion wird allerdings an das Objekt "angepappt" und hat Zugriff auf dieses als "Self".
Überschreiben von Methoden ist nicht möglich.

Tja, aber genau das überschreiben kann ja evtl. zu einem Problem werden! Daher ja auch die Frage nach dem Namespace. Werde es aber wohl so machen, wie shmia gemeint hat.

@mkinzler: Du meinst Vererbung? Das will ich nicht, da mein Animator allgemeingültig sein soll und alle Integer/Extended-Properties animieren können soll -- auch wenn ein User z.B. die "Tag"-Property angibt, der Animator machts