Difference between class abstraction and class encapsulation ?

[isam alie]

As far as I understand, class abstraction is the separation of class implementation for class use.
and class encapsulation is the hiding of the details of the class implementation.

For example, say we have a Car class, the abstraction part will be that I do not think about how the Car class is implemented (its data fields and methods) when I use it. While
the encapsulation part would be that placing everything related to a car in the Car class, and then providing a class interface for the user to use the class.

Is my understanding the class abstraction and class encapsulation correct ? I feel they are kinda of the same. Also I've read that abstraction is dependent on encapsulation (the abstraction is achieved through encapsulation)

I dunno this seems to be a bit complicated.

[isam alie]

from*

And there is information hiding (It's claimed to be the same as encapsulation)

[Junilu Lacar]

Yes, you got it. Don't overthink it. They are both related but they're different perspectives.

Think of it like this: If you are a cashier at a store, abstraction is like you thinking about the customer paying for a purchase. That's the main behavior you care about. Implementation is whether the payment is done with cash, card, or check.

On the other hand, encapsulation is about the Customer knowing how much money they have in their bank account, how much cash they have in their wallet, or how much more they can charge before they reach their credit limit. To you, the cashier, that is information you are not privvy to,  i.e. the information is hidden from you. Any attempt by you to obtain that information is inappropriate, i.e. you would be violating your customer's privacy or in ther words, you're breaking their encapsulation.

Does that make sense?

[Junilu Lacar]

isam alie wrote:from*
And there is information hiding (It's claimed to be the same as encapsulation)

Encapsulation involves information hiding, yes, but it's only part of it. Encapsulation also involves the behaviors that operate on the information. There's also the abstraction part of it where you don't really care if the data is actually kept in the object as an instance variable or if it simply calculated. So to say encapsulation is the same as information hiding is like saying a painting is the same as the frame around it.

[isam alie]

Junilu Lacar wrote:Yes, you got it. Don't overthink it. They are both related but they're different perspectives.

Think of it like this: If you are a cashier at a store, abstraction is like you thinking about the customer paying for a purchase. That's the main behavior you care about. Implementation is whether the payment is done with cash, card, or check.

On the other hand, encapsulation is about the Customer knowing how much money they have in their bank account, how much cash they have in their wallet, or how much more they can charge before they reach their credit limit. To you, the cashier, that is information you are not privvy to,  i.e. the information is hidden from you. Any attempt by you to obtain that information is inappropriate, i.e. you would be violating your customer's privacy or in ther words, you're breaking their encapsulation.

Does that make sense?

Thank you for the example.

Here is an example I came up with after doing a little more search.


Say you have a RAM class and a HDD class, the RAM uses the HDD to read and write files. If the HDD class was "well encapsulated" (the implementation details of how the HDD stores files and searches for them are hidden) then the RAM just use two methods, one to write to the HDD (say hdd1.writeFile(File f)) and another to read from (say hdd1.readFile(File f)) and that achieves the concept of abstraction, because the RAM class is not concerned with how the files are stored within the HDD, it just reads and writes to it using two methods (through the class interface), so the the implementation of HDD class is separated from the use of it.

However, if the HDD was not "well encapsulated" (its implementation details are visible to the client/user classes), then the RAM class will do something like this to read a file from the HDD :

File logFile = null;
for(File file : hdd1.files)
    if(file.getName.equals("logFile")
        logFile = file;

In the preceding code we see that the implementation details of the HDD class are exposed (for example we know that the HDD class stores the files in an array), thus the concept of encapsulation is not fulfilled.
Also, we see that the use of the HDD class is not separated from the its implementation (when we use it we actually think of how its implemented in order to read a file), thus the concept of abstraction is not fulfilled, as well.

So, what we can conclude is that encapsulation is a requirement for abstraction. If there were no encapsulation (the encapsulation is violated), there would be no abstraction.

I hope you validate me on my understanding.  

Thank you once again.

[isam alie]

"Class abstraction separates class implementation from class use, by encapsulating the implementation details of the class,
and providing an interface to interact with/use the encapsulated class."  

[Junilu Lacar]

I think more or less you get the idea.

A guy named Joel Spolsky famously noted that all non-trivial abstractions, to some degree, are leaky. Your example shows that but it's not an egregious violation of encapsulation. In some cases, you can't help doing that kind of thing and it's partly because the language itself allows you to do it.

Consider this alternative to the code you gave:

     Optional<File> logFile = hdd.find(f -> f.getName().equals("logFile"));
     if (logFile.isPresent()) {
          ... logFile.get() ... // do something with the file we found
     }

Providing a Optional<File> find(Predicate<File>) method in the HDD class is arguably a more encapsulated design than just having a List<File> files() method.

But what if you didn't have the ability to modify the HDD class and add a find() method like that? What if it the HDD class was not something you developed and you didn't have the source code to it and it was a final class? Then you're probably stuck with the interface you get and if it only has a List<File> files() method, then the code you wrote is the only way to do something with that list of files encapsulated by the HDD class.

My point in all this is that trying to stick to principles is good but there are times where the principles are broken and you just have to do your best to minimize the bad effects of that.

[Junilu Lacar]

One way to protect your design from any bad effects of breaking encapsulation is to make defensive copies. In your example, the List<File> files() method in an HDD class might be implemented as returning a copy of the list it manages instead of a reference to its internal list. It could also make it an unmodifiable list.

/**
 * Returns an unmodifiable list of files that this
 * hard drive contains.
 */
public List<File> files() { ... }

// alternatively, it could be designed like this
/**
 * Returns snapshot of the list of files that this hard drive 
 * contains. Any changes to the returned list will not affect
 * what is on the hard drive. The list is not guaranteed to 
 * reflect the current state of the hard drive over time, only
 * what it was when this method was invoked.
 */
public List<File> files() { ... }

So it's important to understand some of the limits/constraints of encapsulation and how methods are designed. To some degree, as the Law of Leaky Abstractions asserts, there exists a leaky abstraction in those designs where the implementation details are kind of relevant to the proper use of the class.