What's the difference between abstraction and encapsulation?

Question

In interviews I have been asked to explain the difference between abstraction and encapsulation. My answer has been along the lines of

• Abstraction<

Answer 1

The essential thing about abstraction is that client code operates in terms of a different logical/abstract model. That different model may be more or less complex than the implementation happens to be in any given client usage.

For example, "Iterator" abstracts (aka generalises) sequenced traversal of 0 or more values - in C++ it manifests as begin(), */-> (dereferencing), end(), pre/post ++ and possibly --, then there's +, +=, [], std::advance etc.. That's a lot of baggage if the client could say increment a size_t along an array anyway. The essential thing is that the abstraction allows client code that needs to perform such a traversal to be decoupled from the exact nature of the "container" or data source providing the elements. Iteration is a higher-level notion that sometimes restricts the way the traversal is performed (e.g. a forward iterator can only advance an element at a time), but the data can then be provided by a larger set of sources (e.g. from a keyboard where there's not even a "container" in the sense of concurrently stored values). The client code can generally switch to another data source abstracted through its own iterators with minimal or even no changes, and even polymorphically to other data types - either implicitly or explicitly using something like std::iterator_traits<Iterator>::value_type available.

This is quite a different thing from encapsulation, which is the practice of making some data or functions less accessible, such that you know they're only used indirectly as a result of operations on the public interface. Encapsulation is an essential tool for maintaining invariants on an object, which means things you want to keep true after every public operation - if client code could just reach in and modify your object then you can't enforce any invariants. For example, a class might wrap a string, ensuring that after any operation any lowercase letters were changed to upper case, but if the client code can reach in and put a lowercase letter into the string without the involvement of the class's member functions, then the invariant can't be enforced.

To further highlight the difference, consider say a private std::vector<Timing_Sample> data member that's incidentally populated by operations on the containing object, with a report dumped out on destruction. With the data and destructor side effect not interacting with the object's client code in any way, and the operations on the object not intentionally controlling the time-keeping behaviour, there's no abstraction of that time reporting functionality but there is encapsulation. An example of abstraction would be to move the timing code into a separate class that might encapsulate the vector (make it private) and just provide a interface like add(const Timing_Sample&) and report(std::ostream&) - the necessary logical/abstract operations involved with using such instrumentation, with the highly desirable side effect that the abstracted code will often be reusable for other client code with similar functional needs.

Answer 2

Why Encapsulation? Why Abstraction?

lets start with the question below:

1)What happens if we allow code to directly access field ? (directly allowing means making field public)

lets understand this with an example,

following is our BankAccount class and following is its limitation
*Limitation/Policy* : Balance in BankAccount can not be more than 50000Rs. (This line 
 is very important to understand)

class BankAccount
{
   **public** double balanceAmount;
}

Following is **AccountHolder**(user of BankAccount) class which is consumer of 
**BankAccount** class.

class AccountHolder
{
   BankAccount mybankAccount = new BankAccount();

   DoAmountCreditInBankAccount()
   {
       mybankAccount.balanceAmount = 70000; 
      /* 
       this is invalid practice because this statement violates policy....Here 
       BankAccount class is not able to protect its field from direct access
       Reason for direct access by acount holder is that balanceAmount directly 
       accessible due to its public access modifier. How to solve this issue and 
       successfully implement BankAccount Policy/Limitation. 
      */
   }
}

if some other part of code directly access balanceAmount field and set balance amount to 70000Rs which is not acceptable. Here in this case we can not prevent some other part of code from accessing balanceAmount field.

So what we can do?

=> Answer is we can make balanceAmount field private so that no other code can directly access it and allowing access to that field only via public method which operates on balanceAmount field. Main role of method is that we can write some prevention logic inside method so that field can not be initialized with more than 50000Rs. Here we are making binding between data field called balanceAmount and method which operates on that field. This process is called Encapsulation.(it is all about protecting fields using access modifier such as private)

Encapsulation is one way to achieve abstraction....but How? => User of this method will not know about implementation (How amount gets credited? logic and all that stuff) of method which he/she will invoke. Not knowing about implementation details by user is called Abstraction(Hiding details from user).

Following will be the implementation of class:

class BankAccount
{
   **private** double balanceAmount;

   **public** void UpdateBankBalance(double amount)
   {
    if(balanceAmount + amount > 50000)
    {
       Console.WriteLine("Bank balance can not be more than 50000, Transaction can 
                          not be proceed");
    }
    else
    {
       balanceAmount = balanceAmount + amount;
           Console.WriteLine("Amount has been credited to your bank account 
                              successfully.....");
    }
   }
}


class AccountHolder
{
   BankAccount mybankAccount = new BankAccount();

   DoAmountCreditInBankAccount()
   {
      mybankAccount.UpdateBankBalance(some_amount);
      /*
       mybankAccount.balanceAmount will not be accessible due to its protection level 
       directly from AccountHolder so account holder will consume BankAccount public 
       method UpdateBankBalance(double amount) to update his/her balance.
      */
   }
}

Answer 3

Encapsulation : Suppose I have some confidential documents, now I hide these documents inside a locker so no one can gain access to them, this is encapsulation.

Abstraction : A huge incident took place which was summarised in the newspaper. Now the newspaper only listed the more important details of the actual incident, this is abstraction. Further the headline of the incident highlights on even more specific details in a single line, hence providing higher level of abstraction on the incident. Also highlights of a football/cricket match can be considered as abstraction of the entire match.

Hence encapsulation is hiding of data to protect its integrity and abstraction is highlighting more important details.

In programming terms we can see that a variable may be enclosed is the scope of a class as private hence preventing it from being accessed directly from outside, this is encapsulation. Whereas a a function may be written in a class to swap two numbers. Now the numbers may be swapped in either by either using a temporary variable or through bit manipulation or using arithmetic operation, but the goal of the user is to receive the numbers swapped irrespective of the method used for swapping, this is abstraction.

Answer 4

My opinion of abstraction is not in the sense of hiding implementation or background details!

Abstraction gives us the benefit to deal with a representation of the real world which is easier to handle, has the ability to be reused, could be combined with other components of our more or less complex program package. So we have to find out how we pick a complete peace of the real world, which is complete enough to represent the sense of our algorithm and data. The implementation of the interface may hide the details but this is not part of the work we have to do for abstracting something.

For me most important thing for abstraction is:

1. reduction of complexity
2. reduction of size/quantity
3. splitting of non related domains to clear and independent components

All this has for me nothing to do with hiding background details!

If you think of sorting some data, abstraction can result in:

1. a sorting algorithm, which is independent of the data representation
2. a compare function, which is independent of data and sort algorithm
3. a generic data representation, which is independent of the used algorithms

All these has nothing to do with hiding information.

Answer 5

Simply put, abstraction is all about making necessary information for interaction with the object visible, while encapsulation enables a developer to implement the desired level of abstraction.

Answer 6

A program has mainly two parts : DATA and PROCESS. abstraction hides data in process so that no one can change. Encapsulation hides data everywhere so that it cannot be displayed. I hope this clarifies your doubt.