Aggregation & Interfaces
Premise:
Primary actor is the StoreUser. Every StoreUser will be associated with Messages,Reports, Status.
Now my problem lies in trying to figure out which one of the two options is a better one:
a) Messages,Reports, Status AGGREGATED in a StoreUser with StoreUser exposing behaviour
publicclass StoreUser{
Messages messages;
Reports reports;
Status status;
public addMessage(){
messages.addMessage();
}
public addReport(){
reports.addReport();
}
public updateStatus(){
status.updateStatus();
}
}
b) StoreUser implementing interfaces to provide behaviour
publicinterface MessageIntf{
addMessage();
}
publicinterface ReportsIntf{
addReport();
}
publicinterface StatusIntf{
updateStatus();
}
public StoreUserimplements MessageIntf,ReportsIntf,StatusIntf{
Messages messages;
Reports reports;
Status status;
// Implement the methods in the Interfaces
}
[1936 byte] By [
katriyaa] at [2007-10-2 6:05:22]
I'm sorry, but the answer is "it depends".
I'd say the interface design might be a good one if you had other model objects that also had message, report, and status aggregation. They could all share a common interface and, better yet, a common abstract class that would guarantee that they'd all a common default behavior.
But if StoreUser was the only class in your design that aggregated these classes, I'd just make them class members, give whatever access was appropriate, and call it a day.
I'd also agree with the interface design if there was some behavior associated with manipulating these classes. But the way you've presented them makes me think they're little more than glorified getters/setters. You spell out the need for aggregation by having the interface, but little more.
I like the impulse to incorporate interfaces into your design. That's a good instinct.
%
> I'd say the interface design might be a good one if
> you had other model objects that also had message,
> report, and status aggregation. They could all share
> a common interface and, better yet, a common abstract
> class that would guarantee that they'd all a common
> default behavior.
>
> But if StoreUser was the only class in your design
> that aggregated these classes, I'd just make them
> class members, give whatever access was appropriate,
> and call it a day.
Indeed, StoreUser is the only class that will have messages,reports etc associated
> I'd also agree with the interface design if there was
> some behavior associated with manipulating these
> classes. But the way you've presented them makes me
> think they're little more than glorified
> getters/setters. You spell out the need for
> aggregation by having the interface, but little
> more.
Actually, a lot of processing does happen in the Messages, Reports and Status classes by themselves, other than just getting/setting.
Especially, the Messages class is the one in which Messages are added,removed, etc.
When i thot about it, in pure OO direction.. I went ahead with..
Every StoreUser HAS Messages,Reports, Status and there by ended up with Aggregation.
I'm hoping I have hit the right nail.
Messages is a loaded term for me. It makes me think of JMS and asynchronous processes. Is that how you mean it?
I'd have to know more about your Message, Status, and Report classes, but I'm not so sure I'd do things this way. Generating a report sounds more like a service that aggregates StoreUsers in some way rather than an object that they'd "have". I can see a Service class of some kind where I'd ask for an aggregation of StoreUsers that met some criteria ("tell me all the StoreUsers who have open premium credit accounts with an average balance of $500 or more so I can target this special sale for them"). That has more of a data warehousing/data mining sense to it than an object-oriented feel.
How do you mean it?
%
> Every StoreUser HAS Messages,Reports, Status> and there by ended up with Aggregation.> yet, what you are doing is not aggregation, but composition.
> > Every StoreUser HAS Messages,Reports,
> Status
> > and there by ended up with Aggregation.
> >
> yet, what you are doing is not aggregation, but
> composition.
Well they can possibly have different life spans so what makes you say that?
> > > Every StoreUser HAS Messages,Reports,
> > Status
> > > and there by ended up with Aggregation.
> > >
> > yet, what you are doing is not aggregation, but
> > composition.
>
>
> Well they can possibly have different life spans so
> what makes you say that?
aggregation is a weaker form of ownership, composition is the strong form of ownership, meaning you will have to take care of its creation, desctruction and everything in between. so obviously, life spans should not be used as an execuse of lacking of knowledge:))
> > > > Every StoreUser HAS Messages,Reports,
> > > Status
> > > > and there by ended up with Aggregation.
> > > >
> > > yet, what you are doing is not aggregation, but
> > > composition.
> >
> >
> > Well they can possibly have different life spans
> so
> > what makes you say that?
>
> aggregation is a weaker form of ownership,
> composition is the strong form of ownership, meaning
> you will have to take care of its creation,
> desctruction and everything in between. so obviously,
> life spans should not be used as an execuse of
> lacking of knowledge:))
> aggregation is a weaker form of ownership,
> composition is the strong form of ownership, meaning
> you will have to take care of its creation,
> desctruction and everything in between. so obviously,
> life spans should not be used as an execuse of
> lacking of knowledge:))
Considering the reputation you have earned on these forums I would not waste my time and effort on explaining to you the subtle difference between the two and what it has got to do with life spans.
>
> Considering the reputation you have earned on these
> forums I would not waste my time and effort on
> explaining to you the subtle difference between the
> two and what it has got to do with life spans.
Ah....don't be like that....give it go....I am sure he will get it after the 200th post by you (or so.)
After all he has to learn something sometime.
Right?
RIGHT?
(Time to start drinking I suppose)
Well, I didn't know what the difference was between aggregation and composition, so I asked Google for "aggregation versus composition". And it gave me back this article entitled "Aggregation vs. Composition": http://www.artima.com/legacy/design/compoinh/messages/24.html
I like the ref. Good one.
> I like the ref. Good one.indeed.i was reading uml specs quite a while ago, it seems they are dumping aggregation, there will be only composition left, and i think it makes sense...
Martin Fowler's "UML Distilled" says aggregation is a "part-of" relationship. The distinction into two camps has to do with the life cycle of the underlying objects.
I think aggregation is an association where the child objects have a life independent of their parent. Composition is more restrictive - when the parent is removed from memory, so are its children in that case.
A School can be considered to have associations with Students and Classrooms. If I bulldoze the School, the Classrooms go with it (composition), but I don't shoot all the Students, too (aggregation).
%
> A School can be considered to have associations with
> Students and Classrooms. If I bulldoze the School,
> the Classrooms go with it (composition), but I don't
> shoot all the Students, too (aggregation).
>
> %
you can design these students as aggregation too, passing thenm in, and i think you can do composition too, instantiating them within your class, and they 'die' when class is over: susan is a housewife, she's also a student while attending school; when school/class is over, she is no longer a student, once again just a housewife.
> you can design these students as aggregation too,
> passing thenm in, and i think you can do composition
> too, instantiating them within your class, and they
> 'die' when class is over: susan is a housewife, she's
> also a student while attending school; when
> school/class is over, she is no longer a student,
> once again just a housewife.
Not really.
I won't be sending my kids to your school, daFei. If you have any, I hope they're at the head of the class.
%
> I won't be sending my kids to your school, daFei. If
> you have any, I hope they're at the head of the
> class.
>
> %
oh, big daddy worries too much. when your kids graduate from school, they would still be alive, just that they would be students no more, they must be writing good interfaces:)
at 2007-7-20 18:47:51 >
> > I won't be sending my kids to your school, daFei.
> If
> > you have any, I hope they're at the head of the
> > class.
> >
> > %
>
> oh, big daddy worries too much. when your kids
> graduate from school, they would still be alive, just
> that they would be students no more, they must be
> writing good interfaces:)
thats the whole thing, graduates that cease to be students are too hard to deal with.
Start with a, add b as required.
Hi I think you have confusion to our problem only the way of better interfaces.Now you will use seperate.Edited by SASIK
