3. Es gibt eine Klasse, die hat ein Feld von der Klasse die das Interface implementiert.
Dem Feld wird mittels <Klassenname>.Create(...); die Objektreferenz zugewiesen und dieses Feld
wird später an den Constructor des Threads übergeben (genauer: das Property davon, welches direkt
auf das Feld durchgreift).
Wenn du die Instanz in einer Objektreferenz speicherst, darfst du entweder nie (!) das Interface verwenden oder du musst die Referenzzählung in der Klasse deaktivieren (sprich statt TInterfaceObject als Basisklasse einfach TSingletonImplementation aus System.Generics.Defaults verwenden).
Was nun? Das Interface deckt bisher leider nicht die komplette Funktionalität der Klasse ab.
Man könnte es ggf. erweitern und dann statt einer normalen Objektreferenz für das Feld gleich das
Interface benutzen. Würde das die Sache besser machen?
Ja, eindeutig. Du kannst auch ein zweites Interface dafür verwenden und mit as / Supports casten, wenn diese Funktionalität nicht offen verfügbar sein soll.
Man kann eine Instanz einer Klasse nach der Erstellung auch durchaus in eine Objektreferenz packen und z.B. mit Daten füttern und erst danach in eine Interfacereferenz packen, die diese Möglichkeiten nicht bietet. Aber danach darf man die Objektreferenz nie wieder verwenden (am besten direkt auf nil setzen), da man ja nie weiß wann das Objekt über das Interface freigegeben wird (wodurch das Objekt aus der Objektreferenz ungültig ist). Außerdem wird das Objekt freigegeben, sobald das Objekt als Interface weitergegeben wurde und die Interfacereferenzen aus dem Scope laufen oder nil werden. Denn es gibt ja keine dauerhaft aktive Interfacereferenz, wenn es als Objektreferenz gespeichert wird...
1. Habe _AddRef und _Release beide überschrieben und darin sowohl einen Breakpoint gesetzt als auch
eine LogCat Logmeldung ausgegeben
Das verstehe ich bei Verwendung des Interfaces nicht. Aber ohne Quelltext kann ich dazu auch nicht viel mehr sagen.