Accessing a parent instance's properties?
up vote
-1
down vote
favorite
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:
- Doing it without having to make a duplicate
ImportantInfo
property and pass it into the child instance container's constructor - Doing it without having to pass
ImportantInfo
in as an argument when the child instance'sSomeCoolStringBufMethod()
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 ?
c# class instance system.reflection
add a comment |
up vote
-1
down vote
favorite
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:
- Doing it without having to make a duplicate
ImportantInfo
property and pass it into the child instance container's constructor - Doing it without having to pass
ImportantInfo
in as an argument when the child instance'sSomeCoolStringBufMethod()
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 ?
c# class instance system.reflection
2
Bar
contains no reference toImportantInfo
and also no reference toFoo
. Therefore, this is impossible. In order forBar
to get atImportantInfo
, you must give it something that it can trace back to it, whether theImportantInfo
itself or an instance of an object that references it.
– laptou
Nov 22 at 0:08
add a comment |
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
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:
- Doing it without having to make a duplicate
ImportantInfo
property and pass it into the child instance container's constructor - Doing it without having to pass
ImportantInfo
in as an argument when the child instance'sSomeCoolStringBufMethod()
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 ?
c# class instance system.reflection
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:
- Doing it without having to make a duplicate
ImportantInfo
property and pass it into the child instance container's constructor - Doing it without having to pass
ImportantInfo
in as an argument when the child instance'sSomeCoolStringBufMethod()
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 ?
c# class instance system.reflection
c# class instance system.reflection
asked Nov 21 at 23:48
Robert Smith
109110
109110
2
Bar
contains no reference toImportantInfo
and also no reference toFoo
. Therefore, this is impossible. In order forBar
to get atImportantInfo
, you must give it something that it can trace back to it, whether theImportantInfo
itself or an instance of an object that references it.
– laptou
Nov 22 at 0:08
add a comment |
2
Bar
contains no reference toImportantInfo
and also no reference toFoo
. Therefore, this is impossible. In order forBar
to get atImportantInfo
, you must give it something that it can trace back to it, whether theImportantInfo
itself or an instance of an object that references it.
– laptou
Nov 22 at 0:08
2
2
Bar
contains no reference to ImportantInfo
and also no reference to Foo
. Therefore, this is impossible. In order for Bar
to get at ImportantInfo
, you must give it something that it can trace back to it, whether the ImportantInfo
itself or an instance of an object that references it.– laptou
Nov 22 at 0:08
Bar
contains no reference to ImportantInfo
and also no reference to Foo
. Therefore, this is impossible. In order for Bar
to get at ImportantInfo
, you must give it something that it can trace back to it, whether the ImportantInfo
itself or an instance of an object that references it.– laptou
Nov 22 at 0:08
add a comment |
3 Answers
3
active
oldest
votes
up vote
1
down vote
accepted
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.
LeY provided a bit more info about GC tracing in regards to memory but you where the first to answer. You're both right in this case. It doesn't seem practical nor savvy at runtime to try and search through memory to find theFoo
class attached to theBar
. I'll sadly have to stick to passing in either an argument toBar
's method or sharingImportantInfo
with Bar via its constructor. Though I feel like shared items for instantiated elements within a class's scope should be a thing guess that's not how this works, sadly.
– Robert Smith
Nov 22 at 3:13
You also mentioned passing them by reference instead to save the memory. In this case my logic in thinking was to save memory say, if I needed to share a large buffer or something with a class. Passing by reference remedies that worry in the way I was thinking about things.
– Robert Smith
Nov 22 at 3:17
Right. Just make sure you understand how passing by reference works since you can pass a reference by value, or pass a reference by reference (usingref
), and the effects can be different if you're not careful. That article I linked to explains it.
– Gabriel Luci
Nov 22 at 13:39
add a comment |
up vote
1
down vote
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.
Think it would ever be practical to include objects a child class like this would inherit and be able to use ? I'm speaking from MS's point of view on all that. Of course what I'm asking probably isn't the smartest way of doing such things either.
– Robert Smith
Nov 22 at 3:07
add a comment |
up vote
0
down vote
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'sSomeCoolStringBufMethod()
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 Bar
s 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.
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
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.
LeY provided a bit more info about GC tracing in regards to memory but you where the first to answer. You're both right in this case. It doesn't seem practical nor savvy at runtime to try and search through memory to find theFoo
class attached to theBar
. I'll sadly have to stick to passing in either an argument toBar
's method or sharingImportantInfo
with Bar via its constructor. Though I feel like shared items for instantiated elements within a class's scope should be a thing guess that's not how this works, sadly.
– Robert Smith
Nov 22 at 3:13
You also mentioned passing them by reference instead to save the memory. In this case my logic in thinking was to save memory say, if I needed to share a large buffer or something with a class. Passing by reference remedies that worry in the way I was thinking about things.
– Robert Smith
Nov 22 at 3:17
Right. Just make sure you understand how passing by reference works since you can pass a reference by value, or pass a reference by reference (usingref
), and the effects can be different if you're not careful. That article I linked to explains it.
– Gabriel Luci
Nov 22 at 13:39
add a comment |
up vote
1
down vote
accepted
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.
LeY provided a bit more info about GC tracing in regards to memory but you where the first to answer. You're both right in this case. It doesn't seem practical nor savvy at runtime to try and search through memory to find theFoo
class attached to theBar
. I'll sadly have to stick to passing in either an argument toBar
's method or sharingImportantInfo
with Bar via its constructor. Though I feel like shared items for instantiated elements within a class's scope should be a thing guess that's not how this works, sadly.
– Robert Smith
Nov 22 at 3:13
You also mentioned passing them by reference instead to save the memory. In this case my logic in thinking was to save memory say, if I needed to share a large buffer or something with a class. Passing by reference remedies that worry in the way I was thinking about things.
– Robert Smith
Nov 22 at 3:17
Right. Just make sure you understand how passing by reference works since you can pass a reference by value, or pass a reference by reference (usingref
), and the effects can be different if you're not careful. That article I linked to explains it.
– Gabriel Luci
Nov 22 at 13:39
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
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.
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.
edited Nov 22 at 0:29
answered Nov 22 at 0:19
Gabriel Luci
8,30311122
8,30311122
LeY provided a bit more info about GC tracing in regards to memory but you where the first to answer. You're both right in this case. It doesn't seem practical nor savvy at runtime to try and search through memory to find theFoo
class attached to theBar
. I'll sadly have to stick to passing in either an argument toBar
's method or sharingImportantInfo
with Bar via its constructor. Though I feel like shared items for instantiated elements within a class's scope should be a thing guess that's not how this works, sadly.
– Robert Smith
Nov 22 at 3:13
You also mentioned passing them by reference instead to save the memory. In this case my logic in thinking was to save memory say, if I needed to share a large buffer or something with a class. Passing by reference remedies that worry in the way I was thinking about things.
– Robert Smith
Nov 22 at 3:17
Right. Just make sure you understand how passing by reference works since you can pass a reference by value, or pass a reference by reference (usingref
), and the effects can be different if you're not careful. That article I linked to explains it.
– Gabriel Luci
Nov 22 at 13:39
add a comment |
LeY provided a bit more info about GC tracing in regards to memory but you where the first to answer. You're both right in this case. It doesn't seem practical nor savvy at runtime to try and search through memory to find theFoo
class attached to theBar
. I'll sadly have to stick to passing in either an argument toBar
's method or sharingImportantInfo
with Bar via its constructor. Though I feel like shared items for instantiated elements within a class's scope should be a thing guess that's not how this works, sadly.
– Robert Smith
Nov 22 at 3:13
You also mentioned passing them by reference instead to save the memory. In this case my logic in thinking was to save memory say, if I needed to share a large buffer or something with a class. Passing by reference remedies that worry in the way I was thinking about things.
– Robert Smith
Nov 22 at 3:17
Right. Just make sure you understand how passing by reference works since you can pass a reference by value, or pass a reference by reference (usingref
), and the effects can be different if you're not careful. That article I linked to explains it.
– Gabriel Luci
Nov 22 at 13:39
LeY provided a bit more info about GC tracing in regards to memory but you where the first to answer. You're both right in this case. It doesn't seem practical nor savvy at runtime to try and search through memory to find the
Foo
class attached to the Bar
. I'll sadly have to stick to passing in either an argument to Bar
's method or sharing ImportantInfo
with Bar via its constructor. Though I feel like shared items for instantiated elements within a class's scope should be a thing guess that's not how this works, sadly.– Robert Smith
Nov 22 at 3:13
LeY provided a bit more info about GC tracing in regards to memory but you where the first to answer. You're both right in this case. It doesn't seem practical nor savvy at runtime to try and search through memory to find the
Foo
class attached to the Bar
. I'll sadly have to stick to passing in either an argument to Bar
's method or sharing ImportantInfo
with Bar via its constructor. Though I feel like shared items for instantiated elements within a class's scope should be a thing guess that's not how this works, sadly.– Robert Smith
Nov 22 at 3:13
You also mentioned passing them by reference instead to save the memory. In this case my logic in thinking was to save memory say, if I needed to share a large buffer or something with a class. Passing by reference remedies that worry in the way I was thinking about things.
– Robert Smith
Nov 22 at 3:17
You also mentioned passing them by reference instead to save the memory. In this case my logic in thinking was to save memory say, if I needed to share a large buffer or something with a class. Passing by reference remedies that worry in the way I was thinking about things.
– Robert Smith
Nov 22 at 3:17
Right. Just make sure you understand how passing by reference works since you can pass a reference by value, or pass a reference by reference (using
ref
), and the effects can be different if you're not careful. That article I linked to explains it.– Gabriel Luci
Nov 22 at 13:39
Right. Just make sure you understand how passing by reference works since you can pass a reference by value, or pass a reference by reference (using
ref
), and the effects can be different if you're not careful. That article I linked to explains it.– Gabriel Luci
Nov 22 at 13:39
add a comment |
up vote
1
down vote
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.
Think it would ever be practical to include objects a child class like this would inherit and be able to use ? I'm speaking from MS's point of view on all that. Of course what I'm asking probably isn't the smartest way of doing such things either.
– Robert Smith
Nov 22 at 3:07
add a comment |
up vote
1
down vote
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.
Think it would ever be practical to include objects a child class like this would inherit and be able to use ? I'm speaking from MS's point of view on all that. Of course what I'm asking probably isn't the smartest way of doing such things either.
– Robert Smith
Nov 22 at 3:07
add a comment |
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Nov 22 at 0:30
LeY
332213
332213
Think it would ever be practical to include objects a child class like this would inherit and be able to use ? I'm speaking from MS's point of view on all that. Of course what I'm asking probably isn't the smartest way of doing such things either.
– Robert Smith
Nov 22 at 3:07
add a comment |
Think it would ever be practical to include objects a child class like this would inherit and be able to use ? I'm speaking from MS's point of view on all that. Of course what I'm asking probably isn't the smartest way of doing such things either.
– Robert Smith
Nov 22 at 3:07
Think it would ever be practical to include objects a child class like this would inherit and be able to use ? I'm speaking from MS's point of view on all that. Of course what I'm asking probably isn't the smartest way of doing such things either.
– Robert Smith
Nov 22 at 3:07
Think it would ever be practical to include objects a child class like this would inherit and be able to use ? I'm speaking from MS's point of view on all that. Of course what I'm asking probably isn't the smartest way of doing such things either.
– Robert Smith
Nov 22 at 3:07
add a comment |
up vote
0
down vote
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'sSomeCoolStringBufMethod()
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 Bar
s 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.
add a comment |
up vote
0
down vote
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'sSomeCoolStringBufMethod()
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 Bar
s 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.
add a comment |
up vote
0
down vote
up vote
0
down vote
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'sSomeCoolStringBufMethod()
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 Bar
s 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.
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'sSomeCoolStringBufMethod()
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 Bar
s 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.
answered Nov 22 at 4:04
Scott Hannen
12.1k1425
12.1k1425
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422035%2faccessing-a-parent-instances-properties%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Bar
contains no reference toImportantInfo
and also no reference toFoo
. Therefore, this is impossible. In order forBar
to get atImportantInfo
, you must give it something that it can trace back to it, whether theImportantInfo
itself or an instance of an object that references it.– laptou
Nov 22 at 0:08