Strange class construct.

I'm reviewing some template generated code, and have come across one of the strangest class constructs I have ever seen, so I figured I'd post it on here to get peoples opinions. The construct looks like this:

vb Code:

Public Class A
 
 public bt as B
 
 Public sub New ()
  bt=Nothing
 end sub
 
'The other class is defined within A:
 Public Class B
  public ba as A
  
  public sub New(anA as A)
   ba = anA
   ba.bt = Me
  end sub
 
 end class
 
End Class

In case anyones confused by the simplicity, I reduced the whole thing to a minimal example. All the pieces are there, and the relationships between the objects are preserved, but there is plenty more to the second class (though to be fair, there isn't much more to the first class). Mostly, the second class raises lots of events.

Thus you see that B is defined within A, and A has a member of type B, while B has a member of type A. The B member of A is Nothing when A is created, but when B is created, the two objects are members of each other. Normally, I would simply say that there is no purpose for having two classes in this situation, but there are a couple of reasons for some of this code:

1) There could be numerous objects of type B in type A, though typically there is only one, so combining A and B doesn't necessarily make good sense, as there could be many B instances combined into A.

2) B is defined within A for no very good reason that I can see. The definition of many of the pieces of B are dependent on the name of A, but this is all template derived code, so generating B outside of A would really not take any more time.

So my question is largely: Has anyone ever seen anything like that before, and is there any advantage of creating something this way, with each object being a member of the other object?

Can B be added to multiple other types besides A?

Say we had a C that also held and instance of B (exactly the same as A, but... not). Given B, you could determine who the "parent" object was that was containing it; either C or A, and you wouldn't have to iterate through a bunch of collections to find it. To me, the pseudo code you posted looks more like a "bottom-up" approach instead of the more common "top-down."

That is possible.

There is a type C that holds these lines:

public at as A
public WithEvents A.bt as B (or something like that, I may have the syntax off).

So basically, type C is holding an instance of A, and an instance of the B that is a member of A, even though A is a member of B and B is a member of A. Of course, A doesn't raise any events, so having the instance of B there means that type C can consume events published by B, so I understand that. The whole purpose behind A is becoming less and less clear, though, since it has only a New and Close method, and the close method doesn't do much of anything. Object A simply exists to hold three variables that are used by any instance of type B that is created.

One thing I have determined since then is that A will usually have a definition for B, but it might also have a definition for D, E, F, etc. Each of these classes will be almost identical (template generated code), and each will need access to the members in A.

It seems to me that a singleton A makes far more sense, since the whole purpose of A is to provide access to the three variables that will be common to each of B, D, E, F, etc.

An alternative would be inheritance, but there is little advantage to this.

One fun little piece of code I have found was that type C (which holds an instance of both A and B), calls a method that takes both A and B as arguments. Since they are mutually referential, there is NO reason to take both.

The thing that I am most stuck on is whether or not this is bad, or just confusing as hell. Is there a more efficient way to do this? I suspect that, while it appears bizarre, there is little or no runtime impact.

An example would be the ListViewItem class and the ListViewItem.ListViewSubItem class. The subitem class is declared inside the item class because a subitem is meaningless without an item. The item has a member referring to a collection of subitems, while each subitem has a field referring to its parent item. Makes perfect sense.

Ok, I haven't seen that case, perhaps it is the same. The thing that puzzles me is that the holder class really doesn't DO anything. It has only a constructor and a destructor (which is written based on a misconception, but that's a different issue). The constructor doesn't create any of the contained classes, which would be consistent with the ListViewItem class, because there COULD be a subitem, but there certainly doesn't HAVE to be one. There are no other methods, though, so the class is really just a container for three variables that are shared between all sub classes. There sure seem to be other ways to do that, and I can't decide if there are any advantages to this technique.

It does sound a bit convoluted, but we'd have to know more about the classes to know whether it was the most appropriate way to implement it or not. Without knowing their purpose and the context in which they would be used it's hard to say.