Intelligente Objekte - automatische Freigabe von Referenzen

[Stevie]

Fakt bei Delphi Interfaces sind folgende Dinge (zumindest meinem Verständnis und meinen Erfahrungen nach):

• wenn man mit Interfaces arbeitet sollte man tunlichst vermeiden auf die Objekte dahinter zuzugreifen und noch viel mehr, Objekt und Interface Referenzen zu vermischen
• wenn man sich auf das Programmieren gegen Interfaces entscheidet braucht man entweder RefCounting oder eine andere Art des Memory Managements (z.B. die von TComponent oder eines DI Container)
• man braucht einen rein hierarchischen Objectgraph. Doppelt verlinkte oder zirkuläre Referenzen sind komplett zu vermeiden, da sonst das RefCounting komplett das Freigeben verhindert
• weicht man vom RefCounting ab, kann es zu "dangling pointers" kommen

Behält man das jederzeit im Hinterkopf, kann man eine Menge Freude an Interfaces haben - die Nichtbeachtung birgt eine große Anzahl an möglichen Problemen.

[bernau]

Kommt in meinem Code nicht wirklich oft vor, daß ein Objekt zwei Variablen (V1,V2) zugeordnet ist und aus dem Grund eine (V1) auf NIL steht und die andere (V2) nicht.

Ich habe da aber keinen großen Aufwand getrieben. Eine TObjectlist angelegt und jedes erzeugte Objekt in die TObjectlist geschrieben. Beim freigeben aus der TObjectlist wieder herausgelöscht. Wenn ich wissen wollte, ob das Objekt noch vorhanden ist, dann einfach in der Objektliste nachgeschaut. Ganz sicher ist diese Lösung natürlich nicht, denn Wenn ein Objekt (V1) freigegeben wird und ein Objekt erzeugt wird, was zufällig die gleiche Speicheradresse wie V2 hat, dann zeigt V2 zwar auf ein gültiges Objekt, aber eben nicht auf das ursprüngliche. Ist bisher aber nie passiert

[Patito]

Zitat von Stevie:

Fakt bei Delphi Interfaces sind folgende Dinge (zumindest meinem Verständnis und meinen Erfahrungen nach):

• wenn man mit Interfaces arbeitet sollte man tunlichst vermeiden auf die Objekte dahinter zuzugreifen und noch viel mehr, Objekt und Interface Referenzen zu vermischen
• wenn man sich auf das Programmieren gegen Interfaces entscheidet braucht man entweder RefCounting oder eine andere Art des Memory Managements (z.B. die von TComponent oder eines DI Container)
• man braucht einen rein hierarchischen Objectgraph. Doppelt verlinkte oder zirkuläre Referenzen sind komplett zu vermeiden, da sonst das RefCounting komplett das Freigeben verhindert
• weicht man vom RefCounting ab, kann es zu "dangling pointers" kommen

Behält man das jederzeit im Hinterkopf, kann man eine Menge Freude an Interfaces haben - die Nichtbeachtung birgt eine große Anzahl an möglichen Problemen.

Zu Punkt 1:
Sobald man aber ein wenig tiefer in die Objektorientierung eintaucht und es mit diversen Design-Patterns zu tun bekommt wird das so nicht mehr funktionieren. Dieses "nicht mischen" von Objekt und Interface-Referenzen ist eine blöde Idee die vermutlich Leute erfunden haben, die mit aller Gewalt die Design-Fehler von Delphi als "as designed" verteidigen wollten. (Kommt das von Joanna Carter mit ihrer unsinnigen Goldenen Regel?!?). Im allgemeinen kastriert man sich damit die Anwendungsfälle von Interfaces so gewaltig weg, dass es so richtig wehtut.
Warum sollte z.B. ein Objekt das ein Interface unterstützt, mit dem ein Logger alle paar Tage mal ein paar Daten auslesen kann sich plötzlich automatisch zerstören nur weil gerade mal kein Logger an den Daten interessiert ist (RefCount Logger-Interface = 0)?!

Punkt 2:
Es ist auf jeden Fall richtig, dass man nicht verschiedene Arten des Memory-Managements für dasselbe Objekt mischen sollte. Ref-Counting ist für reine Daten-Typen ganz gut und für Objekte nur bei ganz simplen Objekt-Graphen sinnvoll.

Punkt 3:
Wenn man sich auf Ref-Counting einläßt muß man halt darunter leiden... Wenn man das Ref-Counting wie in TComponent so gut es geht abschaltet, kann man sich auch auf etwas kompliziertere Objekt-Graphen einlassen. Man muß dabei nur beachten, dass man bevor man ein Objekt freigibt alle Interface-Referenzen auf das Objekt eliminieren muß.

Insgesamt habe ich schon viel zu oft so Sätze vom "Objekt und Interfaces nicht mischen" und dem "immer im Hinterkopf behalten von irgendwelchen unsinnigen Regeln" gelesen, dass ich's langsam zum kotzen finde...

[neo4a]

Zitat von Patito:

.

Fullquote und eine Liste simpler, bekannter Regeln mit ein paar deftigen, aber inhaltsarmen Sprüchen "umrahmen" ... ich glaube, Du schaffst es nicht auf die Liste meiner Lieblingsprosa. Zumal (zumindest mir) nicht klar wird, worauf Du mit Deiner Tirade überhaupt hinaus willst.

BTW, wenn Du Deinem Logger-Interface eine Referenz in z.B. einem Singleton-Object verschaffst, wird es sich auch in Wochen nicht selbst zerstören. Wäre halt deftiges Design, statt deftiger Sprüche.

[implementation]

Ihr redet vollkommen aneinander vorbei. Patito bemängelt, dass Interfaces in Delphi anders umgesetzt sind, als sie in anderen Sprachen konzipiert sind - nämlich viel zu COM-orientiert.
Stevie verteidigt hingegen den praktischen Nutzen dieser "Falschumsetzung".

Zitat von neo4a:

BTW, wenn Du Deinem Logger-Interface eine Referenz in z.B. einem Singleton-Object verschaffst, wird es sich auch in Wochen nicht selbst zerstören. Wäre halt deftiges Design, statt deftiger Sprüche.

Singleton = globale Variable = nicht schön.
Interfaces wären hier tatsächlich um einiges angebrachter, hätte man da nicht die völlig unangebrachte Referenzzählung ins Spiel gebracht.

In Delphi heißt "Interface" immer "COM-Objekt". Wenn man dann Interfaces mal so benutzen will, wie in andern Sprachen problemlos möglich, knallts, weil sich die Speichermodelle vermischen.
Natürlich kann man sich das ganze jetzt zu Nutzen machen und Frameworks darauf basieren lassen.

[neo4a]

Zitat von implementation:

Zitat von neo4a:

BTW, wenn Du Deinem Logger-Interface eine Referenz in z.B. einem Singleton-Object verschaffst, wird es sich auch in Wochen nicht selbst zerstören. Wäre halt deftiges Design, statt deftiger Sprüche.

Singleton = globale Variable = nicht schön.

Singleton = DI-Container-Referenz = schon besser

[stahli]

Da ich ja auch direkt angesprochen war, will ich auch mal...

Ich habe bisher mit persistenten Objekten gearbeitet, die die gesamten Daten sowie die BL enthielten und beliebig komplex aufeinander verweisen konnten.
So konnte ein Personenobjekt ("A.Stahl") von mehreren Vereinsmitglied-, Spieler- und Schiedsrichterobjekten referenziert werden.

Öffnet der User ein neues Turnier, werden alle Objekte aufgelöst und neue erzeugt. Über die Owner-Beziehungen wird die Datenstruktur definiert.

Nun könnte eine referenzierte Person ("A.Stahl") u.U. irgendwann aufgelöst werden (abgesehen davon, dass das die BL natürlich ggf. auch verhindert).
In einem solchen Fall wollte ich gern, dass die betreffenden Personenreferenzen automatisch genilt werden.

Meine Überlegung war auch, dass Neulinge der OOP intuitiv davon ausgehen, dass solche Referenzen NIL werden. Das Objekt ist ja halt "weg".

Natürlich ist es möglich (das war mir auch damals klar), die Referenzen extra zu verwalten und Referenzen explizit zu nilen. Ich hätte mir jedoch eine Compilerlösung gewünscht, die das automatisch regelt.

Soviel zum einfachen Anliegen.


Inzwischen habe ich mich mit ein wenig mit Interfaces beschäftigt und will künftig auch mit diesen arbeiten.

Dann will ich an zentraler Stelle Interfaces abrufen können (z.B. IPerson(123)), die die Objekte erzeugt und verwaltet und die abgefragten Schnittstellen heraus gibt. Wird ein Objekt länger nicht benötigt, kann es aus einer Liste innerhalb der zentrale freigegeben und damit aufgelöst werden.


Ich will also künftig i.d.R. keine festen Verbindungen zwischen den Objekten mehr haben. Statt einer festen Referenz "Player.Person" würde künftig eine Personeninterface anhand der PersonenID abgefordert werden.
(So lässt sich auch eine DB vernünftig nutzen und es müssen nicht alle Daten komplett im Hauptspeicher liegen.)


Insofern hat sich das Problem für mich eigentlich erledigt (sofern ich das später alles so umsetzen kann, wie eben beschrieben).


Bei der klassischen RefCount-Nutzung der Interfaces stört mich eigentlich, dass man noch auf das dahinter liegende Objekt zugreifen kann, obwohl es eigentlich schon aufgelöst sein sollte (weil irgendwo noch eine Referenz "hängen geblieben ist"). Ich könnte also ggf. fleißig weiter auf eine Person zugreifen deren RefCount noch nicht bei 0 liegt, obwohl bereits ein neues Turnier geöffnet wurde). Der Zugriff auf ein aufgelöstest und geniltes Objekt würde wenigstens einen sichtbaren Fehler erzeugen.


Fazit: Man sollte Objekte bzw. Interfaces möglichst an einer zentralen Stelle anfordern und verwalten und auf feste (dauerhafte) Referenzen möglichst verzichten. Das scheint mir (nach meiner aktuellen Einschätzung) am sinnvollsten zu sein.


(Aber ich lerne als Hobbyprogrammierer halt immer nur stückweise aus meinen eigenen Fehlern. Vielleicht sehe ich das bald schon wieder anders )


EDIT @implementation:Was ist denn der wesentliche Unterschied von Delphi-Interfaces zu Interfaces anderer Sparachen?

[implementation]

Zitat von stahli:

EDIT @implementation:Was ist denn der wesentliche Unterschied von Delphi-Interfaces zu Interfaces anderer Sparachen?

Interfaces an sich bedeuten erst einmal nur, dass ein gemeinsamer Nenner definiert wird, den alle implementierenden Objekte haben sollen.
Angenommen du hast ein Handtuch und ein Auto. Was haben die gemeinsam? Man kann sie trocknen. Also implementieren sie beide ITrockenbar.
Nun kann es also irgendwo eine Prozedur Trocknen geben, die ein solches ITrockenbar als Parameter will.

In Delphi muss man sich dann auch als Aufrufer höllische Gedanken über die Speicherverwaltung machen. Sowas ginge dann schief:

Delphi-Quellcode:

var a: TAuto; h: THandtuch;
begin
  ...
  try
    ...
    Trocknen(a); // Huppsala
    ...
  finally
    ...
  end;
end;

Stattdessen muss man sich dann damit behelfen, komplett nur Interfaces zu nutzen.
Da Objekte und Interfaces aber zur Interaktion konzipiert sind, ist es vollkommener Humbug, beiden verschiedene Speichermodelle zu geben. *
Entweder beide manuell freigegeben, oder beide referenzgezählt (->Vala), oder auch für alles GC (->Java,.Net)



* der FPC kennt mittlerweile {$interfaces corba} , wo die Interfaces auf Referenzzählung und sonstige COM-Last verzichten. Könnte Emba auch mal einführen.

[Robotiker]

Hallo,

wenn ich diesen Thread so lese, denke ich der Umgang mit VCL-Objekten ist im C++ Builder in diesem Sinne einfacher geregelt. Da ist z.B. sowas üblich

Code:

void __fastcall TfrmMain::btnTestClick(TObject *Sender)
{
    scoped_ptr<TStringList> list(new TStringList);
 
    list->Add(L"Eins"); 
    list->Add(L"Zwei");
    list->Add(L"Drei");
}

Wenn die Funktion verlassen wird, auch über eine Exception, löscht der Smartpointer die Stringlist.

Zitat von stahli:

Meine Überlegung war auch, dass Neulinge der OOP intuitiv davon ausgehen, dass solche Referenzen NIL werden. Das Objekt ist ja halt "weg".

Natürlich ist es möglich (das war mir auch damals klar), die Referenzen extra zu verwalten und Referenzen explizit zu nilen. Ich hätte mir jedoch eine Compilerlösung gewünscht, die das automatisch regelt.

Das wäre dann ein Fall für shared_ptr und weak_ptr, erstere sind referenzzählend, letztere werden ungültig, wenn kein shared_ptr mehr auf "ihr" Objekt zeigt.

Das Anlegen sähe, wenn der Compiler schon C++11 könnte, dann so aus:

Code:

  auto liste = make_shared(new TStringList);

(Das auto ermittelt den Typ der Variable entsprechend dem Ausdruck auf der rechten Seite der Zuweisung.)

[himitsu]

Und wie verwaltet corba dann die Referenzen?