Composition vs association best practices...

[Alain]

Hi all,

I'm wondering if there is some sort of way, or 'best practice' to differenciate composition references from relational/association references. The need behind it is to find a way to tell a recursive sub or function that would browse an object tree structure when to stop digging.

Would having a generic 'Children' collection in each class and adding any reference that I consider to be a composition in it be acceptable, or is there a trap I didn't see coming to that strategy?

Thanks for you ongoing support!

Cheers,

[jmcilhinney]

It's hard to say without knowing the specifics of the situation. Every class having a Children collection doesn't sound like a good idea but that sort of thing is a good idea in specific situations, e.g. the Control.Controls property. The most immediately obvious examples for me are all UI related but the same cam apply to more abstract types too. In short, it depends.

[Alain]

Thanks for answering JM.

I understand the 'vagueness' of my question, and that some specifics would help. So let's imagine a Clone() function I'd like to implement (I know, I can implement the one from the .NET Framwork, but just for the sake of argument...), so let's say I want to do a clone function. Idealy (in my opinion, but that's debatable), the best would be to define a clone function in some top level class, and thus be available to all other sub-classes that would inherit the top one. It would be coded so that when called on any given object, it would subsequently be called on all 'children' objects, and so on until the object structure is fully cloned all the way down the tree structure. But for that, there must be a way to differenciate amongst all relations/references an object may have, which ones are 'children', or which ones are 'part' of the object (i.e.: which ones are compisition links) in comparison to relations that are associations only, and for which the clone function would stop digging. I don't know of a way to 'flag' a pointer/reference as 'composition' and was wondering if there was some way I wasn't aware of to do so.

That said, I'm assuming the proper way to handle such a case (the clone example) in a OOP state of mind would be to define a clone function for each sub-class, which would overload the top-class one, and into which you can specify which links to process as composition, and which to ignore.

I guess that's more a generic OOP question than an actual .NET question. Switching from VB6 to .NET, I'm now truly confronted for the first time to OOP, and it raises questions, naturally.

[jmcilhinney]

There is no easy way to generalise what you're talking about there, which is why it's not already done. Cloning an object does a shallow copy and any sort of deep copy has to be implemented on an as needed basis. You could only generalise for a small set of well-known types whose relationships were consistent. When one type doesn't know at what level in a tree it will be used and what types might be used in the levels above or below, how can it know exactly what needs to be copied and what doesn't?

[Alain]

When one type doesn't know at what level in a tree it will be used and what types might be used in the levels above or below, how can it know exactly what needs to be copied and what doesn't?

Well unless relations were 'typed', as I suggested. And it's not so much 'what needs to be copied and what doesn't' (in the Clone example), so much as 'where do I stop going deeper'.

Let's imagine this:

Public Class Car
Private Child Engine as Motor 'Or something like that

Then one could call:

If p Is Child then' where p is a Motor (or some other top class object Motor inherited from)
'do whatever needs to be done
end if

In UML, composition links are clearly differenciated from other relations. So to me differenciating them in the code that implements a data model designed in UML would make sense.

But again, I'm not criticizing or even arguing. I'm just trying to grasp the way it is usually handled in OOP in general.

And I thank you for taking the time to enlight me on this!

[Grimfort]

Have you seen Attributes? You can mark a field with an attribute which can then be used/checked by your code. For example, you could mark the fields that are just association with an attribute, and then decide to follow or not depending on its value.
Serialization uses them to decide what to and not to serialize as it happens.

[Alain]

Thanks Grimfort!

I think you're on to something. I have some reading to do as there seem to be quite a lot written about attributes, but I'll sure take a serious look at it.

Thanks again!