Object oriented and Process oriented Differences between of Power Nodes java College Collation

Procedural orientation is the ability to define functions or methods in a program. In case you're wondering, isn't there a language that can't define functional methods? Earlier basic did not, and only used jumps to implement function calls.

Object orientation goes one step further, allowing you to encapsulate "procedures" (functions, methods) and their context-specific data into objects, while objects allow developers to restrict access to and modify parts of them through inheritance and derivation and type qualifiers.

I don't want to make the connection between object orientation and things in life, although they are somewhat paradoxical, but it makes no sense to you to understand the nature of programming, even misleading you. The essence of object orientation is not to simulate real-world objects, but to develop strong, simple, and maintainable code.

The bad thing about making object-oriented language easy to understand is that it looks easy to understand when what you actually know is completely wrong, and it can lead beginners completely astray.

The core 1 is encapsulation, which does not allow you to access private functions and members. As many people understand, there is actually a layer of code that does not allow developers to modify the code at will, because arbitrary changes in code and arbitrary changes in the value of variables 1 are a source of disaster.

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

So what do you do? So you say, this is not easy, I'm going to make a copy of this function, I'm going to copy it, I'm not going to change it, I'm not going to change it. So here's the problem again. If the writer of the original function finds an bug, he fixes it, but the copy of bug you copied won't fix it unless you know how many copies it was copied, 11.

How does object orientation solve this problem? A developer implements a function by writing a class in which methods are defined as virtual methods. When you need to modify the method to fit a new requirement, instead of directly modifying the source code of the class, you derive a class to override the virtual methods that allow you to customize, so that you can customize the original program in a controlled way. But because the base class type is called elsewhere, and you haven't changed the base class code, it doesn't cause problems with the original code. Moreover, if the original author of the base class finds that a non-virtual method has bug, he will simply modify it. Because your class inherits this code, rather than copying and pasting it, one change changes everything.