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.
Hi there, My dad used to run a one-stop print shop. You could come in with an idea for a flyer, and he'd do the graphic arts, print up 10,000 of them, and bulk mail them out to a mailing list you provided. Of course, he didn't do all this himself--he didn't have the capabilities to print 10,000 of anything. Instead, he'd farm out, or delegate, the task to a local printer he knew. That's what delegation is--you have object A that advertises it can foo(), but when you call a.foo(), all a does is forward the call to some other object and return the result of that forwarded call. It is important to understand, though, that the two objects retain their individual identity in the greater scheme of things. In other words, if you just needed some graphic arts done, you'd go to my dad's business, if you needed printing done, you could go to either the local printer or my dad's business...but you'd pay a little more at my dad's because he'd have to make a little in the process, too. Composition is a slightly different thing. Composition is used to describe the relationship between two objects when one is "composed of" the other. To remember what the term "composition" describes, think about what "decomposition" means--rotting, something falling apart into smaller pieces. For example, a building contains rooms. If you knock down that building, the rooms cease to exist. A building is "composed of" rooms. A marriage is "composed of" its partners. If one of the partners leaves the marriage, the marriage ceases to exist. If either my dad or the local printer went out of business, the other would continue to exist, so this is not a composition relationship. You might say, well, if the printer goes out of business, then my dad very well might because he'd have nowhere to send his printing. Good try...but no, my dad could find another printer. My dad's relationship to the local printer was not really an association with that particular instance...he'd be just as happy using any object that had the print() method. A composition, on the other hand, can only live as long as the specific parts, i.e., instances, that make it up. It's important to recognize that this distinction is often impossible to make in a vaccuum--it is very likely that you would need to know the problem domain in order to accurately express the correct relationship between two things. Example: am I composed of my body organs? If you're writing an application that tracks the effects of smoking on people's organs, you'll likely have a Person class and a bunch of BodyOrgan subclasses (Heart, Lung, etc). When you instantiate a Person p, it would be composed of specific instances of these organs. If a Person dies, all the organs die. If you're writing an application that tracks organ donors, however, you'll also likely have a Person class and a bunch of BodyOrgan subclasses. However, in this application, a Person is only associated with their organs. When a person dies and your system mirrors that by having a particular Person instance die, the Heart object might form a new association with a different Person instance to reflect a transplant. (Delegation, by the way, is one type of association--I've heard of OO gurus like Martin Fowler talk about as many as 6 different kinds of association, of which delegation and aggregation are two...and composition is one kind of aggregation. Does your head hurt yet? ) Now in the first application I mentioned, you might say, hey, wait a minute...what if someone dies and their heart happens to get transplanted into someone else? Wouldn't I also want to reflect that in my application? Well, no. Your application doesn't care about transplants--it's interested in tracking the effects of smoking. So, to mirror a person in your system who, in real life died and gave a heart to someone else, you'd simply destroy that Person instance and twiddle with the health of the organ recipient. The idea is, in this problem domain, you're not interested in tracking individual organs, which means you can set up a composition relationship between people and their organs because even if they swap them around, it's irrelevant. The organ donor app, though, considers swapping organs around of great relevance, as it's supposed to be tracking those BodyOrgan instances floating around. The reason I give this example of two applications is: you can get very confused if you sit around trying to figure out the relationship between objects without considering the context of the problem. Is a car composed of various parts (engine, transmission, etc). I could make arguments either way if we don't fix the problem domain. If you're writing an app that manages a junkyard, no. If you're writing an app that simulates road traffic, then yes. In one, you have to track parts as they move around independent of any specific car. In the other, you might need to simulate speeding Yugos versus speeding Corvettes. You might decide that the speed of a car is determined by the type of engine in the car, so you might need an Engine class, but you'd be ok in this case considering a car instance as "composed of" its various car parts. sev
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: meaning of composition and delegation ???