TObjectList-Object da, aber beim Zugriff Stack-Overflow

[Benmik]

Zitat:

Zitat von Sir Rufo (Beitrag 1327352)

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:

Zitat von stahli (Beitrag 1329223)

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:

Zitat von Benmik (Beitrag 1329165)

Zitat:

Zitat von Sir Rufo (Beitrag 1327352)

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

Delphi-Quellcode:

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. :thumb:

[stahli]

@Benmik

Also grundsätzlich würde ich bei einem überschaubaren Projekt keine Interfaces verwenden. Erst mal bringt das Dir nämlich nichts.

Interfaces bringen Dir nur etwas, wenn sie Vorteile bringen. ;-)

Wenn die Wahrscheinlichkeit besteht, dass Du später verschiedene Klassen dynamisch tauschen möchtest, dann machen Interfaces (und der etwas höhere Aufwand) Sinn. Man kann dann eher in "Funtionalitäten" denken und die Klassen sind dann "Funktionalitätenblöcke" (IkannA, IkannB, IkannC).

Wenn Du mit Klassen nicht mehr weiter kommst und andauernd casten musst, dann denke halt über den Einsatz von Interfaces nach. Als reinen Selbstzweck macht das wenig Sinn.


@Sir Rufo
Oh, ich sehe gerade, man kann Interfaces offenbar auch TObject zuweisen und nicht nur TInterfacedObject und somit ohne Referenzzählung arbeiten. War mir noch gar nicht klar. Werde ich heute Abend gleich mal versuchen.
Ich dachte es geht nur mit (Leer-)Überschreiben der Referenzzählung.

[Sir Rufo]

Mit einem Interface legt man fest, was die Klasse implementieren muss.

Basis für jedes Interface ist dabei

Delphi-Quellcode:

IInterface

und das legt 3 Methoden fest, die also immer wie auch immer vorhanden sein müssen.

Wie diese Implementierung und das Verhalten aussieht ... bleibt dem Klassen-Designer überlassen.

Delphi-Quellcode:

TInterfacedObject

hat diese 3 Methoden schon implementiert und ich kann von da meine Klasse ableiten ... wenn die Implementierung von

Delphi-Quellcode:

TInterfacedObject

auch passt.

Und es gibt noch eine Menge mehr Spielarten gerade im Bezug auf Interfaces, die das ganze dann auch sehr flexibel machen.

[stahli]

Stimmt, ich hatte mich hier von einem anderen Thread in die Irre führen lassen. Aber Das Überschreiben (Stillegen) der Referenzzählung werde ich nochmal versuchen.