Aber: Wie hat sich der Erfinder das gedacht?
Na ja, er hat sich gedacht, daß vielleicht jemand im
Create irgendwas mit der Interface-Referenz macht, das den Referenzzähler hoch und wieder runter zählt. Wäre der Referenzzähler bei Beginn des
Create = 0 würde das beim Runterzählen ein unerwünschtes
Destroy auslösen. Da das
NewInstance direkt vor und das
AfterContstruction direkt nach der
Create-Kette ausgeführt wird, erhöht er den
RefCount vorher künstlich und erniedrigt ihn hinterher ohne das
Destroy auszulösen (also eben nicht mit _AddRef bzw. _Release).
Er hat vermutlich nicht damit gerechnet, daß jemand das AfterConstruction überschreibt und darin außerhalb dieser Klammer (also nach dem inherited) mit dem Interface rumhantiert.
Übrigens: Für das
Destroy gibt es so eine Sicherung interessanterweise nicht. Hantieren mit Interfaces innerhalb des
Destroy eines
TInterfacedObject ist also ebenfalls zum Scheitern verurteilt. Deswegen arbeite ich in der Regel mit einer eigenen Ableitung, die lediglich das
BeforeDestruction ergänzt und den RefCount auf 1 setzt:
Delphi-Quellcode:
begin
inherited;
FRefCount := 1;
end;
Ich finde es an sich ja schon logisch, dass man in AfterConstruction zuerst inherited aufruft und dann erst das eigene macht.
Das kann man so pauschal nicht sagen. Je nach Situation kann/soll/muss das
inherited vorher, hinterher oder zwischendrin aufgerufen werden - manchmal sogar gar nicht.