Evolution of understanding the PLO
Almost all programmers believe they know OOP. I thought so too. Looking around a bit, I realized that the evolution of my understanding of the PLO was considerable. It all started with a simple, that there are classes, they have methods. And if one class represents some notion of the real world, then here it is - the PLO. In fact, this is not an article, but merely thoughts, an idea of how my understanding of the PLO and the attitude towards it has changed. By the way, I am not sure that in a couple of months it will not again undergo some changes.
For me, life in the PLO began with a very simple phrase that is relevant now. All that the noun is our objects. All verbs are actions, and adjectives are characteristics. It's funny that I heard this phrase only in the third year of university. It turns out that the basics of the PLO are held in Russian language lessons at school. Alas, only now I understand how I underestimated these lessons.
The main advantage of OOP, in my opinion, is the fact that we use it both in programming and in ordinary speech. We can just continue to live our lives, discuss different concepts, argue about who should do what. This happens every day several times. Just try to transfer all such discussions to the workspace, to the programming area. We discuss the contracts of our company with customers - so here it is, the object of contracts. We are discussing the possibility of publishing contracts on our website - and here it is the behavior that the contract can be published.
')
Such a simple use of language and words in sentences when defining a model allows us not to distort the language when communicating with customers. If he tells me that the contract should be able to pay some bonus to people who worked on his conclusion, I can easily do it using a simple method in the class of the contract. Later, for me this method will be a signal that the contract money is paid, and I will not forget about it, I know exactly where this functionality is.
If we draw a certain analogy, then for me it is akin to cross-platform development environments. For example, the same .NET. No matter what language I write in - C #, VB or some other, I know that my code will compile into intermediate. So, imagine that I, as a programmer, use C #, and my customer says his requirements on VB. In such a situation, the PLO serves as the very converter that helps the customer and me to meet, to be on the same wavelength (they like the phrase - to be on the same page). And here opens a key feature that was not noticeable before. OOP is a tool. My model, which I implement in my code, is a tool. It will not necessarily be fully preserved if they say I created an object, played with it, changing its internal state, received some kind of exhaust from it and now I can safely throw it in the trash. It is like a screwdriver that helps in work, like Excel plates, which I open, produce calculations and close without saving. This is a tool for working with data, and not a holistic, persistent model. Very often, in the development teams, people are involved in databases and people working directly on code, model, and user interface. I am not at all pleading for the fact that these teams should be divided, on the contrary, I welcome the joint work. So, if you do not attach to the data, then the refactoring of your model looks like an improvement of our tool for working with this data set. It is the same as releasing a new improved drill or a new drill to drill thicker walls.
There is a myth that OOP programmers first write classes. Most likely this confusion came from the fact that in object-oriented languages all operations and functions are performed in some objects, which means that in order to describe any behavior, it is necessary to create a class. Everything seems to be the same, but the understanding of what it means to write a class is different for everyone, starting with creating an empty class and ending with a description of its state and behavior. In most cases, the working chain looks like this - we understand that we need some kind of system behavior and we describe the interface, announcing a contract for this behavior. Then we estimate at what point in time it needs to be completed, and choose the ideal performer from the existing objects, or create a new one. You will never write a class, and then think about what to do with it. That is, the chain always starts from behavior. Mechanically, we often create a new class and only then declare a method in it. It turns out that this myth came to us from a mechanical understanding of things in the PLO. Sometimes, we think very quickly and only having realized what kind of system behavior is needed, we are already deciding what kind of object it will perform. This also gives the impression that we are dancing from an object, but no, because thoughts always begin with behavior. Plus, the customer helps us with this. He always needs the system to do something, and not just have a concept of some kind, such as a contract or order.
Without refraining from comparing the procedural and object-oriented approach, I asked myself a simple question - where could I use the procedural approach instead of the objective one? To be honest, I do not know such areas in which the OOP is clearly losing the functional approach in one way or another. One thing that goes on in the language, nevertheless, is - there are some calculations, complex calculations, algorithms. Let's take an example when we need to calculate the value according to some complicated rules. I do not know how a person who preaches a procedural style would act, but I can understand the thoughts of an objectman. Point one first, I would break this calculation into semantic stages, for example, counting this coefficient, then this and then the final one. Each calculation step is an object that will participate in the whole process. To communicate between steps, in order to give them the opportunity to exchange data, we will create another auxiliary object that will hold all intermediate calculations. Then we combine these objects into a single chain, we will describe a single method that will return the required value and that's it. This code will be convenient to test, it is comfortable to read, it is not difficult to understand, but there is one But. You need to have a slight shift in your understanding that the object is not necessarily some kind of noun from the real world; it can also be an action. But this is becoming more complicated and clearly not in favor of the PLO. Determining the edge where objects of the real world or some concepts are used as objects, and where objects can be actions is very difficult. Yes, and you need to make some effort to understand how the method will look at such an object. It turns out that the behavior of some action, and this is already beyond the bounds of the Russian language. From this my understanding of things, I conclude that OOP is really not the best choice for this task, but only because it may not always be simple and transparent in understanding.
OOP first of all tool
For me, life in the PLO began with a very simple phrase that is relevant now. All that the noun is our objects. All verbs are actions, and adjectives are characteristics. It's funny that I heard this phrase only in the third year of university. It turns out that the basics of the PLO are held in Russian language lessons at school. Alas, only now I understand how I underestimated these lessons.
The main advantage of OOP, in my opinion, is the fact that we use it both in programming and in ordinary speech. We can just continue to live our lives, discuss different concepts, argue about who should do what. This happens every day several times. Just try to transfer all such discussions to the workspace, to the programming area. We discuss the contracts of our company with customers - so here it is, the object of contracts. We are discussing the possibility of publishing contracts on our website - and here it is the behavior that the contract can be published.
')
Such a simple use of language and words in sentences when defining a model allows us not to distort the language when communicating with customers. If he tells me that the contract should be able to pay some bonus to people who worked on his conclusion, I can easily do it using a simple method in the class of the contract. Later, for me this method will be a signal that the contract money is paid, and I will not forget about it, I know exactly where this functionality is.
If we draw a certain analogy, then for me it is akin to cross-platform development environments. For example, the same .NET. No matter what language I write in - C #, VB or some other, I know that my code will compile into intermediate. So, imagine that I, as a programmer, use C #, and my customer says his requirements on VB. In such a situation, the PLO serves as the very converter that helps the customer and me to meet, to be on the same wavelength (they like the phrase - to be on the same page). And here opens a key feature that was not noticeable before. OOP is a tool. My model, which I implement in my code, is a tool. It will not necessarily be fully preserved if they say I created an object, played with it, changing its internal state, received some kind of exhaust from it and now I can safely throw it in the trash. It is like a screwdriver that helps in work, like Excel plates, which I open, produce calculations and close without saving. This is a tool for working with data, and not a holistic, persistent model. Very often, in the development teams, people are involved in databases and people working directly on code, model, and user interface. I am not at all pleading for the fact that these teams should be divided, on the contrary, I welcome the joint work. So, if you do not attach to the data, then the refactoring of your model looks like an improvement of our tool for working with this data set. It is the same as releasing a new improved drill or a new drill to drill thicker walls.
Action is more important than the one who committed it.
There is a myth that OOP programmers first write classes. Most likely this confusion came from the fact that in object-oriented languages all operations and functions are performed in some objects, which means that in order to describe any behavior, it is necessary to create a class. Everything seems to be the same, but the understanding of what it means to write a class is different for everyone, starting with creating an empty class and ending with a description of its state and behavior. In most cases, the working chain looks like this - we understand that we need some kind of system behavior and we describe the interface, announcing a contract for this behavior. Then we estimate at what point in time it needs to be completed, and choose the ideal performer from the existing objects, or create a new one. You will never write a class, and then think about what to do with it. That is, the chain always starts from behavior. Mechanically, we often create a new class and only then declare a method in it. It turns out that this myth came to us from a mechanical understanding of things in the PLO. Sometimes, we think very quickly and only having realized what kind of system behavior is needed, we are already deciding what kind of object it will perform. This also gives the impression that we are dancing from an object, but no, because thoughts always begin with behavior. Plus, the customer helps us with this. He always needs the system to do something, and not just have a concept of some kind, such as a contract or order.
The task of calculating thoughts of the object
Without refraining from comparing the procedural and object-oriented approach, I asked myself a simple question - where could I use the procedural approach instead of the objective one? To be honest, I do not know such areas in which the OOP is clearly losing the functional approach in one way or another. One thing that goes on in the language, nevertheless, is - there are some calculations, complex calculations, algorithms. Let's take an example when we need to calculate the value according to some complicated rules. I do not know how a person who preaches a procedural style would act, but I can understand the thoughts of an objectman. Point one first, I would break this calculation into semantic stages, for example, counting this coefficient, then this and then the final one. Each calculation step is an object that will participate in the whole process. To communicate between steps, in order to give them the opportunity to exchange data, we will create another auxiliary object that will hold all intermediate calculations. Then we combine these objects into a single chain, we will describe a single method that will return the required value and that's it. This code will be convenient to test, it is comfortable to read, it is not difficult to understand, but there is one But. You need to have a slight shift in your understanding that the object is not necessarily some kind of noun from the real world; it can also be an action. But this is becoming more complicated and clearly not in favor of the PLO. Determining the edge where objects of the real world or some concepts are used as objects, and where objects can be actions is very difficult. Yes, and you need to make some effort to understand how the method will look at such an object. It turns out that the behavior of some action, and this is already beyond the bounds of the Russian language. From this my understanding of things, I conclude that OOP is really not the best choice for this task, but only because it may not always be simple and transparent in understanding.
Source: https://habr.com/ru/post/129247/
All Articles