OOP – Understanding Abstraction in Object-Oriented Programming

abstractionencapsulationobject-oriented

I hear that Abstraction is a technique that helps us identify which specific information should be visible, and which information should be hidden.
Encapsulation is then the technique for packaging the information in such a way as to hide what should be hidden, and make visible what is intended to be visible.

I understand Encapsulation well… A simple example would be a Method that calculates calories based on the parameters we provide. CalculateCalories(x,y,z) Here I don't know how this method calculates calories but I can call it to calculate the calories.

Abstraction is what I am confused about. What are those techniques that Abstraction uses to help identify which specific information should be visible, and which information should be hidden? Or am I misunderstanding the concept?

Could anyone give an intuitive example?

Best Answer

In functional programming, there is a concept called Map. Map is a higher-order function that applies a function to each element in a list.

In ordinary code, you would do something like:

var list = new List<int> { 1,2,3,4,5,6 };

var newList = new List<int>();

foreach(var item in list)
{
    newList.Add(item * 2);
}

// newList --> { 2,4,6,8,10,12 }

Rather than writing a loop each time, you create a Map method:

public List<T> Map<T>(this List<T> list, Func<T,TResult> function)
{
    var newList = new List<T>()

    foreach(T item in enumeration)
    {
        newList.Add(function(item));
    }

    return newList;
}

Now, instead of writing a loop each time, you can simply write:

var list = new List<int>() { 1,2,3,4,5,6 };

var modifiedList = Map(list, x => x * 2); // { 2,4,6,8,10,12 }

and get the same result.

The Map method is an abstraction over writing a loop to modify each member of a list.

I haven't mentioned it yet, but the <T> syntax is also an abstraction. It's called generics; it means that you can write a function that can operate on different data types, instead of writing functions for each data type.

All abstraction is a form of generalization: writing code that applies to more than one specific situation.

Related Solutions

Encapsulation – How Encapsulation Enhances Safety

How will encapsulation help when making changes in code and from its rippling effects. For a data member, if I change its type from int to float, (even if I am exposing this using property) I will need to change variable type where I am using already using this code.

The benefit of encapsulation is that it lets you change the internal implementation without breaking client code. It doesn't protect you if you decide that you need to change the interface to your code, but that's a different matter.

Example: Say you have a value representing the price per unit of some commodity. The price is expressed in cents, and because you don't deal in fractional cents you decided to make the property an integer (I'll use C here because I'm not very familiar with C#):

int _price

int pricePerUnit(void) {
    return _price;
}

int priceForUnits(int units) {
    return units * _price;
}

That all works out fine until one day when somebody notices that your firm is losing a lot of money due to rounding errors. Many of the commodities that you track are bought and sold in lots of many thousands of units, so you need to start tracking the price to an accuracy of at least 0.001 cent. Because you were smart enough to encapsulate the price instead of letting clients access it directly, you can make that change pretty quickly:

double _dprice

int pricePerUnit(void) {
    return (int)_dprice;
}

int priceForUnits(int units) {
    return (int)(units * _dprice);
}

The interface that clients use to obtain prices stays the same, but the data they get back is now more accurate. If the price per unit is $1.001, priceForUnits(1000000) will now return a price that's $1000 greater than before. That happens even though you haven't changed the interface to your system at all, and you therefore haven't broken any client code.

Now, that may not always be all that you need to do. Sometimes you'll need to change or augment your interface so that you can report the price more accurately to clients, too:

double pricePerUnit() {
    return _dprice;
}

A change like that will break client code, so you might instead keep the old interface and provide a newer, better routine:

int pricePerUnit() {
    return (int)_dprice;
}

double accuratePricePerUnit() {
    return _dprice;
}

You and the rest of your team can then embark on the process of converting all the clients of your system to use the newer, better accuratePricePerUnit(). The client code will get more accurate as you make progress on that task, but even the old stuff should continue to work as well as it did in the past.

Anyway, the point is that encapsulation lets you change the way the internals work while presenting a consistent interface, and that helps you make useful changes without breaking other code. It doesn't always protect you from having to update other code, but it can at least help you do that in a controlled manner.

C# – An alternative to multiple inheritance when creating an abstraction layer

Without knowing more I would focus on... Not doing that. Chains of subclasses is very rarely the answer, and I would submit never the answer for API implementation of the interface.

The problem is that the API isn't implementing the interface, it's already done. You're creating a least common interface from the different libraries. The focus then should be (if I understand the problem correctly) making your own API, with your own implementation agnostic data types and an adapter layer to the platform implementations (not an abstraction layer from the implementations).

Best Answer

Related Solutions

Encapsulation – How Encapsulation Enhances Safety

C# – An alternative to multiple inheritance when creating an abstraction layer

Related Topic