The original address

What are the characteristics of object orientation? This is definitely an entry-level interview question that comes up a lot. Why is it that a lot of coders who have been working for many years write code in object-oriented languages that is procedural? What is the essential difference between them?

[background]

Many junior engineers may learn what object orientation is, but it takes a lot of coding to get a feel for it.

Here we first from the whole software development process, to our understanding of object-oriented should be helpful.

By moving away from the low-level language of assembly and punching, programmers can spend a lot of time and energy on the real problems they need to solve. The characteristics of software programming in this period were basically to write a logic to do it when encountering any problems. Basically, you hand over to the machine what you need to do, follow the process, step one, step two… What’s the last step? Code it down. This pattern is process oriented. It is intuitive and conforms to our thinking mode when solving problems, so after skipping the low-level language at the beginning, it is natural to reach this stage, which is also the normal thinking mode of the Coder at the beginning of writing code.

Wouldn’t it be nice to just go on like this? The history of software development suggests the answer is: no. Although process-oriented programming is consistent with the way we think about solving problems, it brings huge problems as the problems we need to solve become more and more complex and large. Regardless of the level, regardless of whether the management is good, there will always be these problems, as you get bigger, the quality of the software gets worse and the schedule is not guaranteed. People will find that when a process is fixed as a function, if the process or the object being operated changes, many related operations in the system will change, which is actually one of the reasons for the above problems. This once became a huge obstacle to the development of software, and directly spawned the later software engineering, but even software engineering can not effectively solve this problem. During this period, the man-month Myth, which is regarded as the work of god by later generations, was born, which is to summarize the engineering experience of a super project based on this kind of process-oriented development.

Later, it was discovered that you could divide and conquer requirements or programming efforts, the idea of modularity. Although partition module has not entered the object-oriented level, but has played a role in the whole software development process. From the beginning of the problem of software development mode, people have been trying to sum up experience in the development process. How to make the code extensible, easy to maintain, reusable and so on to improve the efficiency and robustness of software development. Object orientation didn’t become popular until C++ came along, then the GOF gang of four came up with the design pattern in 1994, and then JAVA and C# pushed object orientation to its peak.

In fact, we see the above process, we know that the emergence of object-oriented, in fact, is to solve the problems in the process of software development. Especially how to improve the quality and efficiency of software development in projects with complex requirements, large scale and numerous personnel. It is based on people’s long-term experience summary, is the product of a practical process, in many solutions to stand out in a software programming method.

What is object oriented?

With that background in mind, let’s take a look at what object orientation is.

Object oriented is a programming idea, a programming method. It is a set of software development methods that have been tested in practice for a long time in the industry to solve all kinds of complex change problems encountered in the process of complex and large-scale software development. The so-called object is a model, which contains attributes and methods. To put it simply, an object is a model composed of a group of data and methods to process these data. In the process of object-oriented software development, we need to abstract everything into objects and design them into objects. This model is what we call object-oriented programming.

In this group of programmers, we often joke that they are for salary programming, for leadership programming, for resume programming…… Do you see that? Although this is a joke, but what this means, in fact, what is the core of the programming. So object-oriented programming, is to object this model as the core, to carry out our development work.

When the requirements of a complex system are thrown in, the first thing we do is to identify what objects are in it, what people, what objects, what components, etc., and list their properties. Then analyze what their respective functions are in the whole system, and define their methods to form a variety of objects. This is a typical object-oriented requirements analysis method.

How object Orientation works

What role does it play? In simple terms, it means simplifying complex things.

If we are faced with a complex requirement and use object orientation in the development process to simplify the whole requirement, then it has worked.

In the process of object-oriented development, people summed up a set of effective methods in practice, and these methods are abstracted into a theory, used to guide software developers how to make object-oriented development method as much as possible to play its advantages. In brief, it is the five principles: “single responsibility principle”, “open and closed principle”, “Richter substitution principle”, “dependence inversion principle”, “interface separation principle”, “Demeter principle (high cohesion and low coupling)”, and on this basis, dozens of design patterns have been developed. These contents are limited to space here not to expand, related content online information is also a lot of, you can search by yourself.

These principles as well as dozens of design pattern, let us in the face of complex and changeable demand, and the development of large scale of these problems, there are a set of effective measures for the entire software development complexity control within a certain range, and greatly strengthened the extensibility of software code, they are the developers are faced with various complex scenes, Make use of the idea of object orientation to simplify the best practices.

  

[Three characteristics]

This is an inescapable problem.

In the above mentioned basic principles of object orientation and the design patterns derived from it, we will find that process orientation does not have, and the design techniques used everywhere in these patterns, the most prominent are encapsulation, inheritance and polymorphism. So these three features are the core features of object orientation.

Encapsulation is when we abstract objective things into object models. After reading what object orientation is mentioned above, I think this is beyond doubt. Without this encapsulation, objects, the basic unit on which we depend, would not exist.

Inheritance is when we encapsulate a class of things that are obviously derivative but not identical, and we can think about inheriting them layer by layer. Some people express this derivation in terms of IS-A. If used properly, inheritance can reduce code duplication when we define such objects. Note, however, that if we force inheritance from things that are not closely related, it breaks the extensibility of the code, because inheritance itself is a way of coupling multiple objects together. So in practice, composition is superior to inheritance, and only objects that are really closely related and have such a derivative relationship are suitable for design with inheritance.

Polymorphism means a set of standards with multiple implementations. The emergence of standards has played a good role in isolating different categories of functionality, and polymorphism has made our software more extensible.

Understanding object Orientation

I have known the concept of object orientation since I started to contact the Java language. But after years of programming, I can’t say I’ve really learned the essence of object orientation.

From a complete lack of understanding of various concepts at the beginning, I now have some experience. In the actual development process, I gradually consciously use this set of methods to guide my development work. I think the real difficulty lies in that all the concepts are understandable, but there is no actual programming experience. These were things that I quickly forgot, even if I took them literally, before I faced the practical difficulties of constantly changing requirements, rushing to live, making a feature completely unusable by poor design, and so on. This set of programming methods is the experience summarized by predecessors based on practical problems. I think the most effective method is: Learn what object orientation means, see what these design patterns mean, forget about them, and then experiment with those inflexible, inconvenient designs as you go through the actual development process, and eventually meet again, and you’ll find that these patterns are really good medicine. If you don’t experience those bad experiences, you can’t appreciate their convenience. You have to do it to get something.

【 No silver bullet 】

At the end of the day, object orientation is a software programming approach that creates problems in the process of solving them.

If you’ve looked at Spring’s source code, you’ve probably been confused by the complexity of the concept, and when you look at the code layer by layer, you’ve probably forgotten what this module is really about. The design is elegant only if we really understand its intent and from the perspective of object-oriented design principles, but the code complexity that this design brings is also high. So, we can’t dogmatically think that object orientation is good, we have to take object orientation into account when we do any design.

In real development, if our goal is to simplify complex requirements, then we can consider using object-oriented; If you want to quickly implement a simple requirement, or if you’re looking for performance, or if you’re looking for a small, fixed module, use procedural orientation.

Always remember that object orientation is just a tool to facilitate problem solving, and don’t let your development process fall into the trap of over-designing for the sake of those principles. The design that works for our system is truly elegant.