Referenzen auf Objekt ermitteln

[hofi]

hallo,

kennt jemand ein framework, pattern oder was auch immer um von einem objekt aus alle referenzen darauf abzufragen?

konkret: was ich nicht machen will:

class ClassA
{
    public ClassB classB;
}


class ClassB
{
    public List refobjects = new ArrayList()

    public List getRefObjects ()
    {
         return refobjects;
    }
}

class Test
{
    public static void main (String [] args)
    {
         ClassA a = new ClassA();
         ClassB b = new ClassB();

         a.classB = b;
         b.refobjects.add(a);  -- sollte nicht nötig sein
         .......
         a.classB = null;
         b.refobjects.remove(b); -- sollte nicht nötig sein
    }
}

mit aop (spring aop oder aspectj) wäre es ja sicher möglich dieselbe funktionalität zu ermöglichen ohne "b.refobjects.add(a)" gibt es da bereits eine fertiglösung?

der garbagecollector muss die referenzen ja auch kennen, gibt es da irgendeine möglichkeit darauf zuzugreifen?

thanxxxxxxxxxxxxxxxxxx

 

[Wildcard]

Ist das für deinen Programmfluss oder für Debugging?

Wenn es für deinen Programmfluss ist:
Warum? Eigentlich gibt es keinen Grund das ein Objekt wissen sollte wer es referenziert.
Vermutlich lässt es sich dennoch über MBeans bzw. MXBeans herausfinden.

Für Debugging:
Die IDE deiner Wahl sollte in der Lage sein dir diese Information zur Laufzeit anzuzeigen.
Wenn nicht, hast du wohl die falsche IDE :wink:

 

[Guest]

erst mal danke für die antwort.

nein es ist nicht fürs debugging und jmx ist auch nciht umbedingt mittel der wahl ;-)

ein beispiel, bei dem dieses feature hilfreich wäre sind hierarchische aufgebaute objektgraphen.
bsp. in einer buchhaltungsanwendung hast du zum beispiel eine anwendung (als Frame), mehrere buchhaltungen (als internal frames), mehrere Journale für die Buchungen (als JTables) und darin mehrere Buchungen (im Model der JTable).

wenn der objektgraph von der wurzel aus aufgebaut wird, kannst du zwar von dem anwendungs (-singleton) anwendungsobjekt zu jeder buchung navigieren, du kannst für eine buchung aber nicht direkt bestimmen zu welcher buchhaltung eine buchung gehört.

code:

....buchhaltung b = new Buchhaltung();
....buchung bu = new Buchung();
....b.add(bu);

was ich sparen will ist:
....bu.setBuchhaltung(b) // oder gleich im Konstruktur übergeben

aber ohne kann ich von der buchung nicht die dazugehörige buchhaltung bestimmen.

geht mir auch ein wenig um das prinzip der self-awareness (sorry für den ausdruck): ein mensch weiss zum beispiel bei welchem freund er gerade zu besuch ist, ein objekt hat keine ahnung von welchen anderen objekten es gerade referenziert wird.

 

[Wildcard]

Ein Mensch besucht aber auch nicht gleichzeitig 100 verschiedene Leute an verschiedenen Orten.
Da es dir schlicht um eine Datenstruktur geht verwende den klassichen Ansatz oder überdenke deinen Design.
Wenn du diesen Pfad weitergehen möchtest machst du dich unglücklich.
Warum sollte eine Buchung wissen wer sie verwaltet?

 

[Guest]

ok,

das beispiel war nicht besonders gut und der vergleich hinkt zugegebenerweise auch ein wenig.
und ja: das design entsteht wenn ich privat etwas mache on the fly (und ja ich
weiss :noe: ). dabei ist es mir eben einfach schon mehr einmal passiert, dass dann irgendwann so eine "rückwärts" referenz gefehlt hat. klar lässt sich das mit den refactoring methoden von eclipse oder netbeans relativ schnell lösen lässt, aber mühsam ist es troztdem.

anyway
:toll:

 

[Wildcard]

Da du deinen Anwendungsfall nicht sehr gründlich beschreibst, bleibt nur der allgemeine Tipp, dass du dich mit Entwurfsmustern beschäfigen solltest.

 

[Guest]

ja eben ich hab im ersten post geschrieben ein pattern dafür sei mir auch mehr als recht, nur kenn ich eben keins ;-) ausser jedesmal im konstruktor oder nachher eine referenz mitzugeben. das gefällt mir aber nicht so ganz weil es extrem schnell vergessen geht und man dann während der laufzeit evt. irgendwann eine nullpointer exception kriegt
:autsch:

 

[AlArenal]

Das sind eben die Probleme, welche man sich mit miesem Design einhandelt. Hättest du vorher mehr Zeit ins Design investiert, hätte sich diese Investition spätestens jetzt ausgezahlt.

Deine Anwendung jetzt mit irgendeiner von hinten durch die Brust ins AUge geschossenen Lösung zusätzlich zu verkomplizieren, wäre bestensfalls eine sehr kurzfristige Lösung.

Schonmal von KISS gehört?

 

[Wildcard]

Weniger wegen deiner Rückwärtsreferenz. Vielmehr ist die Frage, ob nicht eine völlig andere Herangehensweise sinnvoll ist.
Wie gesagt, ohne genaue Informationen ist dazu nichts weiter zu sagen.