This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Soft Skills and have John Sonmez on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Class relationships Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Class relationships" Watch "Class relationships" New topic
Author

Class relationships

Donald R. Cossitt
buckaroo
Ranch Hand

Joined: Jan 31, 2003
Posts: 401
As an example:
In a CustomerOrder schema with the following core components:
Account
Item
Order
RushOrder

It is obvious that
RushOrder "Is-a" Order (Inheritance)
Order "Has-a" Item (Aggregation)

However, it is not obvious whether
Order "Uses-a" Account (Dependence)
Account "Has-a" Order (Aggregation)
Account "Uses-a" Order (Dependence)

Inheritance and Aggregation are somewhat straightforward. But Dependence is a bit vague; and what of Association?


doco
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
"uses-a" is a nice description. This kind of thing is discussed heavily down in the OO and OO & UML forum. Drop in and READ a bunch of posts on relationships, then see if you have more to ask about.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20723
    ∞

Is the ocean blue? Or is it green?
How you choose to build your application is up to you. You're struggling with the answers to these questions thinking "Am I dumb to not see what appears obvious to everybody else?" The answer is that everybody else struggles too. Because you are able to ask the question so consisely, you are closer to the solution than many people that call themselves software architects.
A modern approach, which is an excellent approach for beginners, is an agile approach. XP or something like it. You sit down and look at the program you are about to write. You know that you will have something sort of functioning in, say, three hours. What sort of stuff will that thing do? Focus only on the next few hours. Don't worry about six months from now at this moment. Get something going. Once you have something going, it will be clearer whether a "has a" relationship is better than a "uses a" relationship. Changes are easy to make.
Some people think the answers to these questions are obvious. Probably because they struggled with them in the past and came up with answers that satisfied them. Be careful with these people! Often times, they found that a hammer solved a problem in the past, so they try to use a hammer for everything! And sometimes what they insist is a "hammer" is actually a rock (and they call it "The Model/View/Controller Pattern").
Your questions are healthy. Keep asking them.


permaculture Wood Burning Stoves 2.0 - 4-DVD set
Surasak Leenapongpanit
Ranch Hand

Joined: May 10, 2002
Posts: 341
Usually association relation is the first choice, after that refine them.
Jacquie Barker
author
Ranch Hand

Joined: Dec 20, 2000
Posts: 201
When it comes to translating the various relationships into code, aggregation and association relationships are implemented in exactly the same fashion; in fact, one could argue that aggregation could be left out of the UML without any significant loss, since an association could certainly be labeled "has a".


Author of Beginning Java Objects, Beginning C# Objects, and Taming the Technology Tidal Wave
Donald R. Cossitt
buckaroo
Ranch Hand

Joined: Jan 31, 2003
Posts: 401
Excellent! Thanks all and especially Paul - your comments take the edge off of the process.
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
When it comes to translating the various relationships into code, aggregation and association relationships are implemented in exactly the same fashion; in fact, one could argue that aggregation could be left out of the UML without any significant loss, since an association could certainly be labeled "has a".
I do think that distinguishing between aggregation and assiciation is useful in a few situations, including when trying to understand a developing solution design and discovering what design patters might fit well.
Sometimes it's just useful to know whether something uses another thing or whether it actually is composed of it. For instance, a car and a road both interact with car tires. At times, it's useful to distinguish that the car is partly composed of the tires and the road just interacts with them. I don't think I'd like to say the road "has a" car tire in this relationship.
The lil' thing that just kinda bugs me about UML is the distinction between aggregation and composition. At the moment I don't recall what the big deal is all about that these need to be distinguished.
But we can spend days stumbling over semantics and such over in the OO, Patterns and UML forum...
[ October 16, 2003: Message edited by: Dirk Schreckmann ]

[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Class relationships