CODEWITHSUNDEEP
c#classcollections
Trevor Elliott
Trevor Elliott

Reputation: 11252

Design practice for container class with multiple collections which reference each other

I'm trying to design a class structure with the following:

Relationships can be "Attaches To" where a style has a list of other styles it can attach to, and "Attachments" which is the inverse of that. If a style can "Attach To" another style, then the other style should be able to produce the first style as one of its "Attachments".

The container manages the Items and the ItemStyles. I use unique IDs for everything because I want to be able to serialize to and from XML.

However I keep running into logical problems such as I am trying to deserialize an ItemStyle from XML, but of course it can't generate references to the item IDs that it reads since only the Container itself has access to the other items.

Another issue is I want these classes to be independent to the point where if I have a reference to an Item, I can invoke a list of compatible items such as calling "Item.Attachments" or "Item.AttachesTo". This of course all needs to be calculated by the Container since it is the only class to be able to access both the ItemStyles and the Item collections.

So I'm running into a solution where I am going to have to give each Item and ItemStyle a reference to the Container so they can perform their own lookups and determine their relationship with other items. This seems like bad encapsulation and bad OOP practice, but I can't think of any other way.

I'm trying to compare my code to how a ListView works as an example. A ListView has a ListViewItemCollection and ListViewItems. In user code when you can create a new ListViewItem and when you add it to a ListViewItemCollection, it automatically now has a reference to its parent ListView. When looking at the metadata it shows the ListView reference as only having a getter. Can I assume that it uses an internal set?

Should following the ListView model of owner/item relationship work with my classes?

Upvotes: 2

Views: 217

Answers (1)

VinayC
VinayC

Reputation: 49195

Looking at a tight coupling between all classes involved, I don't think that having a reference to the parent (Container) would be a bad idea. There are many models that rely on having parent reference (typical reason could be to ensure a single parent but other reasons such as validations etc can be a cause) - one of the way to model is to have non-public constructor and construct objects via factory methods. Another way of modelling is to have public constructor but have internal setter to set the parent reference. Whenever child is added to the parent's collection object, the reference is set.

I would prefer the later approach. However, one of the thing that I would do is to avoid direct coupling with Container. Rather, I will introduce IContainer interface that will abstract look-ups needed in children and children (Item/ItemStyle) will know only about IContainer interface.

Yet another reasonable design would be to raise events from children when they want to do look-ups. These will be internal events that will be handled by container when the children are added to it.

Yet another approach would be to have a loose model. Essentially, Item can maintain its own ItemStyle references. Whenever needed, Container can build ItemStyle collection by implementing visitor pattern.

Upvotes: 2

Related Questions