Object in OOP (Object Oriented Programming)

Objects in OOP are real-world objects.

Any software systems designed to simulate real systems, so it is very important in what terms we are trying to describe these real systems. The description in the form of a sequence of actions (a procedural approach to programming) turned out to be rather complicated. Object-oriented approach proposes to describe the system as an interaction of objects.

Suppose we need to develop a bank automation system. This system could be implemented as follows:

Object Interaction Scheme

In the operation of withdrawing money through an ATM, 3 objects are involved: “Client Ivanov”, “ATM on Tverskaya” and “Account No. 66579801”, which is open in this bank for Ivanov. Approaching the ATM and sticking his card, the object “customer Ivanov” sends a message to the ATM “Start work”. Having received such a message, the ATM displays some information and requests an access code, that is, the object “ATM on Tverskaya” sends a message to the object “customer Ivanov” - “Report the identification code”. If the identification is successful, the “client Ivanov” asks for 1000 rubles to be given to him. He sends a message about this to an ATM, and the latter in turn to the object “account no. 66579801”. By accepting this message, the object “account number 66579801 ″ checks if it has 1000 rubles, and, if it has, sends the permission to withdraw money, at the same time reducing its balance by the appropriate amount. The ATM transfers the money and the procedure ends there.

Objects perform the necessary actions by passing messages to each other.

Description in the form of objects allows you to define various components of the system. The same objects - “account number 66579801 ″ and“ client Ivanov ”- will participate in another operation where the client comes to the bank branch for withdrawing or crediting money to his account.

The given situation is a vivid example of the essence of the concept “ object in OOP ”. It is difficult to give a clear definition of this concept, I will quote this definition of Ivar Jacobson:

An object in an OOP is an entity capable of maintaining its state (information) and providing a set of operations (behavior) for checking and changing this state.

An object in object-oriented programming is a model or an abstraction of a real entity in a software system. The subject of modeling in the construction of an object in the OOP may be different. For example, there may be the following types of abstraction used when constructing an object:

• abstraction of the concept: an object is a model of a certain concept of a subject domain;
• action abstraction: an object combines a set of operations to perform a function;
• virtual machine abstraction: the object combines operations that are used by other, higher levels of abstraction;
• random abstraction: an object combines unrelated operations.

The state of the object in the OOP

Each object in the PLO is characterized by its state. The state of a bank account is the amount of money it holds. The state of the ATM includes the state "on" or "off", ready or not ready to accept the request, the availability of money in the ATM.

The state of an object is characterized by the current value of its attributes . In our example, the account has an attribute-balance. In the simplest case, it is reflected by the number - the number of rubles and kopecks in the account. The operation of withdrawing or crediting to an account changes the balance and attribute of the object “account No. 66579801 ″. The object “ATM on Tverskaya” has several attributes. The amount of money in an ATM can be characterized by a number. The state is “on” or “off” and the state “ready or not ready to accept the request” is a logical value.

It is worth noting that the attributes of an object in OOP can be not only the simplest values ​​(number, logical value, etc.), but also complex values ​​or other objects. For example, our bank will keep a history of all transactions for control purposes. A transaction is an object that has attributes (characteristics) of the transaction type, the amount of money transferred, the place of execution and the names of the counterparties of this operation. The object “account number 66579801 ″ will have a new attribute -“ transaction history ”, which will consist of a set of transaction objects.

Identification of objects in OOP

Sometimes you need to identify objects in OOP, that is, if there are two objects, how can you determine that these objects are different. For example, such a procedure is very important for identifying a bank account (object “account No. 66579801”) of a bank customer Ivanov.

In fact, there are two questions: are the two objects equal or are they identical?

Usually special attributes of objects are used for identification - identifiers. For example, for the object “account no. 66579801 ″, the identifier is its attribute“ account number ”, which is unique (the domain requirement is respected).

In turn, knowing the identifiers of objects, we can determine exactly whether they are identical or not.

Object Interface in OOP

The most important characteristic of an object in OOP is a description of how it can interact with the outside world. This description is called the object interface .

Objects in OOP interact with each other using messages. By accepting a message, the object performs the appropriate action. These actions are usually called methods .

In our example, the object “account number 66579801 ″ has the following methods -“ withdraw money from the account ”and“ put money into the account ”. These two methods make up the object's interface. The object “client Ivanov” has a method “Report your code”. And the object “ATM on Tverskaya” has methods “to start work”, “to accept money”, “to issue money”.

The object “account number 66579801 ″ has another attribute“ balance ”. Is it part of the object interface? The interface is an external description of the object. When developing the banking system and, in particular, the “account” object, we decide the question: is the balance the necessary information for other objects? Obviously, that is. Then we need to answer one more question: what exactly do other objects need? The balance of money in the account. In this case, you need to add another method “report the remaining money on the account” to the object “account”, and its interface will now consist of three methods.

Thus, the balance attribute is not directly part of the interface. Other objects can access this attribute only indirectly, using the “report account balance” method (thus they cannot directly change the value of this attribute).

Along with the methods and attributes included in the interface and accessible to other objects, an object may have attributes intended for internal use (only the object itself can access them). For example, an ATM has a very complex internal structure, i.e. He has a huge number of attributes. But for the banking system, they are not important, and neither the client nor the “account” object can access them. They are not included in the interface of the ATM object.

Object lifetime in OOP

In any system, objects are created, functioned and destroyed. In programming, there are two ways to destroy objects:

1. Objects must be destroyed explicitly using special calls.
2. Objects are destroyed when they are not needed by anyone (the system lacks all references to this object). Such destruction is sometimes called reachability destruction.

But at the same time there may be objects for which it is necessary to restore their previous state upon a new launch of the program. To work with such objects, the serialization method is used, when the values ​​of all attributes are written, and, if necessary, the restoration of the object is read. The scheme of this method is presented below.

Timing diagram of saving and restoring an object

There are, also, permanent objects that are not destroyed when the program ends and are not re-created when it is started (object-oriented database objects). The program and at the first and at the second start addresses the same object stored in constant memory.

Timing diagram of the creation of an object in the database

With the time of life and identification of objects, another concept is closely connected - the concept of objects of the first and second grade or equality of objects in the system.
An object is considered to be independent or first-class, in the event that it possesses all the signs of identification of objects adopted in a given object environment, and its lifetime is not related to the lifetime of the object that generated it.

Composition of objects in OOP

The object may consist of other objects. For example, an ATM contains a large number of nodes (attributes), that is, it includes other objects. At the same time, the ATM can directly include other objects or just refer to them.

Include objects and link to object