Question

I’m fairly new to the OO design process, so please bear with me….

I have two entities that I need to model as classes, call them Parent and Child (it’s close enough to the actual problem domain). One Parent will have one or more Children — I have not interest, in this application, in childless Parents.

Where my brain is going out to lunch is on the fact that I need to be able to find either from the other. In my database I can implement this with a normal foreign key relationship, and the set-based nature of SQL makes it easy to find all Children for a given Parent, or the Parent for a given Child. But as objects…?

I think that the Parent should carry a collection (list, whatever) of Children. I also think that each Child should carry a reference to its Parent. The circular nature of the references, however, is making my head hurt.

Am I:

• On the right track?
• Completely off base? If so, what should I do differently?

This will almost certainly be implemented in VB.NET, but I’m a ways from cutting code yet.

Edit after 8 answers:

Thanks all. It was hard to pick just one answer to accept.

To clarify a couple of things that were questioned in the answers:

• Parent and Child are very different
  entities–there’s not inheritance
  relationship at all. I chose the
  names that I did because they’re
  really very close to the real-world
  problem domain, and now see that it’s
  a source of confusion from an OO
  perspective.
• The hierarchy is only one level deep–Children will never have Children
  within the application.

Thanks again.

Answer 1

The circular references are fine and absolutely standard when creating a tree structure. HTML’s Document Object Model (DOM), for example, has the parent and child properties on every node in a DOM tree:

interface Node {
    // ...
    readonly attribute Node     parentNode;
    readonly attribute NodeList childNodes;
    // ...
}