I have a situation where a custom class is a property of another class.
What I need to be able to do, if it is possible at all, is obtain a reverse to the “parent” class (ie the the class that holds the current class as a property).
For Instance:
Public Class Class1
...
public readonly property Prop11 as Class2
public property Prop12 as String
...
End Class
Public Class Class2
...
private _par as Class1
private _var21 as string
...
Public Sub New(...)
me._par = ????
...
End Sub
public readonly property Prop21 as string
Get
return me._par.Prop12 & me._var21
End Get
End Property
...
End Class
Ultimately, I am trying to access other properties within Class1 from Class2 as they do have substance for information from within Class2. There are several other classes within Class1 that provide descriptive information to other classes contained within it as properties but the information is not extensible to all of the classes through Inheritance, as Class1 is being used as a resource bin for the property classes and the application itself.
Diagram, lazy design ;):
Application <- Class1.Prop12
Application <- Class1.Prop11.Prop21
Question:
Is it possible to get a recursion through this design setup?
3
Well, your design has problems, that’s certain, and you’ve obfuscated the problem a bit too much here.
What I can suggest, based on what you’ve given, is that, instead of this:
class1.Prop12.Prop21
do this:
class1.WrappedProp
where Class1 implements WrappedProp like this:
Public Class Class1
...
Public readonly property WrappedProp as string
Get
return me.Prop12 & myChild.Var21
End Get
End Property
...
End Class
That is to say that the “application” (or whatever object holds a reference to your class1/parent) should not access the child class (or, know about it at all for that matter). From what I can tell, what you’re really doing is providing some kind of container or wrapper with your parent class, but not completely wrapping or containing the child type.
1
I think your design is not optimal, that something is amiss. And the names you are using do not help either.
It’s kind of a forced analogy but… Does a clock need to know who owns it to do its job? Does a pen need to know who owns it to its job? It’s the same thing here. You can say that the clock does need some info about the owner to do its job, specifically the time for the alarm.
But this is not the case here. In your code, Class2 needs something from Class1 in order to even exist. One of its properties can’t leave on it owns without Class1. If it was a method, I’d understand. But a property?
Anyway, alternatives:
-
If you do need to know the owner, pass it as constructor parameter.
-
Pass what the other classes need as parameter.
-
If it is a lot of information, then your Class1 is probably a composition of smaller objects. Break it and pass the little pieces as parameters to other class.
-
Use a 3rd class as a Helper. It’ll use info from the other two classes to do what it’s needed.
PS: If you could edit and make the name of classes/properties more meaningful, we can help you better.
The easiest way to do that is have Class1.Prop21 control the lifetime of Class2, this will allow it to assign the Parent relationship.
2
Well…I would suggest you consider re-thinking your design, but sure you can have two objects that each reference each other; that is trivial.
The real question is how do you want to handle the instantiation / initialization. Does one of the objects, the “parent” as you’ve opted to think about it, contain the “child”, or does a third object get involved to coordinate the aggregation of “parent” and “child”.
However, before you rush into this, a similar concept you might want to check out is the Visitor pattern, which is used for bigger things than this but in a granular sense hinges around one object being passed to another which then passes itself back to that object.
There is also Kent Beck’s “self delegation” pattern; if instead of using properties to couple the two objects together you restructured your logic into one or more methods, you could have the “parent” pass itself into the “child”‘s method(s) as a parameter as needed, thus avoiding back-coupling from the “child” to the “parent”.
Going a little further out, depending on what this “parent” and “child” set up is meant to model, you might just be looking at a Composite implementation.
3