Argthtjtr

Lets say I have a few classes that looks a bit like these:

This class I'll call the parent instance:

public class Foo : Disposable {

    public Foo() {

        Bars = new List<Bar>();

        FullPath = string.empty;

    }

    public Foo(string szInfo) {

        Bars = new List<Bar>();

        ImportantInfo = szInfo;

    }

    ~Foo() => this.Dispose(false);

    /* IDisposible stuff cropped for simplicity */



    public string ImportantInfo {get; internal set;}

    public List<Bar> Bars {get; internal set;}



    public void SomeContainerLoadMethod() {

        /* Add some bars here */

        Bars.Add( new Bar() );

        Bars.Add( new Bar() );

        /* etc... */

    }

}

As you can see here, the parent instance Foo holds onto some Bar classes.
I'll call these Bar classes in the List<Bar> the child instance containers in this question. Here's the definition of the Bar class in the example code way:

public class Bar : Disposable {

    Bar() { }

    ~Bar() => this.Dispose(false);

    /* IDisposable stuff cropped for simplicity */



    public string CoolBuff {get; internal set;}



    public void SomeCoolStringBufMethod() {

        /* Do something to populate CoolBuff, but I need ImportantInfo! */

    }

}

How would I access ImportantInfo from the parent instance , in the child instance container's SomeCoolStringBufMethod() ?

Here are the complications to this problem:

1. Doing it without having to make a duplicate ImportantInfo property and pass it into the child instance container's constructor


2. Doing it without having to pass ImportantInfo in as an argument when the child instance's SomeCoolStringBufMethod() method is called from
   the parent .

Is this possible, say with System.Reflection, to 'look up' the fact a Bar is a member of a Foo, and fetch Foo's ImportantInfo property ?

You can't.

The two options you list are really the only way to do it.

Remember that any class instance exists at an address in memory. Variables just tell your application where to look in memory for the data. So sure, you can use reflection to find the ImportantInfo property of an instance of Foo, but which instance? Where should it look for it in memory? You have to know where in memory to look.

You know where in memory to look by using a variable. So you need to pass a variable to Bar somehow.

If there was a way to use reflection to find every active instance of a class, you could use that to figure it out in a round-about way, but there is no way to do that.

A small note: when you pass a string to a method, you aren't creating a duplicate. More on that here if you're interested.

Short Answer is NO.

Long Answer is Theoretically Yes, but Practically No.

Because you Bar have no reference to Foo at all, so you can't even tell which Foo contain your Bar, you can't even tell if your Bar is referenced by any Foo at all.

In order to figure that all , you have to trace back who is referencing your Bar.

In Theory it could be done using technique like GC,but GC does reference search from Top to Bottom which means from GC root to Foo then to your Bar , is doesn't do Bottom to Top. You can build your external double linked GC like Foo,Bar Graphic.

In Practice this will take you huge amount of effort, after that, you are also facing the Challenge to manage your own GC cycle of your Foo``Bar graphic.

So Short Answer is NO.

Number two is the way to go. (And no, I'm not trying to be funny.)

...pass ImportantInfo in as an argument when the child instance's SomeCoolStringBufMethod() method is called from the parent.

Methods are how classes interact with each other. Having a reference to another object is merely a means to the end of being able to call its methods and access its properties.

There's good reasons why we don't usually create classes with circular references between them. Imagine, for example, Text.StringBuilder. What if it had a reference to the class that created it, regardless of how it obtained that reference - via the constructor, reflection, or anything else.

What would StringBuilder do with that reference? In order to do anything with that object other than call ToString() it would need to know the type of that object. But if it knows the type of that object then it implies that StringBuilder only works if it has a reference to that type of object. That means the class that depends on StringBuilder and StringBuilder can only be used in conjunction with each other.

Relating that back to your class: What does your child class need? Does Bar need a Foo? No. It needs a string. Any class that calls its method can give it a string. So why couple it to another class? One day you or someone else will need to make Bar work without a Foo and then you'll have a knot to untie.

If Bar depends on a Foo to get its ImportantProperty, that also makes unit testing very difficult. You'd have to create a Foo and then create a Bar so that the Bar can get its ImportantProperty from the Foo. If it depends on a string then it's easy to test. The test only has to create a string.

In your example, passing ImportantProperty to a Bar constructor wouldn't make sense because it's a writable property of Foo. That means Foo can change it, and then all the Bars will have a different property unless you create all new ones. (Perhaps the fact that ImportantProperty can change is the reason why you want a reference back to the parent, but passing a string to a method call still solves that problem.)

You can almost certainly make this work without the child containing its own reference to the parent. If it must have that reference then it would make sense to pass that reference to the constructor of the child.