The difference between object-oriented and process oriented (power node)

Procedure oriented means that functions or methods are allowed to be defined in a program. You may wonder, is there a language that can't define function methods? The early basic can't, but can only use jump to realize function call.

Object oriented is a step closer. It allows you to encapsulate "procedures" (functions and methods) and their context sensitive data into objects. At the same time, objects allow developers to restrict access and modification of some of them through inheritance and derivation and type qualifiers.

I don't want to associate object-oriented with things in life. Although they have some specious connections, it makes no sense for you to understand the essence of programming and even mislead you. The essence of object-oriented is not to simulate real-world objects, but to develop strong, simple and maintainable code.

The disadvantage of making object-oriented easy to understand is that it looks easy to understand. In fact, what you know is the wrong thing, and it makes novices go completely astray.

The core of the three characteristics of object-oriented (encapsulation, inheritance and polymorphism) is encapsulation, which does not allow you to access private functions and members. I believe many people understand that there is another layer, which is that developers are not allowed to modify the code at will, because modifying the code at will is the same source of disaster as modifying the value of variables at will.

In the oriented process, if you find that the program is inappropriate and you need to add functions, what will you do? You will directly modify the code of a function, but if the function is not written by you and you don't fully understand it, there may be problems. Another problem is that you don't know how the existing code calls this function. In other words, if you modify it, you are satisfied here. What about the calls elsewhere? Is there a problem?

So what? You think, it's not easy. I copy this function and modify it without changing the original function. So the problem comes again. If the writer of the original function finds a bug and fixes it, but the bug you copied will not be fixed by yourself, unless you know how many copies of the code have been copied and modified one by one.

How does object-oriented solve this problem? Developers implement a function by writing a class. Some methods in this class are defined as virtual methods. When you need to modify this method to meet new requirements, you do not directly modify the source code of this class, but derive a class to override these virtual methods that allow you to customize, so that you can customize the original program within a controllable range. However, because the type of the base class is called elsewhere, and you have not modified the code of the base class, it will not cause problems with the original code. Moreover, if the original author of the base class finds a bug in a non virtual method, he can modify it directly. Because your class inherits these codes instead of copying and pasting them, you can change them all once you modify them.