In defense of OOP. 7 untenable arguments of his opponents

When I went through the Internet, so to speak, I noticed one interesting feature. All programming paradigms, discussed elsewhere, are perceived by people quite calmly. If, for example, they talk about procedural programming, then they talk about it absolutely calmly. The same goes for modular programming. Declarative programming - no storms, worries or holivar. Functional programming is the same.

And only around the PLO storms do not subside.Some scream from him in delight, others, on the contrary, Hyatt on what the light is based. And to be honest with me, it is completely incomprehensible why the whole world came together on the PLO.

You may have just thought that I am rather an adversary than a supporter of the PLO. This is absolutely not true (however, you can understand this from the title). Not. I am rather an opponent of "silver bullets", HYIP, the imposition of any methodology or a person on the throne and all manner of driving round dances. You do not dance around, say, a wrench or lawn mower. And do not write, I hope, publications, why a drill or a hammer sucks.
But today, the entire Internet is teeming with precisely pompous, hyperemotional, radical articles about the PLO - if one says that the PLO is “grave” and in general to all the guts of the gut, then the other necessarily announces that the PLO must be urgently thrown into the dustbin (if only he does not share the views of the first). There is no third.

I just want to introduce the third element. Calmly, without HYIP and swearing, tell why the PLO is not an elixir from all diseases, but also, like PP, AF or PL has the right to exist.

So, calm article in defense of the PLO. In it, I will try to consider the main arguments of opponents of the PLO and justify their inconsistency.

1. Everything that is in OOP has been in other paradigms for a long time.


Almost all programming languages ​​are turing-complete, with the exception of markup languages, such as: HTML, XML, CSS, etc. If you speak peasant language, turing-complete language is a language in which you can write absolutely any conceivable program. A rather general thesis follows from this: what exists in any chosen language at random is in all other languages. The same can be said about paradigms. All the differences between languages ​​(and paradigms) are different ways of implementing certain commands, not counting individual lexical features.

By the way, the same thesis (everything that is in N is in M, and in K, and in R, etc.) can be formulated as follows: the hammer already consists of iron and wood, why do we also need pliers? But after all, no one would argue.

2. OOP mixes data and actions on them. This is bad


The argument is sucked from the finger. First, where does OOP mix data and functions? Secondly, the statement that this is bad is also taken from the lantern, from the barrel “a real man does not do that,” and why - yes, because gladiolus. OOP in some way simulates the real world, where the data is inherent in the object - no one will argue that the chair has no color, and it does not have four legs. And there is no confusion of data and operations here, the object is not a function and not an operator. This is an abstraction.

3. Inheritance enslaves the program, makes it difficult to make changes.


Here you can slow down a bit. Inheritance does not imply the alignment of kilometer-long trees in order to slow down development. Inheritance is invented in order to allocate common properties and methods to the superclass, and this should be done with classes representing objects of the same type. An error will create, for example, two classes, one of which is the heir of the other, because there is no selection of a common code in the superclass simply because there is nothing in common .

If you do not intend to extend the parent class to the third class - such inheritance is simply meaningless. If you are creating a liquor store, then you can inherit the Beer, Vodka and Vine classes from the Alcohol class, but you don’t need to create the Drinks class either, unless you want to sell more and, say, Paraguayan tea.

It is also an error to create hierarchies in which classes do not relate to each other. Well, why, tell me, to fence the tower, where the classes Fly and Cutlet are inherited from the superclass Cheese, which, in turn, is inherited from the superclass Friday ?! But this is no longer a shortage of OOP, but the curved arms of the one who writes this.

4. Encapsulation does not make sense


Here I partially agree. From the point of view of the program, encapsulation really does not affect anything. If I close the variable with private - well, so what, I can still open it, simply by removing private, and then changing everything my heart pleases.

But this is only technically true. The philosophy of the PLO is that a properly organized and encapsulated class can be viewed as a black box. Imagine a box with different buttons on one side, data slots, and an output slot on the other side that returns information. Take, for example, the stack. Imagine a box, on one side of which there is one slot for inserting data and a push button next to it. On the back side is the pop button. You submit there a note with the number 8 and push the push button. Then submit another piece of paper and push push a second time. And so N times, and then press pop. From the box flies a piece of paper with the number 76 (or another, in general, the one that you filed). Need another number? The second time push pop. And so to carrotas long as the box is empty. And if you continue to push pop, the mechanism from the drawer howls: the stack is empty! That is exactly what the object looks like.

But after you have created and set up a class, you are already in the violet, how it works there - it just works correctly, and there is no need to wish for more. And encapsulating all these structures, you do not keep everything in memory. They (many boxes) just communicate with each other in the way you configure.

Encapsulation is a kind of crutch supporting one hundred pillars of your program while you are constructing the hundred and first. In large projects (namely, to create them and invented the PLO) without this, alas, no way.

Although it is unlikely that “alas” is generally appropriate here.

5. In the real world, there are no relationship hierarchies, only inclusion hierarchies everywhere.


Do you think so? But after all, no one bothers to create, for example, a hierarchy, where all the rivers of the world (Congo, Seine, Thames, Amazon, Kolyma, etc.) are objects of one comprehensive “River”, which has properties (for example, water) and actions (for example, flows), and already it will be inherited from the “Waters”, which also consists of water, and from the “Waters” you can also inherit the “Lake”, the objects of which will be separate lakes (Baikal, the Caspian Sea, Titicaca and .d.) The layout is pretty rough. But relationship hierarchies are also an abstraction.. Something a la Platonic idea, if you want. In the real world, they are not there, they exist only in the mind, this is a generalization, and nothing more. But this is precisely how a person very often thinks. After all, we can say “sock”, without specifying what its color is, what material it is woven from, etc., but does this “sock” really exist?

And yet we should not be embarrassed that there is no “object” or “sock”.

6. The methodology of OOP is initially erroneous.


Absolutely unfounded argument. The PLO was created in order to model a kind of virtual world consisting of objects, like our world. For example: a person is an object from the real world. He can walk, run, eat, shit to sleep, play football, watch football, but, unfortunately, I cannot list everything here, and to be honest, it would be disgusting to list everything. This same person has the properties: presence / absence of hair, hair color, if they exist, eye color, if they existskin color, number of fingers, etc. If we correctly construct all the fields and methods, as I wrote above, then the program object will be able to simulate certain properties of the real object. A person thinks very well in such categories - that is why OOP has become widespread. It helps a lot when writing large projects, as it introduces modularity and allows you to break a software package into separate components that interact with each other.

7. But even millions of flies will not convince us that dung is tasty.


The most popular argument against OOP. Like, the masses are for the most part stupid (I still don’t think this applies to programmers), they run around on “fashionable clothes” and admire them.
But think about it, what if the PL didn’t ascend the pedestal, but let's say, the LP? Do you think it would be different? Nothing like this! There would be fans and malicious opponents, and the PLO would be viewed as a tool (I, in fact, I call for this), and not as a pill created by God himself and therefore irreplaceable.



Why is this article in defense of OOP?


All modern talk about programming paradigms, as I see it, boils down to two diametrical assumptions: leave the OOP and throw out the rest, or throw out the OOP and ... well, you understand me.

I don’t want a perfectly fit paradigm to be considered a decent dump, but I don’t want dances around it, and forget everything else. I think that the second is easier to make, but this article is directed against the first.

If you don't like OOP


To whom - OOP, to whom - OP, to whom - PP. And to someone, perhaps, in general, the most pork cartilage is really cute. If you don’t like cats, you probably don’t know how to cook them.

Also popular now: