Understanding Aggregation

Introduction to Aggregation

In the previous demo, you learned about composition in OOP. Aggregation is another type of association that represents a “has-a” relationship between two or more classes. However, it’s more accurately described as a “uses-a” relationship, where one class utilizes another. Unlike composition, the classes involved in an aggregation relationship can exist independently. When one object is destroyed, it does not affect the other objects it’s related to.

For instance, the relationship between a table and a chair is an example of aggregation. The table can exist without the chair, and the chair does not need the table to exist. Similarly, a school can exist without a library.

Aggregation forms a weaker relationship between related objects than composition. To represent aggregation in a UML diagram, the entity that uses the other is indicated by an empty diamond at the end of the relationship line.

Using Aggregation

Maps and lists are data structures that use an aggregation type of relationship between their elements. It’s possible to remove items from a list and store them in another data structure. This leaves the list empty, which is a perfectly valid state for a list. Additionally, items can be created and used in the system long before being added to a list. The diagram below shows a demonstration of a shopping cart implemented as a list. It can be empty or full — either state is valid.

In Android, color resources and button views are completely separate UI components. You can use them together to create visually appealing UI. If you remove a button view, you don’t need to remove its color resource. A button will still function without color resources, but it may not look as good. In this case, the button only “uses” the color resource.

Learning to Use Aggregation

Aggregation is a type of relationship that’s similar to composition in many ways. It’s an associative relationship that offers benefits such as code reusability, easier maintenance, separation of concerns, and improved testing. Aggregation also has the advantage of providing better loose coupling between objects.

Knowing the Disadvantages of Aggregation

Related objects are independent and, as a result, you may need to manually manage their lifecycles from creation to termination. If you keep an expensive object idle in memory, you’ll have to rely on the garbage collector to reclaim it. This could lead to performance hits in large systems.

Creating separate classes might increase compilation overhead, resulting in the creation of numerous classes and files and making code organization challenging.

Understanding how to Establish the Best Form of Relationships in OOP

It’s crucial to think thoroughly about your app so you can establish the best form of relationship between your classes. If objects have a strong relationship and need to be managed together, then use composition. On the other hand, if related objects need to be managed separately and can exist independently, then use aggregation. It’s also important to consider the cost of maintaining your classes — whether they’re small but many or complex and resource-intensive.

In the next segment, you’ll implement an aggregation relationship in your e-commerce app.