Procedural and OO encapsulation

Question

I search a complete description on the concept of encapsulation and i see that the answers found are somehow like pieces of puzzle and must be put together. I found the fallowing descriptions of this concept:

Encapsulation is the technique of making the fields in a class private and providing access to the fields via public methods. If a field is declared private, it cannot be accessed by anyone outside the class, thereby hiding the fields within the class. For this reason, encapsulation is also referred to as data hiding. (source tutorialspoint)

A language mechanism for restricting access to some of the object's components A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data. (source wikipedia)

Encapsulation allows an object to separate its interface from its implementation. The data and the implementation code for the object are hidden behind its interface.

Encapsulation is a technique. It may or may not be for aiding in abstraction, but it is certainly about information hiding and/or organisation. It demands data and functions be grouped in some way - of course good OOP practice demands that they should be grouped by abstraction. However, there are other uses which just aid in
maintainability etc. (source stackoverflow)

In procedural programming is mainly the same i think and here the best example is the FILE struct that is created or modified only by the file functions.

I was wondering what else could be added to have a complete image of this programming concept because it's very useful to know it in specially at designing a API or an interview question.

Answer 1

You are right: encapsulation is a general technique that allows to implement the principle of information hiding and is thereby found in various parts of computer science and even in other fields.

You already mentioned the FILE pointer. Another simple C example would be any API that expects a pointer to a struct without declaring it. The interface user does not need to know how this struct is implemented, only the interface implementation needs to know that. So the information of the struct is hidden by encapsulating the desired action, the passing of the struct's info, into the action of passing a pointer.

Another example would be the network protocols: When requesting this page, your browser used HTTP, which in turn uses the Transfer Control Protocol TCP. On a level below, there is only the Internet Protocol IP with a payload, no TCP. There, TCP is just some unneeded information encapsulated in the IP payload. On a level below, there is no IP, but MAC, and IP is some unneeded information encapsulated in the MAC payload.

And a maybe slightly far-fetched real-life example: Sending a teddy bear by mail. The interface of your postal service expects a box with the address information. It will not look into the box, and will not see the bear. When the recipient receives the package he will open it and he can cuddle with the bear. Now imagine the postal service was planned for sending you teddy bear. How reusable would this interface (bear + address) be? Little. Instead we apply abstraction and create an interface (box + address). And we apply encapsulation by putting our teddy bear into a box, hiding the information that we're actually sending a teddy bear. Poor teddy.

Answer 2

Encapsulation is all about split your system/application in well-defined high-cohesive parts. The simple fact of creating a function/procedure is an encapsulation.

OOP languages normally provide ways to improve/achieve encapsulation, such as visibility modifiers (Information Hiding Principle).

Encapsulation is one of the key principles that OO is based on, so many people have a mistaken idea that it is an exclusively OO feature.

Another thing, this is wrong:

Encapsulation is the technique of making the fields in a class private and providing access to the fields via public methods.

This is Information Hiding Principle.

Answer 3

I'll show it with a stupid simple example. Let's define a circle class:

public class Circle {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    public double getRadius() {
        return radius;
    }

    public double getPerimeter() {
        return 2 * radius * Math.PI;
    }
}

Notice how the radius is a private field, that can't be accessed directly from the outside. That's encapsulation. Encapsulation allows changing your mind after the class has been designed and used by other classes already, without breaking these other classes and clients:

public class Circle {
    private double diameter;

    public Circle(double radius) {
        this.diameter = radius * 2;
    }

    public double getRadius() {
        return diameter / 2;
    }

    public double getPerimeter() {
        return diameter * Math.PI;
    }
}

The state of the object is now represented differently. But since this state is encapsulated into the object, and the interface (the public methods) of the object doesn't change, clients can still use the object as if nothing had changed.

If encapsulation was not used, and the radius field was public, you couldn't change the implementation of the class by removing the radius and replacing is with the diameter, because everybody already using the class would use the radius field.