Why do you need to encapsulate what changes?

With the help of encapsulation , an entity with a known behavior (front end) is created. Moreover, all the necessary information for the "functioning" of this entity is contained in it.

Those. 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 be done only with functions (behavior), but not with entities (classes).

With proper design, only the interface part of the class is used without any assumptions about its internal implementation. Due to this, changes in the implementation (even radical) of one class do not affect others, which facilitates the process of changing programs and makes it less error-prone.

For example, the system of controlling the direction of movement of the car for the driver consists of a steering wheel, the rotation of which leads to the rotation of the wheels ( interface ). In this case, the system itself can be implemented in different ways and from different components (steering rack, trapezoid, etc. - implementation ). However, thanks to the encapsulation with the separation of the interface and the implementation of the change of vehicles from the point of view of steering occurs for drivers almost imperceptibly.

In general, the idea of ​​encapsulation is well illustrated (and, apparently, came from there) by the concept of abstract data types (you can read, for example, in Aho, Hopkroft, Ulman. Data structures and algorithms ). For example, there is a stack with methods (interface) push and pop . In this case, the implementation of the stack can be anything, but from the point of view of the interface there are no differences. Prior to the emergence of support for this concept in programming languages, it was necessary to implement encapsulation itself, which imposed requirements for self-discipline. However, then, this concept was supported at the level of programming language constructs. This difference can be clearly seen in the example of the related languages ​​C and C ++.

Encapsulate what varies - Encapsulate what changes
PS The word encapsulate should not be literally taken as the OOP principle.

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

The idea is to localize when writing code that may become more complicated / change in the future due to new requirements so that these changes do not affect other parts of the application. Usually, interfaces, abstract classes and template methods are used for this.

The simplest example is if you make a duck simulator, then you do not need to use the quack () method in the Duck base class, because rubber ducks do not quack. Of course, we can say that this method can be overridden to an empty cap for a rubber duck, but there may be other non-quacking ducks. The idea is to anticipate the changing part in the application (quack implementation) and localize it from the rest of the application (in the book, this is the use of the pattern strategy).

In this way, you can separate the object's interface 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 has 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 be removed from memory in time — that is, when it is no longer needed, and not later and not earlier. For this, an interface with reference 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, which is the unique identifier of the interface.

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

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

Encapsulation, first of all, is necessary to hide implementation details about which no one should know. 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 a class, we hid almost all the work in private methods, leaving only one public. Why did we do this, because it was possible to make all methods public? - if we had made all methods public, then our class would not be protected from misuse, which could easily lead to an error.

Correspondingly, the use of encapsulation helps to protect the object's data from possible errors that may occur during direct access to this data.