Encapsulation vs data hiding (they are not the same)

Question

I am a little confused by whole terminology of encapsulation and data hiding. I'm reading a book "Dive into design patterns" by refactoring guru and when he explains what encapsulation is, I thought that something is off.

I've searched and I found a really nice explanation: https://stackoverflow.com/a/28614407/11993214.

He mistook encapsulation with data hiding. After reading answer from above link I sum this up to those definitions:

encapsulation - is when we are seperating from a piece of code, data and methods, which are using these data, and we are packing them together. data hiding - is a place where everything we can, we do as private and we are implementing getters and setters as the only places from which we can access this data.

But as I read more, I've got even more confused. He made a topic: Encapsulate what varies. It have two subcategories - encapsulate on method level, and on class level. It says for example to remake this:

into this:

I think it's similar to the statement from question from link above.

Whatever changes encapsulate it. Protecting anything which is prone to change.

, and answer to this was:

(...) And 2, as noted by CommuSoft, isn't really a definition, it's a rule of thumb. And I will add that it's a rule of thumb about when to use data hiding, not encapsulation

So now, I have this section from book, and based on this example that I gave I think that it is more likely to be an encapsulation case. But if I'm thinking correctly and it is similar to the quotes from linked topic, than based on that answer this example code is a rule of thumb about when to use data hiding? So to sum up... I'm really confused if I understand encapsulation and data hiding correctly. Based on those examples which I provide, I'm thinking that this example is encapsulation. Is it correct? And if yes, than how is it different from the topic mentioned in quotes?

I'm looking forward to your answers, and if this whole explanation is not clear than please give me feedback, and I will try my best to do better.

Answer 1

The usual definition of "encapsulation" is binding together data -- specifically state -- with the methods that operate on it, and "data hiding" is restricting access to that data so that it can only be accessed via those methods that operate on it.

Using these definitions, encapsulation is a prerequisite for data hiding, because that's how you identify the methods with the privilege of accessing the data directly. Other ways are imaginable, but that's how it's done in an OOP language.

The author you're referring to seems to be using the word "encapsulation" in a broader sense of binding together units of logic as well as data, and providing an interface to that logic or data that protects the consumer from changes to the underlying details.

I think that is an OK use of the word, because:

• It expresses the same purpose as binding together methods with data;
• There's not really another word that expresses that concept very well; and
• That operation of binding things together into a unit behind some kind of interface (not necessarily an OOP "interface") is how you accomplish the "separation of concerns" and implement the Single Responsibility Principle. Performing this operation is what software design is all about, so it needs a word.

In the example you give, the details of the tax rate calculation are extracted (encapsulated) into their own unit with a simple interface (getTaxRate). This is encapsulation of logical details, not data, but it still works. As the author states, the reason to do this is because these details are prone to change, so you don't want to scatter or copy them all around the code -- gather them into one place and make an interface that allows you to change them in the future without messing with all the code that uses them.