Ausgedachtes System scheitert an Referenzzählen / Sichtbarkeiten

[Getox]

irgendwie fällt mir keine aussagekräftige Überschrift ein :( .Ich habe mir was ausgedacht und habe Probleme bei der Umsetzung.

Angenommen ich habe eine Klasse für Personen. Diese Klasse besitzt ein "Personenlager" vom Typen TObjectDictionary. Wenn ich jetzt eine Person aufrufen will, rufe ich die Klassenfunktion "getPersonByID" auf. Diese Funktion schaut erst im Lager, ob es das Personenobjekt bereits gibt. Wenn nicht wird es erzeugt und eingelagert. Anschließend wird die Referenz des Objektes rausgegeben.

Das mache ich aus 3 Gründen. Erstens ist es irgendwie Speichersparender, zweitens kann ich dann mit Hilfe der Connektoren, die ich im nächsten Absatz erkläre alle Edits synchronisieren und drittens reduziere ich so die Datenbankzugriffe um die Performance zu erhöhen.

Statt Strings verwende ich in dem Objekt Connektoren, die zum einen den String enthalten, aber bei denen man auch meine selbst entwickelten Edits registrieren kann, die mit dem String verknüpft werden sollen. Beispielsweise Name. Wenn ich jetzt ein Edit im Connector registriere, wird ein TNotifyEvent des Connectors an das Edit übergeben. Wenn sich nun das Edit ändert, wird auch der String verändert und dadurch auch der Inhalt aller anderen registrierten Edits. Außerdem signalisiert der Connector eine Wertänderung und kann sowohl den alten als auch den neuen Wert ausgeben.

Jetzt habe ich ein Problem mit der Freigabe der Objekte. Die Person soll aus dem Lager geworfen und freigegeben werden, wenn sie sonst nirgends mehr verknüpft ist. je nachdem wie oft ich die Person irgendwo hinterlegt habe, als Parameter übergebe oder in Funktionsvariablen nutze, kann ich irgendwann überhaupt nicht mehr feststellen, wie viele Referenzen denn nun irgendwo rumschwirren. Somit kann ich niemals gefahrlos die Person freigeben.

Um das zu verhindern habe ich ein Interface erstellt, dass alle Funktionen und Properties enthält, die das Personenobjekt nach außen anbieten muss. Das Personenobjekt habe ich von TInterfacedObject abgeletet statt von TObject und zusätzlich halt von diesem Interface. Jetzt erstelle ich das Objekt und caste es in das Interface und ab da funktioniert das Referencecounting. Die IDee ist, dass ich dann nur noch mit Interfaces arbeite statt Objekten. Somit ist mein Problem gelöst, aber es treten neue auf. Erstens muss ich jede Funktion doppelt deklarieren (Im Interface und im Objekt) und zweitens müssen die ganzen Getter und Setter für die Properties auch im Interface angegeben werden. Diese sind im Objekt private aber nach dem Casten zum Interface kann ich diese nutzen als wären sie Public. Das ist echt kaka.

Hat jemand eine Idee, wie ich mein Dilemma lösen kann?

[mjustin]

Setter und Getter die in einem Interface deklariert werden sind naturgemäß public - wie alles im Interface. Das kann man nicht vermeiden, stört aber auch nicht unbedingt. Dennoch würde ich Setter und Getter in der Klasse private deklariert lassen, damit der public Abschnitt kompakter (lesbarer) bleibt.

Ich arbeite in den meisten eigenen Projekten genau so und die Sichtbarkeit von Settern und Gettern ist kein "gravierender" Nachteil. Sie führt keine Risiken ein (da sich funktional nichts ändert). Die Vorteile durch Referenzzählung und Interfacebasierter Programmierng gleichen den Aufwand mehr als aus.

[stahli]

@Getox

Wie Du das beschreibst, so arbeite ich auch - und der unnötige Aufwand des redundanten Schreibens nervt mich ebenfalls.

Dass die Interfaces so umgesetzt sind wie sie halt sind (mit den zwingenden und öffentlichen Gettern und Settern) lässt sich verschmerzen.

Aber dass man so viel doppelt (und "exakt doppelt") schreiben muss, nervt mich.

Ich arbeite daher an einem https://www.delphipraxis.net/196493-unitoptimizer.html, der mir das abnehmen soll.

Ich bin gerade dabei, das Projekt nochmal neu und optimierter aufzubauen. Es existiert aber eine kleine Demo als aktuelle Umsetzung.

Falls Du es mal testen willst, schreib eine pm mit eMail-Adresse.

[peterbelow]

Zitat:

Zitat von stahli (Beitrag 1429100)

@Getox

Wie Du das beschreibst, so arbeite ich auch - und der unnötige Aufwand des redundanten Schreibens nervt mich ebenfalls.

Dass die Interfaces so umgesetzt sind wie sie halt sind (mit den zwingenden und öffentlichen Gettern und Settern) lässt sich verschmerzen.

Aber dass man so viel doppelt (und "exakt doppelt") schreiben muss, nervt mich.

Ich arbeite daher an einem https://www.delphipraxis.net/196493-unitoptimizer.html, der mir das abnehmen soll.

Ich bin gerade dabei, das Projekt nochmal neu und optimierter aufzubauen. Es existiert aber eine kleine Demo als aktuelle Umsetzung.

Falls Du es mal testen willst, schreib eine pm mit eMail-Adresse.

Mit den richtigen Tools muss man garnichts doppelt schreiben. Seht euch mal Modelmaker Code Explorer an. Da kann man z. B. das definierte Interface (oder einzelne Methoden davon) einfach im MMX Navigator auf die implementierende Klasse ziehen und MMX erzeugt die Methoden in der Klasse. Es geht auch anders herum: man kann erst die Klasse schreiben und dann das "Extract interface" refactoring verwenden, um das Interface zu erzeugen. Ohne MMX möchte ich echt nicht arbeiten :wink:.

[Getox]

Ich danke für eure Antworten. Ich werde dann wohl mit Interfaces arbeiten und das doppelte Schreiben in Kauf nehmen. Und ja... im grunde ist es ja richtig, dass es nicht schlimm ist, auf getter und setter zugreifen zu können. Das tut man ja im Grunde auch über die Property.

Drittanbieter-Tools zu nutzen ist mir hier leider nicht erlaubt, aber danke für die Hinweise :)

[TiGü]

Zitat:

Zitat von Getox (Beitrag 1429243)

Drittanbieter-Tools zu nutzen ist mir hier leider nicht erlaubt, aber danke für die Hinweise :)

Auch wenn das kostenlos ist?

[stahli]

Dazu auch noch eine Anmerkung:

Ein Codeformatierer (egal welcher und ob kostenfrei oder kostenpflichtig) generiert ja keine Abhängigkeiten für das Projekt.
Wenn der Formatierer irgendwann nicht mehr korrekt funktioniert und z.B. gelöscht werden müsste, könnte der Projektcode ja unverändert weiter verwendet und von Hand gepflegt werden.

Das sollte also im Sinne der Produktivität evtl. noch einmal überdacht werden - bei Frameworks oder Komponenten von Drittanbietern wäre die Entscheidung dagegen schon sehr viel eher nachvollziehbar.