Why is it necessary to encapsulate what changes?

Using encapsulation creates an entity with a known behavior (external interface). At the same time, all the necessary information for the" functioning " of this entity is contained in it.

That is, the interface and implementation are separated. It is assumed that the interface will be stable (not subject to frequent changes), and the implementation may undergo frequent changes. Without encapsulation, this can only be done with functions (behaviors), but not with entities (by classes).

When properly designed, only the interface part of the class is used, without any assumptions about its internal implementation. Because of this, changes in the implementation (even radical ones) of one class do not affect others, which makes it easier to change programs and makes it less error-prone.

For example, the driver's car direction control system consists of a steering wheel, the rotation of which causes the wheels to turn ( interface). At the same time, the system itself can be implemented in different ways and from different components (steering rack, trapezoid, etc.-implementation). However, thanks to the encapsulation of with the separation of the interface and the implementation, the change of cars from the point of view of steering is almost imperceptible for drivers.

In general, the idea of encapsulation is well illustrated (and apparently came out of there) by the concept of abstract data types (you can read, for example, in Aho, Hopcroft, Ullman. Data structures and algorithms). For example, there is a stack with methods (interface) push and pop. At the same time, the implementation of the stack can be anything, but from the point of view of the interface, there are no differences. Before there was support for this concept in programming languages, you had to implement encapsulation yourself, which imposed requirements for self-discipline. However, then, this concept was supported at the level of programming language constructs. This difference can be it is good to see the example of the related languages C and C++.

Encapsulate what varies-Encapsulate what will change
P.S. The word encapsulate should not be taken literally as an OOP principle.

One of the basic principles of application design is discussed in many books on design patterns, for example, it goes first in O'Reilly Head First Design Patterns.

The idea is to localize when writing code that may become more complex/change in the future due to new requirements, so that these the changes did not affect other parts of the app. This is usually done using interfaces, abstract classes, and template methods .

The simplest example is that if you are making a duck simulator, you don't need to implement the quack() method in the base Duck class, because rubber ducks don't quack. Of course, we can say that this method can be redefined to an empty plug for a rubber duck, but there may be other non-quacking ducks. The idea is to anticipate the changing environment. the part in the application (implementation of quack) and localize it from the rest of the application (in the book, this is the use of the strategy pattern).

In this way, you can separate the interface of an object from its implementation. For example:

class IFigure
{
public:
   virtual void draw() = 0;
};

class Ellipse : public IFigure
{
public:
   void draw() {
      // Нарисовать эллипс.
   }
};

class Polygon : public IFigure
{
public:
   void draw() {
      // Нарисовать многоугольник.
   }
};

void drawFigure(IFigure* figure) 
{
   if (figure)
      figure->draw();
}

IFigure* newFigure(Figure type)
{
   switch(type)
   {
   case 'e':
      return new Ellipse();
   case 'p':
      return new Polygon();
   }
   return NULL;
}

using namespace std;

void main() 
{
   IFigure* figure;
   while(true) {
      cout << "Что нарисовать? (e - эллипс, p - многоугольник) ";
      figure = newFigure(getch(cin));
      drawFigure(figure);
      free(figure);
   }
}

Interface export is widely used, for example, in Windows in the COM (Component Object Model) technology, which replaced OLE (Object Linking and Embedding).

When sharing objects created inside a DLL and used in the application code, it is important that the object is removed from memory in time - that is, when it is no longer needed, and not later and not earlier. To do this an interface with link counting functions is used.

typedef struct {
   void (*AddRef)(void* pObject);
   void (*Release)(void* pObject);
} ICOMObject;

The library exports the interface request function by its UUID - the unique interface identifier.

HRESULT getInterface(const char *pUUID, IComObject** ppObject);

The client requests the interface, gets it, and calls the AddRef () function, incrementing the reference count by one. When the interface is no longer needed, the client calls the Release () function, which reduces the reference count by one. If the reference count becomes zero, the Release() function deletes the created COM object.

Encapsulation is primarily needed to hide implementation details that no one should know about. For example, take the class of some abstract parser:

/**
 * Пусь это будет парсер e-mail'ов со страницы
 */
class Parser {

    /**
     * Про
     * @var type 
     */
    private $clear_url = null;

    public function parse($url) {
        if ($this->checking_url($url) == true) {
            $page_content = $this->load_page();
            return $this->content_analize($page_content);
        }
    }

    /**
     * Метод проверяет URL
     * @param type $url
     */
    private function checking_url($url) {
        //Проверяем каким-нибудь способом корректность $url
        $this->clear_url = $url;
        return true;
    }

    /**
     * По $this->clear_url загружаем контент
     * @return type
     */
    private function load_page() {
        //По $this->clear_url загружаем контент и возвращаем его $content
        return $content;
    }

    /**
     * Анализируем контент и получаем все E-mail адреса
     * @param type $content
     * @return type
     */
    private function content_analize($content) {
        //Анализируем контенте и из полученных адресов формируем массив $result
        return $result;
    }

}

When writing the class, we hid almost all the work in the private methods, leaving only one public. Why did we do this, because it was possible to make all the methods public? - if we made all the methods public, then our class would not be protected from misuse, which could easily happen lead to an error.

Accordingly, the use of encapsulation helps to protect the object data from possible errors., which may occur when accessing this data directly.