OOP myths and reality

    ( Source )

    I want to contribute my “5 kopecks” to the unceasing dispute between opponents and supporters of the PLO. From recent publications on this subject, one can note a brightly negative headline “The faster you forget OOP, the better for you and your programs” , the more peace-loving “Stop arguing about functional programming and OOP” and the moderately positive “Object-oriented programming in graphic languages” .

    But the idea of ​​this article prompted me to comment on another article:
    A great example for OOP is just awful. The trait system perfectly implements your case, and does not require at all to answer the Existential Question of Object Programming - “What is an Object?”. [...] Forget about the OOP, it was a successful metaphor for the GUI, which they tried to raise to the status of religion.

    In my opinion, this is a very revealing typical commentary, where the OO approach is not criticized (even OOP in the GUI is given due), but the myths that arose around OOP. Thus, in my opinion, everyone is right: both supporters when they point out the convenience of OOP, for example, when programming GUI, and opponents when they are indignant at raising OOP in the status of a silver bullet, an absolute weapon.

    It should be noted right away that in every OO PL there is a different OO approach, sometimes very, sometimes not very different from other OO approaches. I will proceed from the moderate simple approach of OO Pascal, which was already laid down in Turbo Pascal 5.5 and finally took shape for Delphi 7 (we can note the conceptual languages ​​of other manufacturers, for example, Think Pascal for MacOS). There are fundamental principles in this OO approach: encapsulation, inheritance (simple), polymorphism; and significant limitations: for example, there is essentially no very complicated multiple inheritance .

    As I already wrote in the commentary to the article mentioned above, the transition from classical Pascal to OO Pascal looked, in my opinion, very clear and justified:

    The simplest encapsulation is already in the records. Further, the concept of inheritance comes in such simple examples:

    TCoord = record// координаты точки
                        x, y : integer
    TRect = record// прямоугольник
                         leftTop, RBot : TCoord;

    It remains to replace the word “record” with the word “class” (indicating the name of the ancestor in brackets), allow writing the method headers inside such “records” and stipulating simple rules of polymorphism.

    The given example is the implementation of graphic primitives, this is already a broader task than GUI tasks. Here the hierarchy of objects looks obvious and the "Existential Question" What is an Object? "Noted above does not arise. - It is clear that a point is an object and a rectangle is another object. But in the general case, it is far from always possible to clearly distinguish objects and arrange them in the only correct hierarchy. OOP opponents are right here, but the fact is that this is not necessary! The OO approach is often called the model approach (one of). The main principle of the model approach is the modeling of not all the properties of the prototype, but only some, significant properties for the purposes of this model. A textbook example is testing a model of an airplane in a wind tunnel. Obviously, for such tests it is not necessary to make engines, portholes, chassis, cleaned when flying into the hull and seats in the cabin, as well as the cabin itself - it is enough to plan this model from a single piece of wood, reproducing only the alleged contours of the hull. Such tests are carried out not only for real models in a real tube, but also for virtual models in a virtual tube. If you implement a virtual test using OOP, then the principles will be similar to real tests - unnecessary properties and objects will not get into the program. But if we want to reuse the code of this model for modeling the design of the aircraft, we may run into hierarchical problems when adding new objects. Is this a disadvantage of OOP? - In my opinion, no: any modeling is subject to strict restrictions. Moreover, for modeling, there are a number of other complex fundamental problems. For more details see:

    Blekhman I.I., Myshkis A.D., Panovko Ya.G. Mechanics and applied mathematics. Logic and features of mathematics applications.
    Myshkis A. D., Elements of the theory of mathematical models. Ed. 3rd corrected. M .: KomKniga, 2007

    The above books mention many sources on the topic of modeling, including the following example. If you put 3 stools on top of each other, then this design will be quite stable to put a paper cube on it for the school drawing lesson. But this same design is clearly unstable, to use it to change a burned out bulb. No mathematics can draw such conclusions. Thus, there is not a purely mathematical problem of interpreting simulation results. This problem will arise in any implementation of the model: both with and without OOP. But people are prone to cognitive distortion, and often blame the mirror tool for displaying unpleasant information to them;)

    At the end of the last century, world famous people Bill Gates ,Philip Kahn , Björn Straustrup , Nicklaus Wirth and others, not wanting to, planted a bomb under the PLO, propagating it too enthusiastically. Almost everyone believed them, and only now there was sobering. But this process of sobering is dangerous at the other extreme - attempts to completely abandon proven technology in many areas of technology. Only by attempt - this is hardly possible, if only because:

    First of all, forgetting OOP is [...] not realistic, because so many IDEs have graphical tools for creating a GUI, and these tools generate OO code.

    In my opinion, as in the case of any model, one should not expect from a model using OOP that it will miraculously reveal all the secrets of the universe. Each model is adequate only in its narrow framework: "what is laid is what we get." At the same time, according to the requirement of a natural-scientific approach, each result obtained on the model should be double-checked experimentally. But with such natural limitations, not all bonuses are well-known: a primitive-formal approach is often possible for modeling. So, in the case of OOP, you do not need to try to delve deeper than possible when defining objects and their hierarchy. ( Similarly, for example, in chemistry: modern chemists know that an atom is not a ball, and a chemical bond is not a fixed-length rod, but this does not prevent them from using ball-rod models and structural formulas.) - A hierarchy is needed to restore order in the model code, but it will never answer exactly a much more complex prototype than any model.

    Also popular now: