Referenz Verwaltung

[Jonas Shinaniganz]

Hi Ihr Guten!

Es geht um Referenzen(Pointer) auf Instanzen die noch auf die Instanzen zeigen wenn die Instanzen schon freigegeben sind. (Der Speicher freigegeben ist)

Habe warscheinlich ein grundsätzliches Problem zu lösen. Ich lass am besten mal den Code sprechen, der sagt mehr als Worte und wenn Ich hier lange rede dann meißt eh nur um meinen Kopf und Kragen.

Delphi-Quellcode:

//type
  
TMeinObject = class(TObject)
public
  VarX : TMeinObject;
end;

KlasseA : TMeinObject;
KlasseB : TMeinObject;

//implmnt...

KlasseA := TKLasseA.Create;
KlasseB := TKLasseB.Create;

KlasseB.VarX := KlasseA;
KlasseA.VarX := KlasseB;

FreeAndNil(KlasseA);

if (Assigned(KlasseB.VarX)) then
begin
  ShowMessage('It is assigned... this did not help you sir.');
end;

Und klar kann ich so nicht herrausfinden ob da noch Zugriffsrechte bestehen weil die Referenz ja bloß ein ahnungsloser Pointer ist... KlasseB.VarX möchte doch bitte NIL sein. Deswegen:

Delphi-Quellcode:

TMeinObject = class(TObject)
public
  VarX : TMeinObject;
  ReferenzListe : TList;
  procedure FreeNotification(Sender : TObject);
  constructor Create;
  destructor Destroy; override;
end;

var
  KlasseA : TMeinObject;
  KlasseB : TMeinObject;

implementation

{$R *.dfm}

procedure wayne...
begin
  KlasseA := TKLasseA.Create;
  KlasseB := TKLasseB.Create;

  KlasseB.VarX := KlasseA;
  KlasseA.ReferenzListe.Add(KlasseB);

  KlasseA.VarX := KlasseB;
  KlasseB.ReferenzListe.Add(KlasseA);

  FreeAndNil(KlasseA);

  if (Assigned(KlasseB.VarX)) then
  begin
    ShowMessage('It is assigned... this did not help you sir.');
  end;

end;


constructor TMeinObject.Create;
begin
  ReferenzListe := TList.Create;
end;


destructor TMeinObject.Destroy;
var
  I: Integer;
begin
  // Referenzlisten Einträge Nillen
  for I := 0 to ReferenzListe.Count - 1 do
  begin
    TMeinObject(ReferenzListe[I]).FreeNotification(Self);
  end;
  ReferenzListe.Free;
  inherited;
end;


procedure TMeinObject.FreeNotification(Sender: TObject);
begin
  if Sender = VarX then
    VarX := nil;
end;

end.

Damit das jetzt alles brav implementiert wird und alle Klassen von denen Ich auch Referenzen erzeuge Ihre Referenzen selbst verwalten hatte Ich jetzt vor ein IInterface zu verwenden, das habe ich aber noch nie verwendet.

Delphi-Quellcode:

unit ReferenzVerwaltungsInterface;

interface

type
  IReferenceManager = interface(IInterface)

  end;

implementation

end.

Bevor Ich jetzt anfange zu Programmieren wollte Ich noch mal hier nachfragen ob es üblich ist so mit dem Problem umzugehen oder ob es etwas viel besseres / cooleres gibt wie man jetzt am besten einen solchen Referenzmanager aufbaut.

Grüße.

[jaenicke]

Wenn du Objekte an mehreren Stellen referenzierst, sind Interfaces eine gute Möglichkeit das zu lösen.

Dafür muss man natürlich dafür sorgen, dass die durch die Interfaces gekapselten Objekte nicht von anderen Sachen abhängig sind, die es dann nicht mehr gibt. Dieses Problem kann es bei der Mischung von Objektreferenzen und Interfaces relativ schnell geben.

An der Stelle verweise ich einmal auf das Delphi Spring Framework. Dazu gibt es auch viele Artikel wie diesen.
Ich persönlich kann den Ideen in der Ausprägung zwar nicht ganz so viel abgewinnen, weil sie mir zu weit gehen, aber andere finden das so gut, dass ich es dennoch erwähne. :wink: Was du davon hältst findest du am besten selbst heraus. :wink:

[shmia]

Was du da vorhast ist so etwas wie die Vorstufe zu einer Garbage Collection.
Ich meine man sollte das entweder richtig oder gar nicht machen.
Im Falle von Delphi, das keinen Garbage Collector besitzt, würde ich auf solche Tricks wie Smart Pointer komplett verzichten.

Stattdessen benötigt man eine bestimmte (geistige) Einstellung, wie man mit Objekten oder Resourcen ganz allgemein umzugehen hat.
Wann immer ein Objekt erzeugt wird entsteht auch eine Verpflichtung das Objekt später wieder mit Free freizugeben.
So nach dem Motto: "Wer das Essen bestellt hat muss nachher auch abspülen"
Wenn in einem Formular ein Objekt erzeugt wird, dann hat das Formular den Besitz (Ownership) übernommen und damit auch die Verpflichtung sich um das Objekt zu kümmern.

Es ist aber auch möglich, diese Verpflichtung gezielt abzutreten.

Delphi-Quellcode:

var
  list : TObjectList;
  x : TMeineKlasse;
begin
  list := TObjectList.Create({OwnsObjects=}True);
  x := TMeineKlasse.Create;
  list.Add(x);  // TObjectList sorgt für die spätere Freigabe von x

Bei Komponenten tritt diese Abgabe der Verantwortung bzw. Ownership ganz explizit zu Tage.
Man gibt im Konstruktor einfach den Owner an und der Owner wird sich schon um die Freigabe kümmern.

Jetzt ist eine Sache noch ganz wichtig
Keine globalen Objekt-Variablen verwenden!
Bei globalen Variablen hat niemand die Verantwortung übernommen; daher kommen die Probleme bei der Freigabe.
Wenn du alle deine globalen Variablen eliminierst, werden auch deine Probleme mit der Freigabe verschwinden.

[Thom]

Zitat:

Zitat von shmia (Beitrag 1171953)

Im Falle von Delphi, [...], würde ich auf solche Tricks wie Smart Pointer komplett verzichten.

Weshalb verzichten? Und wieso ist das ein "Trick"? Ohne gegenseitige Benachrichtigung bei Freigabe von Objekten würde die ganze VCL nicht funktionieren...

Zitat:

Zitat von shmia (Beitrag 1171953)

Jetzt ist eine Sache noch ganz wichtig
Keine globalen Objekt-Variablen verwenden!
Bei globalen Variablen hat niemand die Verantwortung übernommen; daher kommen die Probleme bei der Freigabe.

Ganz einfach:

Delphi-Quellcode:

finalization
  MeinGlobalesObjekt.Free;
end.

Wo ist das Problem?

[shmia]

Zitat:

Zitat von Thom (Beitrag 1171957)

Zitat:

Zitat von shmia (Beitrag 1171953)

Im Falle von Delphi, [...], würde ich auf solche Tricks wie Smart Pointer komplett verzichten.

Weshalb verzichten? Und wieso ist das ein "Trick"? Ohne gegenseitige Benachrichtigung bei Freigabe von Objekten würde die ganze VCL nicht funktionieren...

Die VCL verwendet keine Tricks sondern nur den etablierten Weg über Komponenten.

DAS hier ist ein Trick (in dem die Referenzzählung eines Interface ausgenützt wird):

Delphi-Quellcode:

unit UAutoRelease;

interface

{**************************************************************************
 * NAME:    AutoRelease
 * DESC:    Gibt das übergebene Objekt automatisch beim Verlassen der
 *          aktuellen Funktion frei.
 * PARAMS:  obj: TObject
 * RESULT:  IUnknown
 *
 * Hilfsfunktion, um Objekte automatisch beim Verlassen der aktuellen
 * Funktion freizugeben.
 * Damit kann man sich manche try .. finally Blöcke sparen.
 * Beispiel:
 *    procedure xyz;
 *    var sl: TStringList;
 *       t : IUnknown;
 *    begin
 *       sl := TStringList.Create;
 *       t := AutoRelease(sl);
 *       sl.LoadFromFile('c:\autoexec.bat');
 *       ...
 *       // sl.Free wird nicht mehr benötigt!!!
 *    end;
 *************************************************************************}
function AutoRelease(obj: TObject): IUnknown;

implementation

type
   TAutoReleaseObject = class(TInterfacedObject, IUnknown)
   private
      FObject: TObject;
   public
      constructor Create(obj: TObject);
      destructor Destroy; override;
   end;

constructor TAutoReleaseObject.Create(obj: TObject);
begin
   inherited Create;
   FObject := obj;
end;

destructor TAutoReleaseObject.Destroy;
begin                    
   FObject.Free;
   inherited;
end;

function AutoRelease(obj: TObject): IUnknown;
begin
   Result := TAutoReleaseObject.Create(obj);
end;

end.

Zitat:

Zitat von Thom (Beitrag 1171957)

Delphi-Quellcode:

finalization
  MeinGlobalesObjekt.Free;
end.

Wo ist das Problem?

Das Problem ist, dass man globale Objekte vermeiden sollte wann immer es möglich ist.
Manchmal lässt es sich nicht vermeiden ein Objekt global anzulegen, aber jedes globale Objekt erzeugt auch Probleme wie schlechte Testbarkeit.
Wenn Projekte an Umfang zunehmen und Hunderte von Units haben ist jedes globale Objekt eine technische Schuld für die man "Zinsen" bezahlen muss.

[Thom]

Zitat:

Zitat von shmia (Beitrag 1171962)

Die VCL verwendet keine Tricks sondern nur den etablierten Weg über Komponenten.

Eben. Und eine Komponente ist kein Objekt? Du hast mir also meine Frage noch nicht beantwortet: Weshalb soll man "Smart Pointer", "Smart Interfaces" oder wie immer solche Dinge auch genannt werden, nicht verwenden? Weil sie nicht "etabliert" sind?

Zitat:

Zitat von shmia (Beitrag 1171962)

Das Problem ist, dass man globale Objekte vermeiden sollte wann immer es möglich ist.

Ja - weshalb denn? Nenne bitte einen nachvollziehbaren Grund.

Zitat:

Zitat von shmia (Beitrag 1171962)

Manchmal lässt es sich nicht vermeiden ein Objekt global anzulegen, aber jedes globale Objekt erzeugt auch Probleme wie schlechte Testbarkeit.

Auch das ist nur eine pauschale Aussage. Es wäre schön, wenn Du Deine Behauptungen auch untermauern würdest...

[shmia]

Zitat:

Zitat von Thom (Beitrag 1171965)

Weshalb soll man "Smart Pointer", "Smart Interfaces" oder wie immer solche Dinge auch genannt werden, nicht verwenden? Weil sie nicht "etabliert" sind?

Nein, weil der Programmierer damit seine schlechte Struktur (globale Objekte, keine Vorstellung über die Lebendauer von Objekten) überdeckt was langfristig zu schlecht wartbarem Code führt.

Zitat:

Zitat von Thom (Beitrag 1171965)

Zitat:

Zitat von shmia (Beitrag 1171962)

... dass man globale Objekte vermeiden sollte wann immer es möglich ist.

Ja - weshalb denn? Nenne bitte einen nachvollziehbaren Grund.

Also das gehört zu den Grundlagen eines jeden Programmierers, der sein Handwerk ernsthaft betreibt.
http://c2.com/cgi/wiki?GlobalVariablesAreBad

[Namenloser]

Eigentlich hat das nichts mit globalen Variablen zu tun.

Es kann einfach sein, dass man das selbe Objekt an zwei verschiedenen Stellen verwendet, wobei es von der einen Stelle freigegeben wird. Die andere Stelle kriegt davon aber nichts mit und hat keine Möglichkeit zu überprüfen, ob das Objekt noch existiert, weil Assigned nur den Pointer auf nil prüft.

Für den Fall, dass man ein Objekt nur an einer einzigen Stelle verwendet, gibt es FreeAndNil, aber bei mehreren, unabhängige Referenzen hilft das nichts. Mal unabhängig davon, dass man immer leicht alles pauschal als „schlechtes Design“ abtun kann, ist das irgendwie asymmetrisch.

Man kann das Problem natürlich „klassisch“ mithilfe eines Observer-Patterns o.ä. angehen (so ähnlich wie es die VCL afaik auch macht), aber das ist erstens umständlich und zweitens wieder eine potenzielle Fehlerquelle, weil man jedes mal darauf achten muss, manuell einen Observer hinzuzufügen oder zu entfernen.

Ein Smart-Pointer automatisiert das Prozedere einfach nur und wäre daher aus meiner Sicht eine Verbesserung – schlechtes Design gibt es mit und ohne Smart Pointer. Aber mit Smart-Pointer hat man zumindest eine Fußangel weniger, an der es knallen kann.

Und an dieser Stelle muss ich natürlich noch mal auf meine Frickel-Lösung aus diesem Thread verweisen, der das gleiche Thema hatte ;). Vielleicht fühlt sich ja jemand inspiriert und entwickelt etwas daraus, das man tatsächlich einsetzen kann (eventuell mithilfe von neuen Sprachfeatures wie Generics, die ich unter TDE leider nicht zur Verfügung habe)...

[shmia]

Zitat:

Zitat von NamenLozer (Beitrag 1171978)

Eigentlich hat das nichts mit globalen Variablen zu tun.
Es kann einfach sein, dass man das selbe Objekt an zwei verschiedenen Stellen verwendet, wobei es von der einen Stelle freigegeben wird.

Genau hier liegt der Hase im Pfeffer!
Der Entwickler muss eben genau die Lebenzeiten seiner Objekte unter Kontrolle halten.
Wenn man sich die Lebenszeit eines Objekts als Rechteck vorstellt, dann besteht die Kunst darin, die Rechtecke so ineinander zu schachteln, dass sich die Grenzen nicht überschneiden.
Wenn es ein Objekt A gibt, dass von Objekt B und C benützt wird, dann wird einfach ein Objekt D benötigt, dass alle 3 Objekte in der richtigen Reihenfolge erzeugt und zerstört.
Und Probleme entstehen auch dadurch, dass häufig nicht erkannt wird, dass dieses Objekt D benötigt wird.
Und wenn Objekt A von B und C benötigt wird, dann wird A eben vor B und C erzeugt und nach B und C zerstört.

Globale Objekte stören diese Ordnung, da sie potentiell länger leben können als das Hauptformular.

[Bummi]

ich hatte bereits vor einiger Zeit in einem Thread von stahli (der sich seit längerem intensiv mit diesem Thema auseinanderzusetzen scheint) vorgeschlagen eine weitere Dereferenzierung vorzunehmen. Die "Zeiger" also global zu halten und nur noch Zeiger auf die "Zeiger" zu übergeben. Bei dieser Vorgehensweise müsste IMHO bei korrekter Implementierung alles wie gewünscht funktionieren.