Difference Between Abstraction & Aggregation
8/22/2009 6:56:00 PM
It is easy to confuse abstraction and aggregation. Briefly, I will shed some light on the difference between the two in this article because they are core concepts that must be grasped by any serious architect.
Abstraction
In one of my previous articles I highlighted that the art of abstraction is the bread-and-butter for an architect. I also mentioned that the application of abstraction is behind most, if not all the progress that humanity has made and the enabler of any progress that the humanity will make.
As a recap, abstraction is about generalizing entities, especially complex ones and the ones involving many processes or parts, into one single entity. It is very important to note that this entity must have laser-focused, single responsibility or else this is not abstraction. This generalization accomplishes two major benefits and enablers of human progress. They are paramount for innovation:
1- Simplification. When things are made simpler, we can do more and create more complex innovations. I attributed this mainly to the limitation of how many entities can the human brains grasp at the same time. We must condense in order to progress.
2- Reuse. When something is generalized, it can apply to many more situations and that in turn, will boost progress.
As examples, chances are, I can bet you that anything you think about is an abstraction. A programming function is an abstraction. A class type is an abstraction. A component is an abstraction. Pure Fabrication in GRASP (the activity of creating a new class that doesn't map to a real-life object) is an abstraction activity. The SRP (Single Responsibility Principle) is about abstraction. A SOA service is an abstraction. A framework is an abstraction. An operating system is an abstraction. A car is an abstraction. A post office is an abstraction etc... I hope you catch the drift.
The main thing to note about these abstraction is that they all perform a single responsibility that they accomplish. They are not simply a group of items.
Aggregation
Aggregation on the other hand is one type of abstraction. A subclass of abstraction in that it shares the benefits or purpose of abstraction but with a specific way.
Aggregation is a method of grouping the individual entities under one access point. It doesn't involve responsibility of performing the actual action. Like a catalyst or a middle man. So one major characteristic of this single access point is that it doesn't do any of the functions of the individual parts it is aggregating. Otherwise, it is not aggregation, it is abstraction. Its pure function is to group. That is its meta responsibility. Not to get involved in any of the details (please don't confuse that with delegation).
Examples of aggregation would be a the Facade pattern, a service layer, and a Message Bus. In business, one can see Unions aggregating employees, iTunes as an aggregator of music (iTunes simply groups all the individual artists but is not in music production itself), Google is an aggregator (when you search for electronics, Google doesn't do electronics but they group them for you). Aggregation seems to be the big opportunity in business ventures these days. The name of the game.
With this definition, one can see that aggregation shares the same benefits of abstraction, i.e., simplification and reuse but not its broadness. Aggregation has an already pre-defined single responsibility and doesn't get involved in the function of that which is aggregating, while abstraction is generic, a supertype if you will that most of the time is the function and carries the responsibility itself.
