Klonen eines Interfaces

[Jasocul]

Zitat:

Zitat von himitsu (Beitrag 1516550)

PS: Wenn es dir nur darum geht, dass es wie ein Interface/Objekt aussieht, also die Methoden und die Daten zusammen und die Funktionen in der "Klasse" drin,
dann kann man die einzelnen Funktionen auch als Methoden in den Record verschieben, statt einem Parameter auf Self zugreifen und fertig.

Damit wird später noch deutlich mehr gemacht. Ein Record wird dann sicher nicht mehr ausreichend sein. Ansonsten gebe ich dir Recht.

Zitat:

Zitat von himitsu (Beitrag 1516550)

Ansonsten nimmt man im Allgemeinen eine Funktion, welche sich TPersistent.Assign bzw. TPersistent.AssignTo nennt.
Da drin mußt du dann die Property/Felder des einen Objekts in das andere Kopieren.

Beim normalen Assign mit allgemeinem Typen wird intern nochmals geprüft, ob der Typ passt,
aber hier kannst du einfach dem Parameter den richtigen Typen geben und schon kann nur der richtige Typ reingegeben werden.

Mit Assign hatte ich es gestern auch versucht, bin dann aber irgendwie gescheitert (Die richtige Basisklasse habe ich dafür natürich genommen). Vermutlich war es gestern einfach schon zu spät und ich habe den Knoten nicht mehr aus den Gehirn bekommen. Ich lege mir aber gleich nochmal ein ToDo an, um das nochmal zu prüfen.

EDIT:
Ich bin nicht gescheitert, aber da die Instanzen vom Typ IMyInt sind, hätte ich hart auf TMyClass casten müssen, damit das assign funktioniert. Da ich kein Freund von solchen Casts bin, habe ich nach einer anderen Lösung gesucht. Wenn es einen Weg ohne den Cast gibt, bräuchte ich einen Tipp.

[himitsu]

Ja, die vordefinierten Assign nehmen nur persistente Klassen an.
seit paar Jahren kann man in Delphi Interfaces (in denen ein Delphi-Objekt steckt) ganz einfach mit AS in ein Objekt casten.

Wenn alles Kopierbare aber als Property/Funktionen lesbar und schreibbar ist, kannst du auch einfach diese Property/Funktionen des Interfaces zum Kopieren der Eigenschaften benutzen und mußt nicht casten.



Wie gesagt, DU mußt die Eigenschafften einzeln übertragen, auch wenn man es bei persistenten Klassen auch anders lösen könnte.
Diese persistenten Klassen haben ja Funktionen, um ihren Inhalt/Zustand zu serialisieren/speichern, also quasi die eine Instanz in einen Stream speichern und die andere Instanz aus dem Stream zu laden.

Aber da du ja nicht von TPersistent oder TComponent geerbt hast, mußt du eh diese Methode selber komplett neu einbauen und kannst dort auch so Einiges ändern, wie eben z.B. den Parameter als Interface.

Im Prinzip ist es egal, wie du deine Kopieren-Methode nennst, aber es macht sich besser, wenn man Methoden mit einheitlichem Verhalten auch einheitlich benennt.
Darum Assign, aber auch Clone wird da oft als Name genommen. Wobei Assign die Daten in die eigene Instanz übernimmt, AssignTo an die andere Instanz übergibt und Clone erstellt selber die neue Instanz, überträgt die Eigenschaften und gibt es als Result zurück.

[Jasocul]

Vielen Dank für deine zusätzlichen Infos.
Eine Umstellung auf TPersistent wäre in der aktuellen Phase sicher kein Problem. Aber im Moment scheint es mir so, als hätte ich mit meiner Variante den passenden Weg gefunden. Trotzdem werde ich weiterhin ein Auge darauf haben, ob nicht doch noch eine Anpassung notwendig wird.

Zitat:

Zitat von himitsu (Beitrag 1516557)

Darum Assign, aber auch Clone wird da oft als Name genommen. Wobei Assign die Daten in die eigene Instanz übernimmt, AssignTo an die andere Instanz übergibt und Clone erstellt selber die neue Instanz, überträgt die Eigenschaften und gibt es als Result zurück.

Sehr interessant. Mich hatte das heute Morgen selbst gestört und daher heißt die Methode seit ein paar Stunden schon CopyFrom. :wink:

[himitsu]

Zitat:

Zitat von Jasocul (Beitrag 1516558)

Vielen Dank für deine zusätzlichen Infos.
Eine Umstellung auf TPersistent wäre in der aktuellen Phase sicher kein Problem. Aber im Moment scheint es mir so, als hätte ich mit meiner Variante den passenden Weg gefunden. Trotzdem werde ich weiterhin ein Auge darauf haben, ob nicht doch noch eine Anpassung notwendig wird.

Zitat:

Zitat von himitsu (Beitrag 1516557)

Darum Assign, aber auch Clone wird da oft als Name genommen. Wobei Assign die Daten in die eigene Instanz übernimmt, AssignTo an die andere Instanz übergibt und Clone erstellt selber die neue Instanz, überträgt die Eigenschaften und gibt es als Result zurück.

Sehr interessant. Mich hatte das heute Morgen selbst gestört und daher heißt die Methode seit ein paar Stunden schon CopyFrom. :wink:

Hier mal ein Beispiel, was zeigt, dass Assign/Assign TO nichts automatisch macht, sondern du es machen mußt.

Delphi-Quellcode:

procedure TEditMargins.Assign(Source: TPersistent);
begin
  if Source is TEditMargins then
  begin
    FLeft := TEditMargins(Source).Left;
    FRight := TEditMargins(Source).Right;
    FAuto := TEditMargins(Source).Auto;
  end
  else
    inherited;
end;

Auch wenn das Beispiel nicht Ideal ist, denn das ELSE würde ich weglassen und Interhited immer ausgeführt werden sollte.
Denn jede Klasse kopiert die eigenen Eigenschaften, welche bei sich eingebaut wurden, und die Vorfahren kopieren ihr Zeugs usw.
Wobei ich das Inherited als Erstes aufrühre, also erst das Zeugs der Vorfahren und dann das Eigene, genauso wie man es auch im Create macht. (eigenes Erstellen und Laden zuletzt und beim Entladen und Freigeben zuerst)

[Jasocul]

Inherited würde ich beim Assign auch als erstes machen. Anderenfalls bestünde die Gefahr, dass manuell gesetzte Werte durch ein folgendes inherited wieder überschrieben würden.

Allerdings bin ich jetzt ein wenig verwirrt. Du schreibst, dass Assign nichts automatisch macht und man die Werte selbst übernehmen muss. Andererseits kopiert jede Klasse die eigenen Eigenschaften. Wenn ich also in deinem Beispiel ein TEditMargins als Parameter übergebe, müssten doch alle eigenen Eigenschaften übernommen werden, also auch die, die im Beispiel manuell zugewiesen werden, oder?

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1516559)

denn das ELSE würde ich weglassen und Interhited immer ausgeführt werden sollte.

Das darf es aber nicht! Zumindest nicht immer. Die Implementierung von TPersistent.Assign leitet nämlich zu Source.AssignTo und das ist in der Regel nicht gewollt, sondern eher schädlich, wenn die aktuelle Klasse die Zuweisung im Assign selbst vornimmt.

Im Assign das inherited aufzurufen darf also nur dann passieren, wenn nicht direkt von TPersistent abgeleitet wurde und eine dazwischen liegende Klasse den Aufruf von TPersistent.Assign verhindert.