7

I know There are different way of reprentation for Conversion of Association,Aggregation and composition in java. But when we convert them into code(java classes) they are all represented in same manner. Like Student taught by teacher which is association will be represented with Student class having instance variable of Class Teacher.

Department has professors which is aggregation will be also be represented with Department class having instance variable (array )of Class Professors.

University has departments which is composition will be also be represented with University class having instance variable (array )of Class department.

So all are reprented in same manner in terms of code. So what benefits terms Association,Aggregation and composition provide to developer?

M Sach
  • 33,416
  • 76
  • 221
  • 314

1 Answers1

5

You're missing part of the story with Composition. It mandates a couple of extra properties:

  • immutability of the parent (i.e. child can't switch parents)
  • lifecycle responsibility for the children lies with the parent. i.e. the parent is responsible for creating and deleting child instances. Child can't live after parent dies.

You're right that the association will manifest as a reference / collection of references in child & parent respectively. But the code must also enforce the rules above if it's to ensure Composition semantics are enforced.

As for Aggregation: I don't use it. The semantics are too loose and it offers no advantages over straight associations.

hth.

sfinnie
  • 9,854
  • 1
  • 38
  • 44
  • Sorry sfinnie i missed both the points. Point1:- If we consider the composition example in original post, are you saying that University class should have instance variable (array )of Class department as final.If not how we will represent it in code. Point2:- yes i agree with your point but does not make difference when we convert uml diagram in to coding because it will still be a simple instance variable. – M Sach Aug 26 '11 at 14:59
  • point 1: yes. Point 2: It's not just about the reference. The UML composite semantics require "If a composite is deleted, all of its parts are normally deleted with it" (UML superstructure 2.3, page 40). In non-GC languages like C++, this means the destructor code must ensure all children are deleted before the parent is deleted. For GC environments this is less obvious. However, there are idioms - such as the "Aggregate Root" approach popularised by Domain Driven Design - in which the only way to create (or remove) a child is via methods on the parent itself...(ctd). – sfinnie Aug 26 '11 at 21:08
  • ...so in the prototypical Order / OrderLine scenario, the only way to add an OrderLine from an Order is to call Order.AddOrderLine() (similarly for removal). So to summarise: there is no direct, declarative analog in code that denotes a Composite. Instead you have to build the behaviour procedurally. Identifying composites in code therefore requires an amount of 'pattern recognition'. If the reference is final, and the only way to create/delete a child is through the parent's interface, then the relationship is likely Composite. hth. – sfinnie Aug 26 '11 at 21:14
  • Thanks sfinnie for such a wonderful explanation.Wanted to add one more point. As you said Child can't live after parent dies and explained it GC terms. Great point. But can we also say in composition that if we want to delete the university from database first we have delete the departments from database. In a way it helps the developer in understanding the behaviour among different entities. – M Sach Aug 28 '11 at 08:03
  • @Mohit: essentially, yes. Relational DBs do have a declarative idiom for this: in the DDL, you add an "ON CASCADE DELETE" constraint. It says that if the parent is deleted, children must also be deleted. If you don't have direct control over the DDL however then you're correct that the code must ensure all children are deleted when the parent is deleted. hth - and thanks for the kind comment. – sfinnie Aug 28 '11 at 13:53