Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
      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


  1. Is it possible to get a recursion through this design setup?
share|improve this question
Classes that know who owns them is considered an anti-pattern due to the tight coupling introduced between the two, as well as the lifetime management issues it raises (and for a few other reasons...). – Telastyn Dec 3 '12 at 16:59
i push the designs of the framework where i can. If you dont know the limits of what your designing against, then you will never know what broke it ;) So basically i should consolidate my instantiation of the properties into the parent class so i can control the information that needs, or does not need, to be passed to the properties? – GoldBishop Dec 3 '12 at 17:55
You have to fasten screws. You have a hammer and a screwdriver. There's no need to push the design of the hammer and use it to fasten the screw. You should use the screwdriver here. The same here. There are alternatives, that it'll make it easier for you in the future. – Luiz Angelo Dec 4 '12 at 16:03
up vote 2 down vote accepted

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:


do this:


where Class1 implements WrappedProp like this:

Public Class Class1
    Public readonly property WrappedProp as string
            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.

share|improve this answer
Yeah i was trying to stay out of the technique that i have used in Collections, but seems they are the best style of technique to use when it comes to this type of design. As well, looks like ill have to some of the strategies i have picked up while designing DAL/BAL for applications. – GoldBishop Dec 4 '12 at 17:18

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.

share|improve this answer

The easiest way to do that is have Class1.Prop21 control the lifetime of Class2, this will allow it to assign the Parent relationship.

share|improve this answer
So make Prop12 readonly and instantiate the underlying object during some other process that is required? Lets say the constructor method? – GoldBishop Dec 3 '12 at 23:54
@GoldBishop: Or upon first access. It really depends on your usage. For instance I have built Tree structures before that guaranteed parent relationships by requiring that you create nodes from their parent. – Guvante Dec 4 '12 at 15:29

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.

share|improve this answer
Had thought of doing a constructor that accepted the parent type as a parameter but then realized that for what the client needed, that was WAY TOO involved for them. As they ultimately are the one supporting it, just looking at options. Thank you for the read information, ill look it up. – GoldBishop Dec 4 '12 at 17:24
The basic underlying concept here is dependency. The flavors are: Association...obj1 and obj2 exist independently of each other and the destruction of one does not cause the destruction of the other. Neither object owns the other. Aggregation: the two objects exist independently of each other, but one object "owns" the other. Destruction of one does not cause destruction of the other. Composition aka Containment: one object owns the other and (usually) created it itself, or caused it to be created internally. Destruction of the owning object destroys the other as nothing else references it. – Ed Hastings Dec 4 '12 at 17:36
good synopsis....again, i have more reading to do for future self-development in these "ownership" realms. – GoldBishop Dec 5 '12 at 16:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.