Aggregation and Composition - An Overview
In Java, and in object-oriented programming in general, Aggregation and Composition are two types of associations between classes, often used to represent "has-a" relationships. Both allow you to create complex objects by combining simpler ones, but they differ in terms of ownership and the lifecycle of the involved objects.
Aggregation and composition are two concepts in programming that describe relationships between objects. They're a bit like different ways of organizing teams in an office. Let's break them down in simple terms:
Aggregation - The Teamwork Approach: Imagine a group of employees in an office working on a project. Each team member has a distinct role, like marketing, finance, or development. This is like aggregation. In programming, aggregation is a relationship where one object is made up of several other objects, but each of those objects can exist independently. Just like a team member can be part of different projects or teams, in aggregation, the individual objects can belong to multiple relationships. It's often described as a "has-a" relationship but with a sense of independence.
Composition - The Department Approach: Now, think of a department in an office, like the Human Resources department. This department can't function without its employees. If the department closes, the roles of HR Manager, Recruiter, etc., also cease to exist. This is like composition. In programming, composition is a stronger relationship where the composed objects cannot exist independently of the parent object. If the parent object is destroyed, the composed objects cease to exist. It's a more dependent "part-of" relationship.
Examples in Real Life: Think of a car (aggregation) — it has an engine, wheels, and seats. These parts can exist independently of the car. You can remove the engine, and it's still an engine. Now think of a house (composition) — it has rooms. Rooms can't exist without the house. If you demolish the house, the rooms also disappear.
Importance in Programming: Understanding aggregation and composition helps programmers manage object relationships in a way that makes sense for their applications. It's crucial for designing systems where objects are interrelated but might have different lifecycles and degrees of dependency.
In programming, aggregation is a relationship where objects can exist independently (like team members working on a project), while composition is a more dependent relationship where if the parent object ceases to exist, so do the composed objects (like rooms in a house).
Aggregation
In Aggregation, the part entity is independent of the whole entity, meaning that the part can exist even if the whole is destroyed. When the whole entity is deleted, it does not necessarily mean the part entity will be deleted. Aggregation represents a "weak" association.
For example, consider a Library
and Book
classes. A library will contain books, but if the library is destroyed, the books can still exist.
class Book {
String title;
// ...
}
class Library {
List<Book> books;
// ...
}
Here, deleting the Library
object doesn't mean the Book
objects have to be deleted. The Book
objects can exist independently of the Library
.
Composition
In Composition, the part entity cannot exist without the whole entity; the lifecycle of the part entity is controlled by the whole entity. Composition represents a "strong" association.
For example, consider a Car
and Engine
classes. An engine is a part of a car, and if the car is destroyed, the engine will be destroyed as well.
class Engine {
// ...
}
class Car {
Engine carEngine;
// ...
}
Here, if the Car
object is destroyed, it's logical that the Engine
object should also be destroyed as it is a part of the car.
Summary
Aggregation: Represents a "has-a" relationship but allows the part to exist independently of the whole (Weak association).
Composition: Represents a "has-a" relationship and does not allow the part to exist independently of the whole (Strong association).
In code, both Aggregation and Composition are generally implemented by using instance variables that refer to other objects. However, the difference comes from the rules of ownership, object lifecycle, and the nature of their relationship, which are often enforced programmatically by the logic surrounding object creation and deletion.
COSC-1437 / ITSE-2457 Computer Science Dept. - Author: Dr. Kevin Roark