views:

1372

answers:

5

"Abstraction and encapsulation are complementary concepts: abstraction focuses on the observable behavior of an object... encapsulation focuses upon the implementation that gives rise to this behavior... encapsulation is most often achieved through information hiding, which is the process of hiding all of the secrets of object that do not contribute to its essential characteristics." - Grady Booch in Object Oriented Analysis and Design

Can you show me some powerfully convincing examples of the benefits of encapsulation through information hiding?

A: 

What? You're not convinced yet?

It's easier to show the opposite. We used to write code that had no control over who could access details of its implementation. That made it almost impossible at times to determine what code modified a variable.

Also, you can't really abstract something if every piece of code in the world might possibly have depended on the implementation of specific concrete classes.

John Saunders
+6  A: 

The *nix abstraction of character streams (disk files, pipes, sockets, ttys, etc.) into a single entity (the "everything is a file") model allows a wide range of tools to be applied to a wide range of data sources / sinks in a way that simply would not be possible without the encapsulation.

Likewise, the concept of streams in various languages, abstracting over lists, arrays, files, etc.

Also, concepts like numbers (abstracting over integers, half a dozen kinds of floats, rationals, etc.) imagine what a nightmare this would be if higher level code was given the mantissa format and so forth and left to fend for itself.

MarkusQ
A: 

Nearly every Java, C#, and C++ code base in the world has information hiding: It's as simple as the private: sections of the classes.

The outside world can't see the private members, so a developer can change them without needing to worry about the rest of the code not compiling.

David Norman
I don't know that I would go so far as to say "without needing to worry about the rest of the code not compiling". You can certainly break compiles while changing only private members. The benefit is more along the lines of being able to completely re-write the internals of a class as long as you don't change the external interface. This is great for certain types of optimizations.
Toji
+5  A: 

The example given in my first OO class:

Imagine a media player. It abstracts the concepts of playing, pausing, fast-forwarding, etc. As a user, you can use this to operate the device.

Your VCR implemented this interface and hid or encapsulated the details of the mechanical drives and tapes.

When a new implementation of a media player arrives (say a DVD player, which uses discs rather than tapes) it can replace the implementation encapsulated in the media player and users can continue to use it just as they did with their VCR (same operations such as play, pause, etc...).

This is the concept of information hiding through abstraction. It allows for implementation details to change without the users having to know and promotes low coupling of code.

Ben S
+2  A: 

I know there's already an accepted answer, but I wanted to throw one more out there: OpenGL/DirectX

Neither of these API's are full implementations (although DirectX is certainly a bit more top-heavy in that regard), but instead generic methods of communicating render commands to a graphics card.

The card vendors are the ones that provide the implementation (driver) for a specific card, which in many cases is very hardware specific, but you as the user need never care that one user is running a GeForce ABC and the other a Radeon XYZ because the exact implementation is hidden away behind the high-level API. Were it not, you would need to have a code path in your games for every card on the market that you wanted to support, which would be completely unmanageable from day 1. Another big plus to this approach is that Nvidia/ATI can release a newer, more efficient version of their drivers and you automatically benefit with no effort on your part.

The same principle is in effect for sound, network, mouse, keyboard... basically any component of your computer. Whether the encapsulation happens at the hardware level or in a software driver, at some point all of the device specifics are hidden away to allow you to treat any keyboard, for instance, as just a keyboard and not a Microsoft Ergonomic Media Explorer Deluxe Revision 2.

When you look at it that way, it quickly becomes apparent that without some form of encapsulation/abstraction computers as we know them today simply wouldn't work at all. Is that brilliant enough for you?

Toji