association, aggregation and composition in oops with real world examples

Association:
This is relation where each object has it own life cycle , independent and no owner.
Ex:-
1) Will take a common example of project and developer. A project will be having multiple developers and developer can work for different projects. There is a relationship but both are independent. Both can create and delete independently.

2) Let’s take an another example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers but there is no ownership between the objects and both have their own lifecycle. Both can create and delete independently.


Aggregation:
This is a specialize form of Association where all object have their own lifecycle has ownership on child object and the child object cannot belongs be related to another parent object.

Ex:-
1) Will take an example of Departments and developers. A developer can be only in one department like dotnet, java etc., but if we delete the Department object still the Developer object exists. This is a “Has- a” relation.
2) Let’s take an example of Department and teacher. A single teacher can not belongs to multiple departments, but if we delete the department teacher object will not destroy. We can think about “has-a” relationship.

Composition:
This is specialize form of Aggregation and can be called as strong Aggregations
Where the child object has no life if the parent object is deleted, because of this we call this as “death” relationship.

Ex:-
Best example is House and room. A house can have multiple rooms but if we delete the house the child i.e. rooms will also be deleted and has no life.

Java Coupling and cohesion Differences with Example

"Object-oriented programming has two main objectives: to build highly cohesive classes and to maintain loose coupling between those classes. High-cohesion means well-structured classes and loose coupling means more flexible, extensible software."

"Cohesive means that a certain class performs a set of closely related actions. A lack of cohesion, on the other hand, means that a class is performing several unrelated tasks. Though lack of cohesion may never have an impact on the overall functionality of a particular class or of the application itself the application software will eventually become unmanageable as more and more behaviours become scattered and end up in wrong places."

"Whenever one object interacts with another object, that is a coupling. In reality, what you need to try to minimise is coupling factors. Strong coupling means that one object is strongly coupled with the implementation details of another object. Strong coupling is discouraged because it results in less flexible, less scalable application software. However, coupling can be used so that it enables objects to talk to each other while also preserving the scalability and flexibility."

"In OO programming, coupling is unavoidable. Therefore, the goal is to reduce unnecessary dependencies and make necessary dependencies coherent."

Example :

Coupling is the unnecessary dependance of one component upon another
component's implementation. An example would be if you had a Dog class
that should be able to bark and jump. You could write it like this:

class Dog
{
void doAction(int number)
{
if(number==1)
//Jump code goes here
if(number==2)
//Bark code goes here
}
}

However, this way whoever used your class would have to follow your
convention that doAction(1) means jump and doAction(2) means bark. A
less-coupled way would be to write separate bark() and jump() methods.

Cohesion occurs when components are wired together in a smart, logical
way. If you have ever used a Controller class, that's a great example
of acheiving cohesion. Highly cohesive components interact with each
other semantically, in other words, they tell each other what they want
to do. In a bank example, an ATM object should be able to tell an
Account object to getBalance(), or withdrawFunds(), etc. These are
sensible ways for the ATM and Account to interact, not specific ways
that are only useful in one program.

So good OOD requires that components can interact powerfully, but
independently of eachother's implementation details. (Think of
System.out.println() - most people have no idea how that works, but
when you want to output some text, you can just use the method.)

Encapsulation is the use of hiding implementation details within your
code. Changing the above Dog code from doAction() to jump() and bark()
would be a step toward good encapsulation. This is getting
frighteningly nerdy, but I think you could say "A program with high
cohesion and low coupling exhibits good encapsulation". In other words,
encapsulation is the goal you're trying to reach when you reduce
coupling. A class with good encapsulation, in turn, lends it self to
being a cohesive part of a system.

Ref:
http://www.velocityreviews.com