Each week I intend to discuss an object-oriented programming concept, often from an unusual perspective. This week I want to talk about encapsulation and aggregation.
|
 |
Encapsulation
Photo used under Creative Commons from Thirteen of Clubs via flickr.com
Encapsulation is when you create a wrapper around something in order to hide some of its details from outside view. For example, if you put on a ski mask, you are encapsulating your head!
Aggregation
Photo used under Creative Commons from Alan Cleaver via flickr.com
Aggregation is when you group things together and treat them as a unit. If you put six coins in a piggy bank, you are aggregating the coins using the piggy bank as the container.
Aggregation vs. Encapsulation
Aggregation is used when you want to treat a collection of objects as a unit
Encapsulation is used when you want to hide the details of an object from outside view.
They seem kind of similar, don’t they? Well, they are and they aren’t.
If you’ll forgive the crude expression, encapsulation is why you wear underwear – to protect your private parts.
Encapsulation is concerned with the notion of visibility – what parts of an object can be seen (“are visible”) by other objects.
Aggregation is concerned with grouping objects in some way, often with little or no visibility of the individual objects.
Can you encapsulate an aggregate? Of course! Can you aggregate encapsulated objects? All the time!
Wrap It Up, or Bag It?
You can think of both encapsulation and aggregation as ways to “wrap” one or more objects inside another, but that’s not entirely accurate. Encapsulation is more of a built-in feature of an object-oriented programming language supporting the fundamental notion of an object: as an encapsulated something. Typically, encapsulation is manifested as the wrapper around the constituents of an object – its methods and properties – and is used to control the visibility of the wrapped elements. Some properties would be public and the rest private, for example.
A combination of aggregation and encapsulation is a common way to create new constructs. You can aggregate several interrelated objects and wrap (encapsulate) them in another object that exposes some but not all of them. For example, a Stack class might contain an aggregate for its stacked objects, and expose only the Top element (as a property) plus Push and Pop methods.
OOP Under the Hood
Under the hood of a Stack, we still have the aggregated (stacked) objects visible to the methods of the Stack class. External to the Stack class, however, the aggregated objects are not directly accessible.
If we allowed external objects to reach in and meddle with the aggregated objects, the integrity of our stack may be affected. If we initially used an Array to hold the aggregated objects in the Stack and later changed to a List, external objects that were relying on the Stack’s Array would break. By reducing visibility with encapsulation, we:
- prevent external objects from relying on unnecessary implementation-specific details, and
- protect our private data from outside interference
OOP Philosophy
Encapsulation is typically used to wrap up a group of interrelated things, be they properties, methods, or subobjects, while aggregation is used to collect a bunch of incidentally related things. All the coins in my piggy bank are incidentally related because they’re all mine, and they’re all in the same container. All the toy blocks stacked up in a tower are interrelated because they support each other.
Many OOP languages and books distinguish the notions of collections, containment, and components, and rightly so: these are refinements of the basic concept of aggregation. But, we are not concerned with the various shades of the basic concept at this time.
So what’s the dividing line between aggregation and encapsulation?
Let’s imagine that we don’t have two distinct concepts of encapsulation and aggregation, but instead we have a more general notion of “wrapping”. Can we still do OOP this way?
Yes, we can – if we treat the traditional OOP elements of properties and methods as if they were stand-alone objects (instead of non-object “primitives”), we can see that “wrapping” properties and methods (with public or private visibility attributes) achieves encapsulation, while “wrapping” several complete objects as a collection achieves aggregation.
In practice, most OOP languages distinguish encapsulation from aggregation by using different built-in language operators and assumptions. But is this necessary?
It really isn’t, because without the notion of visibility, aggregation and encapsulation are the same thing.
So in the end, visibility is what distinguishes encapsulation from aggregation.
Agree or disagree? Talk back in the comments!
About Steven A. Lowe