Entwickler-Ecke
Basistechnologien - Übergeordnetes (Parent-) Objekt ermittlen
C# - Mo 28.03.16 18:42
Titel: Übergeordnetes (Parent-) Objekt ermittlen
Hey @ll,
ich suche einen (halbwegs) eleganten Weg um das Objekt das einen Typ instanziiert von diesem Typ aus zu ermitteln ohne dass das Objekt bekannt ist.
Und jetzt nochmal verständlich :mrgreen::
Ich habe ein Typ A und ein Typ B. Ein Objekt vom Typ A erzeugt intern irgendwo ein Objekt vom Typ B. Gibt es einen weg, dass das Objekt B über die Existenz von Objekt A informiert wird, aber ohne das Objekt im Konstruktor zu übergeben.
C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
| class A
{
void DoSth()
{
B child = new B(this)
}
} |
Die markierte Stelle wollte ich vermeiden. Ich dachte an sowas in der Art CallerMemberNameAttribute, nur halt für das ganze Objekt statt für den Membernamen.
Ralf Jansen - Mo 28.03.16 18:50
Nein es gibt kein Konzept von Parent, Owner, Creator oder sonstwas zwischen normalen Klassen. Wenn du sowas brauchst musst du es ausprogrammieren.
C# - Mo 28.03.16 18:55
Ja das dachte ich mir schon... schade.
Danke für die fixe Antwort.
Palladin007 - Mo 28.03.16 21:51
Wenn Du die Instanz nicht brauchst, dann kannst Du über den StackTrace heraus finden, in welchem Member der Aufruf statt gefunden hat.
Ob man die Instanz darüber auch heraus finden kann, weiß ich nicht.
Aber überleg dir das gut, das ist langsam und schreit für mich nach ganz schlechtem Stil :D
C# - Di 29.03.16 11:29
:mrgreen: Ja aus diesem Grund wollte ich StackTrace und Reflection vermeiden. Ich werds wohl einfach über den Konstruktor machen (wie ich oben gesagt hab dass ich es nicht tun will :D)
Palladin007 - Di 29.03.16 17:43
Ist auch der beste Weg :D
Oder Du findest raus, wie WPF es macht, die machen das weder über den Konstruktor noch über eine Property.
So auf die Schnelle hab ich aber nicht ganz den Überblick gefunden, wie das da abläuft :D
Ralf Jansen - Di 29.03.16 17:49
| Zitat: |
| Ist auch der beste Weg :D |
Der ~beste~ Weg wäre erst gar nicht new zu brauchen. Also irgendeines der vielen Factory Patterns am Start zu haben das einem ein neues Object gibt mit irgendwelchen darauf wirkenden Strategien.
Dann hat man das auch soweit zentralisiert das man keine Angst haben muss einen neuen Konstruktorparameter an allen möglichen Stellen hinzufügen zu müssen der einem den schönen Code ~kaputt~ macht.
C# - Di 29.03.16 17:56
Das Factory Pattern wende ich sogar an :mrgreen:. Vielleicht gibt's ja auch ne bessere Lösung für mein eigentliches Vorhaben. Es soll nämlich nur ein Progress Reporter an ein Objekt angehängt werden, welches ein Interface implementiert. Ich könnte natürlich auch den Progress Reporter ins interface packen aber so ganz elegant erscheint mir das auch nicht...
// Edit
Get rekt Palladin :D (sorry musste jetzt einfach sein)
Ralf Jansen - Di 29.03.16 18:17
Nun ja wenn das Progress Reporter Object nur von deiner Factory setzbar ist wäre mir eher egal ob per Konstruktor oder Property Injection im Object landet. Allgemein würde ich es per Property vorziehen nur wenn ich das Object auch schon im Konstruktor brauche dann würde ich das über den Konstruktor machen.
Palladin007 - Di 29.03.16 18:28
Über eine Property greifst Du darauf zu, ja, gesetzt wird es aber irgendwie anders. Hab erst gedacht, es wäre ein internal set, war aber falsch gedacht.
| Zitat: |
| Get rekt Palladin :D (sorry musste jetzt einfach sein) |
Ich muss gestehen: Ich habe keine Ahnung, was Du damit sagen willst :D
Th69 - Di 29.03.16 18:57
Das passiert (intern) mittels AddVisualChild / AddLogicalChild.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!
Th69 hat folgendes geschrieben 
: