AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Intelligente Objekte - automatische Freigabe von Referenzen
Thema durchsuchen
Ansicht
Themen-Optionen

Intelligente Objekte - automatische Freigabe von Referenzen

Ein Thema von Thom · begonnen am 5. Mär 2012 · letzter Beitrag vom 7. Mär 2012
Antwort Antwort
Seite 2 von 3     12 3      
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.016 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#11

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 11:53
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Benutzerbild von bernau
bernau

Registriert seit: 1. Dez 2004
Ort: Köln
1.295 Beiträge
 
Delphi 12 Athens
 
#12

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 13:06
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
Gerd
Kölner Delphi Usergroup: http://wiki.delphitreff.de
  Mit Zitat antworten Zitat
Patito

Registriert seit: 8. Sep 2006
108 Beiträge
 
#13

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 13:23
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...
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#14

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 14:20
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.
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von implementation
implementation

Registriert seit: 5. Mai 2008
940 Beiträge
 
FreePascal / Lazarus
 
#15

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 16:42
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".

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.
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#16

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 16:54
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
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.343 Beiträge
 
Delphi 11 Alexandria
 
#17

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 17:20
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?
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von implementation
implementation

Registriert seit: 5. Mai 2008
940 Beiträge
 
FreePascal / Lazarus
 
#18

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 17:40
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.
  Mit Zitat antworten Zitat
Robotiker
(Gast)

n/a Beiträge
 
#19

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 18:09
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.

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.)

Geändert von Robotiker ( 5. Mär 2012 um 18:30 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.071 Beiträge
 
Delphi 12 Athens
 
#20

AW: Intelligente Objekte - automatische Freigabe von Referenzen

  Alt 5. Mär 2012, 18:26
Und wie verwaltet corba dann die Referenzen?
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 3     12 3      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:05 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz