aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Class A to Class B -> UML class relationship Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Class A to Class B -> UML class relationship" Watch "Class A to Class B -> UML class relationship" New topic
Author

Class A to Class B -> UML class relationship

kri shan
Ranch Hand

Joined: Apr 08, 2004
Posts: 1378
Class A{

Class B = new Class B();

}



Class B {

}

What is the relationship between Class A and Class B ? (Agreegation / Composite Agreegation) ?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Can you give a compilable code?


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
yooon chin
Greenhorn

Joined: Oct 08, 2009
Posts: 7
Composite Agreegation.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
yooon chin wrote:Composite Agreegation.

Why do you think that?
Jussi Taimiaho
Ranch Hand

Joined: Mar 01, 2004
Posts: 40
The example is a bit vague, but I think Chin is correct. Most likely class A contains one implementation of class B.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

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

For example:


SCJP6, SCWCD5, OCE:EJBD6.
BLOG: http://leakfromjavaheap.blogspot.com
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

OK, but am I right?
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

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

Joined: Jul 05, 2005
Posts: 1936
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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
Ranch Hand

Joined: Jun 30, 2008
Posts: 123
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?


Pranab Das, PMP, SCEA
 
Don't get me started about those stupid light bulbs.
 
subject: Class A to Class B -> UML class relationship