Class A to Class B -> UML class relationship

[kri shan]

Class A{

Class B = new Class B();

}



Class B {

}

What is the relationship between Class A and Class B ? (Agreegation / Composite Agreegation) ?

[Ilja Preuss]

Impossible to tell. Assuming that the code would even compile, the different relationships are about the code's semantics, which we can't infer from your snippet.

[Hong Anderson]

Can you give a compilable code?

[yooon chin]

Composite Agreegation.

[Hong Anderson]

yooon chin wrote:Composite Agreegation.

Why do you think that?

[Jussi Taimiaho]

The example is a bit vague, but I think Chin is correct. Most likely class A contains one implementation of class B.

[Ilja Preuss]

Jussi Taimiaho wrote:The example is a bit vague, but I think Chin is correct. Most likely class A contains one implementation of class B.

And that means it's composition? I don't see it...

[Lucas Smith]

Composite Agregation when B can not exist without A (can not exist not within A) - in logical sense.

For example:

 
class Human{ HumanEye eye;}  

[Hong Anderson]

Lucas Smith wrote:Composite Agregation when B can not exist without A (can not exist not within A) - in logical sense

From the code Class B is defined outside class A. The OP might want to mean B b = new B();

[Lucas Smith]

OK, but am I right?

[Hong Anderson]

Lucas Smith wrote:OK, but am I right?

From your example, I cannot say it's right or wrong. It seems that you just declare an variable.

[Lucas Smith]

But there is no logical (and biological) sense in "living" HumanEye without Human. Is that not correct? So composition will be good.

[Hong Anderson]

Lucas Smith wrote:But there is no logical (and biological) sense in "living" HumanEye without Human. Is that not correct? So composition will be good.

In that case, yes. It depends on the semantic. If a human dies the eyes die as well.

[Ilja Preuss]

Composition is a software design concept - explaining it with "real life" examples is a slippery slope, and doesn't really explain much when to use it in code.

In a garbage collected language, the Composition concept isn't a very import one, anyway, because you typically don't need to explicitely take care of destroying an object. See http://faq.javaranch.com/java/AssociationVsAggregationVsComposition

[Hong Anderson]

Ilja Preuss wrote:
In a garbage collected language, the Composition concept isn't a very import one, anyway, because you typically don't need to explicitely take care of destroying an object. See http://faq.javaranch.com/java/AssociationVsAggregationVsComposition

Many people misunderstand Composition, the Composition concept is very important and it has nothing to do directly with memory management. Software is a model of real-world object, composition is the concept of real world that we're modeling.

Composition means it cannot be shared, and when the composite is deleted the parts will be also deleted.
From the human and eyes example, an eye cannot be shared by more than one human. To be more specific the eye can be moved to other human (if the science can do), but it's no way for the eye belongs to more than one human at a time.
And if one human dies the eye also dies. This is the very meaning of composition.

On the contrary, Association (AggregationKind is none) doesn't have these constraints.
For instance, if there are two countries named North A and South A, and there are people in these countries after that the countries are merged into one country named A, the people in North A and South A are not removed from the existence but they just change their country name to A.

[Ilja Preuss]

Kengkaj Sathianpantarit wrote:
Many people misunderstand Composition, the Composition concept is very important and it has nothing to do directly with memory management. Software is a model of real-world object, composition is the concept of real world that we're modeling.

Oh, I think we are in violent disagreement here!

Software is not a model of real world objects. Software is a model of the *solution* to a problem. And it needs to be a model that takes into account the forces of being implemented in a computer. As one consequence, this model will look significantly different based on, for example, the language used to describe the implementation.

[Hong Anderson]

Ilja Preuss wrote:

Kengkaj Sathianpantarit wrote:
Many people misunderstand Composition, the Composition concept is very important and it has nothing to do directly with memory management. Software is a model of real-world object, composition is the concept of real world that we're modeling.

Oh, I think we are in violent disagreement here!

Software is not a model of real world objects. Software is a model of the *solution* to a problem. And it needs to be a model that takes into account the forces of being implemented in a computer. As one consequence, this model will look significantly different based on, for example, the language used to describe the implementation.

You're right. My statement was misleading. Actually I didn't want to mean that software is a model of real world objects as they are. Because the problem is what is the true definition of real world objects? Different people will see the same thing differently. Modeling a real world object as it is (from the eyes of the modeler) in software or in any forms is narrow and limited.

It was misleading nevertheless. I should improve my communication skills . Thanks for pointing out.

Anyway, model of the solution is only a description from a single viewpoint. To me, as a DDD guy, software is also a model of "domain concepts" of the system.

[P Das]

Can I add my twopence? I feel that if we take the argument by a GoF member that aggregation is a design placebo, with the options being limited to either aggregation or composition, the later prevails.

Otherwise, we have a third alternative, association. Hence matter complicates without any cue to the solution.

Is this a question or a test?