I hereby banish the words ‘aggregation’ and ‘composition’ from all of software.
Am I allowed to do that?
Think about it. The last time you drew a UML diagram, did you use hollow diamonds or filled-in diamonds? If you used both, did anybody know what you meant? I’ll bet the answer is no. And if you used those words in conversation, there was probably a 10-minute discussion about what their meaning. This discussion happens EVERY time.
There’s a good reason for this – the distinction of aggregation vs. composition simply is not useful enough to stick in people’s brains. Some feel the need to use it because it’s part of the modeling tool they spent so much money on. Others like it because it makes them look smart. But it’s not worth it. (nor is the modeling tool, IMHO)
So join the movement! Run sed -e ’s/(aggregation|composition)/association/g’ over all your documentation and emails! Get rid of those stupid diamonds and use arrows instead! Spend your time thinking about the problem you’re trying to solve instead of explaining useless concepts.
2 responses so far ↓
leblanc meneses // June 13, 2008 at 5:04 am |
i disagree in removing them from vocabulary. It like arguing why memorize the names of the common design patterns.
Terms help explain a problem in one word or a short phrase.
Have I memorized how to actually model with filled or open diamond … no i still refer to the documentation. However, i do use the terms during speech.
Now that i’ve spent the time to understand the terms i expect my coworkers to also. It actually helps during discussion.
When i hear aggregation I think:
1) polymorphism – loosely coupled
2) the client is given the object which only knows of an interface
When i hear composition I think:
1) tightly coupled
2) the client can’t be created without creating its internal parts.
now things i don’t expect my all my coworkers know is:
composition can become loosely coupled if you apply factory design pattern or dependency injection.
mullr // June 13, 2008 at 10:24 pm |
You make a good point that I overlooked: that it can be worth deliberately building a team vocabulary. Also, your definition of the terms is succinct and good. I concede the point.