TObjectList-Object da, aber beim Zugriff Stack-Overflow

[SProske]

Da der TE wohl XE4 verwendet, wäre sicher auch die generische Objektliste aus der Unit System.Generics.Collections einen Blick Wert.
Damit könnte man sich die Schreibarbeit für Add/Remove/IndexOf etc. ersparen.

[Captnemo]

@mjustin:
das Private fehlt tatsächlich. Eigentlich kommen bei mir die Getter und Setter immer in Private, hatte ich lediglich vergessen. (hätte bei dem fehlenden Inherited aber nichts geändert).
Aber ich weiß jetzt was du meinst.

Klar kann man das auch über Generics verwenden. Aber ich habe mich so an meine ObjectList gewöhnt....

Und, zugegeben, der Variablenname Temp ist sicherlich nicht der schlaueste, aber man kann das schon lesen

[Sir Rufo]

Nur so als Tip:

Wenn man Klassen mit Stream-Funktionen ausstattet, dann sollte man auch immer das Interface IStreamPersist an die Klasse heften.

Macht auf jeden Fall das Leben leichter

[Benmik]

Zitat von Sir Rufo:

Wenn man Klassen mit Stream-Funktionen ausstattet, dann sollte man auch immer das Interface IStreamPersist an die Klasse heften.Macht auf jeden Fall das Leben leichter

Könntest du mal ausführen, in welchen praktischen Fällen dieses Interface das Leben leichter machen würde? Habe mich ein bisschen in Interfaces eingelesen und bin leicht ratlos, welchen Nutzen man eigentlich von Interfaces hat, wenn man nicht gerade komplexe Klassenstrukturen hat oder externe Schnittstellen ansprechen will.

[stahli]

Hi Benmik,

ich habe mal ein kleines Einsteigertutorial für Interfaces erstellt.
Vielleicht hilft es Dir ja etwas: http://www.delphipraxis.net/183702-i...-factorys.html

Interfaces sind hilfreich, wenn man gleiche Funktionalitäten in unterschiedlichen Klassen unterbringen will.
Es erspart einem das Prüfen und Casten von vorliegenden Objekten wie

Delphi-Quellcode:

if (MyObj is ClassA) then
  (MyObj as ClassA).DoX
else if (MyObj is ClassB) then
  (MyObj as ClassB).DoX;

Statt dessen schreibt man einfach

Delphi-Quellcode:

var
lDoX: IDoX;
...
if Supports(MyIntf, IDoX, lDoX)
  lDoX.DoX;

Dan ist völlig egal, was da für ein Objekt dahinter steckt. Wichtig ist nur noch, ob DoX unterstützt wird oder nicht.


Fluch und Segen (und außerhalb von Delphi unüblich) ist die automatische Referenzzählung. Objekte hinter Schnittstellen werden automatisch freigegeben, wenn es keine Referenzen mehr darauf gibt.
Das kann man als positiv oder auch negativ bewerten - je nach den vorliegenden Bedürfnissen.

[Benmik]

Hallo Stahli, deine Produktionen waren für mich sozusagen erste Anlaufstelle. Ich habe zum ersten Mal im Groben kapiert, was Interfaces überhaupt sind. Jetzt stehe ich vor der moralischen Entscheidung : Muss ich die auch verwenden? Die meisten Tutorial-Autoren machen eine Bemerkung, dass für "einfache" Delphi-Programme Interfaces meist nicht notwendig sind. Deshalb hat mich Sir Rufos Bemerkung verwirrt: Warum sollte mann immer das Interface "anheften"? Ist das wirklich die Regel, dass man so viele Objekte hat, die man unter einem Interface versammeln muss?
Und was ich über die Tücken der Referenzzählung gelesen habe: Da sträuben sich die Haare. Also, selbst wenn ich drei Objekte hätte, ich würde die Klassen einzeln erstellen und gut ist. Voraussetzung natürlich: Ich habe weder Schnittstellen nach außen noch irgendwelche Plugins oder Ähnliches.
Aber vielleicht übersehe ich da was. Daher die Bitte um eine praktische Verwendung.

[Sir Rufo]

Zitat von stahli:

Fluch und Segen (und außerhalb von Delphi unüblich) ist die automatische Referenzzählung. Objekte hinter Schnittstellen werden automatisch freigegeben, wenn es keine Referenzen mehr darauf gibt.
Das kann man als positiv oder auch negativ bewerten - je nach den vorliegenden Bedürfnissen.

Das ist leider total falsch.

1. Die Referenz-Zählung ist keine Erfindung von Delphi
2. Eine Instanz kann sich automatisch freigeben, wenn der Referenz-Zähler auf 0 geht. Ob das passiert hängt von der Implementierung ab ... und die hat man ja selber in der Hand.

[Benmik]

Und könntest du neben Stahli auch mich mit einer Antwort bedenken?

[Sir Rufo]

Zitat von Benmik:

Zitat von Sir Rufo:

Wenn man Klassen mit Stream-Funktionen ausstattet, dann sollte man auch immer das Interface IStreamPersist an die Klasse heften.Macht auf jeden Fall das Leben leichter

Könntest du mal ausführen, in welchen praktischen Fällen dieses Interface das Leben leichter machen würde? Habe mich ein bisschen in Interfaces eingelesen und bin leicht ratlos, welchen Nutzen man eigentlich von Interfaces hat, wenn man nicht gerade komplexe Klassenstrukturen hat oder externe Schnittstellen ansprechen will.

Wenn du da so eine schöne Klasse hast, die sich in einen Stream schreiben kann, dann könnte man eines schönen Tages auf die Idee kommen, diese in einer Datenbank in einem Blob-Feld abzulegen.

Habe ich damals beim designen der Klasse nachgedacht und das Interface IStreamPersist implementiert, dann sieht mein Code so aus

Delphi-Quellcode:

MyDataSet.Append;
MyDataSet.FieldByName( 'BlobData' ).Assign( MyInstance );
MyDataSet.Post;

Und wenn ich es wieder zurück haben möchte?

Delphi-Quellcode:

// leider nur sehr kurz
MyInstance.Assign( MyDataSet.FieldByName( 'BlobData' ) );

[Benmik]

Hab Dank. Das muss ich mir erstmal zu Gemüte führen. Vermutlich liegt für mich der Punkt, an dem ich mal Interfaces brauchen kann, in einiger Ferne. Das war bei generischen Objektlisten allerdings auch mal so, und heute kann ich mir ein Leben ohne sie gar nicht mehr vorstellen.