Thoughts on OOP

Another article about “the basics of programming in C ++” pushed me to the idea that many programmers do not understand the essence of object-oriented programming (OOP).



In particular, this article states that
"++ , ++ . "

Quite a long time ago, at one of the forums, I came across the arguments of another programmer who wanted to program the storage system of “universal” objects and talked about “whether the chair is an object”.
')
Both of these people are somehow mistaken about the PLO.

Objects in OOP, as a rule, have nothing to do with objects in the real world. Moreover, even if we put together a set of certain characteristics of anything in one place (in the record), it would still not be an object in the understanding of the OOP.

Confusion often arises also because of the haggard word “object”. Yes, and the concept of "class" and "object" is often mixed.

So, a simple rule that makes it easy to understand where OOP is and where it is not.

Headlights and belt

BEHAVIOR AND CONDITION

More expanded, the class of objects (in the understanding of OOP) is used if ...

... some entity has a behavior that depends on the internal state of this entity.

What does “essence have a state”? Let's see.

An entity instance has its own data set — this is obvious. What is the difference from the usual record (structure)?

First of all, the state implies that part of the data is essentially used “for oneself”, for the realization of one’s own behavior. If the entity has nothing to hide, then it degenerates into an ordinary data record. Moreover, the concept of "state" is more stringent than just an "additional set of data." It implies some connectedness, interdependence of this internal data. The condition may be correct and incorrect. And who can understand this? An external observer? No, only the essence itself. Thus, the state is hidden for a reason; it is protected from damage by an incompetent user of the entity.

Now it is clear what the “behavior” of the entity is. This is when the entity implements some kind of functional, while maintaining the correctness of the state.

Let's take some simple example. There is a product: name, price per unit, balance in stock. Is it an OOP object?

Think before you read further.

If you do not impose any restrictions on its characteristics - no. State does not occur.
We can enter any values. Nothing to hide.

Let's introduce restrictions - the balance can not be negative, and the price should be positive.

And now?

Can an external user now arbitrarily change the data in the product? Obviously not. Our product has a behavior - reducing the balance means “pick up the goods in a certain amount” and pick up more than the balance - it’s impossible.

Notice what happened? We have introduced restrictions, that is, we have made some sense in the nature of the properties of the entity. And immediately a sensible behavior appeared - “to bring in goods”, “to take goods”.

Another example. Suppose the program requires dynamic loading of modules. There is a state - a set of already loaded modules. And the behavior is easily visible - “load module”, “unload module”. Why this example? To the fact that there is no connection with objects in the real world here and there.

To associate the nature of classes in OOP with the nature of objects in the real world is a rather absurd and meaningless undertaking. The nature of the entity will be determined not by the real world, but by the system and will depend on the environment of the entity, on its use, on the interrelation of the components.

That's all. You can call it encapsulation. And you can not call. You can talk for a long time on the topic of inheritance. And you can simply understand that “inheritance” is a way to extend the behavior of an object.

The main thing is to understand that OOP is necessary for a programmer to control the complexity of development. And not to "reflect the objects of the real world."

UPD

Okay, let's continue to throw in clever words.

Abstraction and polymorphism are not directly related to the PLO. Surprisingly.

Any procedure or function is an abstraction. Any. Here is the announcement:

void sort (int * array, int size);

This feature is an abstraction. It implements sorting. Abstractly. We do not know how.
But the output will be a sorted array. There is an abstraction, but where is the PLO? There is no OOP. No objects, no classes.

Now I declared the sort pointer. And I can assign him the following function:

void quick_sort (int * array, int size)

or this:

void bubble_sort (int * array, int size).

There is a polymorphism. The function pointer remains the same. But now there are different algorithms behind the same function pointer.

And where is the PLO? OOP no. Because it is not even C ++, it is C. In which there are no classes. And abstraction and polymorphism are achieved.

Yep

UPD2

: - ;)

C, , this , , , this. ?

python, , ( ) - ?


That's it. I just about it :-) I anywhere anywhere in general did not write a line that the C ++ is necessarily OOP. And everything else - supposedly not.

OOP is not a language feature. NOT! This is an application architecture, a method of domain modeling. Under which the division into entities according to the principle described in the article.

The capabilities of the language may facilitate the application of OOP principles, may not interfere, but may complicate the application of these principles. But the principles do not change.

I can do a bad class in C ++. Which violates the principle of a consistent change of state.

And I can on C or on the Python implement the "correct" OOP. Or even in assembler. I will select entities and not let them change their state from the outside.

The main idea of ​​my article is not about compiler features.

And about the situation when a programmer using OOP thinks about “a class (of objects) is needed here or not needed.”

If there is a state with behavior, it is needed; otherwise, it is not needed.

How he will implement it in his programming tool is not important to me.