This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
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".
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 ]