encapsulation - when the internal state of objects can be changed only by the object itself (the ability of the object to maintain its internal state).

What is the object:

It is an entity that simultaneously contains behavior and data. Physical this entity is located in the address space of the computer (also in one place in memory).

An object has attributes such as attributes, states, behaviors.

An object can be a class, a group of classes, a subsystem.

What is the state of the object:

For example, if a person dyed his hair, then his state changed. hair color property has changed values.

Example: There is some abstract brain that can take information in a linear fashion.

1) The stage of data hiding

class Brain{ String capsule; }

We have already hidden the data by creating the Brain class. Now it can be accessed only by creating an instance of this class. There are no other ways to reach the capsule. Thus, the internal state of Brain can only change an object of this class.

We hide data by creating a Brain class from the outside world. The races attributes are hidden from the outside world; only the object itself can change its internal state.

 brain1 = new Brain(); brain2 = new Brain(); brain1.capsule = "Чайник"; brain2.capsule = "Магазин";

2) Stage hidden implementation details

 class Brain{ private String capsule; //Интерфейс методы для взаимодействия с объектом.(Слово интерфейс в широком понимании) public String getCapsule(){ return capsule; } public void setCapsule(String data){ if(!isBusy){ //проверям является ли этот информация корректным //если да то проверям может ли мозг принят его if(isCorrect(data) && isAccept(data)) capsule = data; }else{ waitPleas(); } } //Реализация private boolean isCorrect(String data){ } //Реализация private boolean isAccept(String data){ } private boolaen isBusy(){ } }

The Brain class has limited access to the data and has hidden implementation details. The client was given only interface methods.

  • brain1.capsule = "Teapot"; - but here the field value is set from the outside, and not by the object itself - Grundy
  • 3
    An object is a region of memory in which class methods are stored, and in an instance, fields. When re-allocating memory, an instance is created, but the object is not created. Encapsulation - hiding implementation. - Alexander Puzanov
  • In this context, consider the Brain class as an object. and brain1 is an instance. That is, when brain1 sets capsule values, then for a Brain object will there be a state change from outside? I thought that brain1 should not change the states of brain2) - natus vincer
  • 2
    @ Alexander Puzanov object - this is an instance. And you confuse object and class. - Pavel Mayorov
  • @Alexander Puzanov, I’m afraid to fan holivar around the AEC, but you’re talking about "practical understanding" of encapsulation in common languages. In the literature on cs, I repeatedly came across the definition of encapsulation, something like "combining data and methods of working with them in one entity." That is, concealment is not important, but the fact that we interfere with properties and behavior. - Duck Learns to Take Cover

1 answer 1

As for the object, you yourself answered your question in one sentence (with a slightly broken grammar, but understandable):

It is an entity that simultaneously contains behavior and data.

All Everything else that you have listed is irrelevant or even erroneous details.

What is the state of the object

Definitions you did not give, you immediately gave an example that does not describe what a state it is . And the answer is very simple. This is the data from the object definition given by you.

We have already hidden the data by creating the Brain class. Now it can be accessed only by creating an instance of this class. There are no other ways to reach the capsule.

A class is similar to a “project” for objects, by which objects can be created that have certain common features. In your example, the capsule is part of the Brain class objects, and it is impossible to reach the capsule without having an object of the Brain class not because of concealment, but because the capsule simply does not exist anywhere . capsule own for each object, and if there are no objects, then capsule are not.

An object can be a class, a group of classes, a subsystem.

Can. And not only this. These are examples, not definitions.

Unless from the aforesaid you can wonder whether a class can be considered an object. In the context of the above definition is usually possible. In modern programming languages, it is often possible to determine precisely the class of fields and behavior. And somewhere, even the semantics of the language directly states this ( Class.new.is_a?(Object) # => true in Ruby ).

But this is the general concept of an object. In a specific language, it may differ. In C ++, for example, it is customary to call objects instances of classes and structures, they are full-fledged values, they can be passed to functions and returned from there. Classes in C ++ are not objects from this point of view.

The idea of encapsulation is to separate the user and the developer , on the assumption that the user cannot change the definition of an object (more often indirectly, by changing the definition of the class to which the object belongs), and the developer can.

This is done by hiding for the external inspection of those parts of the class that the user does not need to see . From the inside (from the assumption above, that only the developer is inside), all the details are still visible.

Basically, this is a "noise filter" . Having made something private, the developer says something like "you don't need it anyway with regular use . " If the cover-up did not exist, the developer would have to somehow mark some of the accessible contents of the object as “implementation details” in the documentation.

For some reason, many people believe that encapsulation is a ban, like “don't touch it” hands in a museum. That it protects the object from the encroachments of unscrupulous users . She really performs this task. If there was no concealment, the user could have more opportunities to violate the documentation and get the object in an incorrect state, which could result in anything.

But avoiding a number of such problems is rather a pleasant bonus than a real purpose: in the end, somewhere you can simply edit the class in order to climb into the fields that the developer did not conceive of as public, somewhere you can open the places of interest with a crowbar reflection.