-
Aug 21st, 2014, 06:05 PM
#1
Thread Starter
Fanatic Member
Composition vs association best practices...
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,
Don't ask why, just reboot!
-
Aug 21st, 2014, 10:32 PM
#2
Re: Composition vs association best practices...
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.
-
Aug 22nd, 2014, 08:49 AM
#3
Thread Starter
Fanatic Member
Re: Composition vs association best practices...
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.
Don't ask why, just reboot!
-
Aug 22nd, 2014, 08:56 AM
#4
Re: Composition vs association best practices...
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?
-
Aug 22nd, 2014, 09:24 AM
#5
Thread Starter
Fanatic Member
Re: Composition vs association best practices...
Originally Posted by jmcilhinney
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:
vb.net Code:
Public Class Car
Private Child Engine as Motor 'Or something like that
Then one could call:
vb.net Code:
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!
Don't ask why, just reboot!
-
Aug 22nd, 2014, 02:50 PM
#6
Re: Composition vs association best practices...
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.
-
Aug 22nd, 2014, 03:54 PM
#7
Thread Starter
Fanatic Member
Re: Composition vs association best practices...
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!
Don't ask why, just reboot!
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|