Today I’m going to talk about some of the trickier issues in object-oriented programming.
In the 1960s, programming had a big problem: computers weren’t that powerful and needed to somehow balance the power of data structures and programs.
This means that if you have a lot of data, you can’t make the most of it without pushing the computer to its limits. In addition, if you need to do a lot of things, then you can’t use too much data, otherwise the computer will run forever.
Then, in 1966 and 1967, Alan Kay theorized that packaged microcomputers could be used. These microcomputers do not share data, but communicate via messaging. This allows computing resources to be used more economically.
Clever as the idea was, object-oriented programming didn’t become mainstream until 1981. Since then, it hasn’t stopped attracting new and experienced software developers. The object-oriented programmer market is as busy as ever.
But in recent years, this decades-old programming paradigm has come under increasing criticism. Could it be that after 40 years of object-oriented programming, technology has moved beyond this paradigm?
Function and data coupling
The main idea of object-oriented programming is simple: Try to break up a powerful program into equally powerful parts. This allows you to couple some data with functions that are only used on related data.
Note that this covers only the concept of encapsulation. That is, data and functions inside an object are not visible to the outside. We can only interact with the contents of an object through messages, usually through getter and setter functions.
Inheritance and polymorphism were not included in the original design idea, but are now required for object-oriented programming. Inheritance basically means that a developer can define a subclass that has all the attributes of its parent class. Inheritance wasn’t introduced until 1976, a decade after the concept of object-oriented programming was introduced.
It took another decade for polymorphism to make its way into object-oriented programming. In simple terms, this means that a method or object can be used as a template for another method or object. In a sense, polymorphism is a generalization of inheritance, because not all attributes of the original method or object need to be transferred to the new entity. Instead, you can choose to override some properties.
What makes polymorphism special is that even though two entities depend on each other in the source code, the called entity works more like a plug-in. This makes the developer’s life easier because they don’t have to worry about runtime dependencies.
It is worth noting that inheritance and polymorphism are not unique to object-oriented programming. The real difference is in the way the data is encapsulated and contained. It was a genius idea at a time when computing resources were much scarcer than they are today.
Five big problems in object-oriented programming
When object-oriented programming came along, it changed the way developers looked at code. Until the 1980s, procedural programming was very machine-oriented. Developers need to know a lot about how computers work to write good code.
By encapsulating data and other methods, object-oriented programming makes software development more human-centered and intuitive. For example, the method Drive () belongs to the CAR data group, not the Teddybear group. The inheritance that comes later is also intuitive. For example, it makes sense that Hyundai is a subclass of cars and has the same attributes, but PooTheBear is not.
Three, banana monkey jungle problem
Imagine that you are setting up a new program and are considering designing a new class. Then you think back to the neat little class you created for another project and see that it fits the work in progress.
No problem, you can reuse classes from previous projects in new projects.
There’s a problem: this class may be a subclass of another class, so you need to include its parent class as well. Then you realize that the parent class might be a subclass of another class, and so on, and you end up with a bunch of code.
Erlang founder Joe Armstrong famously said, “The problem with object-oriented languages is that they come with all the implicit environment around them. You want bananas, but you get gorillas with bananas and a whole jungle.”
That pretty much says it all. It’s okay to reuse classes, and in fact this can be a major advantage of object-oriented programming, but don’t take it to the extreme. Sometimes you should create a new class instead of adding lots of dependencies.
Fourth, fragile base class problems
Imagine if you had successfully reused a class from another project for new code, what would happen if the base class changed?
This can break the code for your entire new project, even though you may not have done anything. Once someone changes a detail in a base class that is critical to your project, the impact can be large and sudden.
The more you use inheritance, the more potential maintenance work you have. So even though reusing code is great in the short term, it can cost you in the long run.
Fifth, rhombus inheritance problem
Inheritance allows you to pass attributes in one class to other classes. But what if you want to mix two different classes of attributes?
Yes, it can’t be done, at least not by conventional means. Take the Copier class, which scans the contents of a file and prints them on a white paper. Should it be a subclass of Scanner or Printer?
There is no perfect answer to this question. Even if this problem doesn’t break your code, it comes up often and can be frustrating.
6. Hierarchy
In the diamond inheritance problem, which class Copier is a subclass is the key issue. But there might be an opportunistic solution: assume that Copier is the parent and Scanner and Printer are subclasses that inherit only a subset of attributes, and the problem is solved.
But what if your Copier is black and white and Printer can handle color? In this sense, Printer is not a generalization of Copier? What if Printer connects to WiFi but Copier doesn’t?
The more attributes pile up on a class, the more difficult it is to establish an appropriate hierarchy. In the cluster of attributes you are dealing with, Copier shares some, but not all, of Printer’s attributes and vice versa. In large, complex projects, problems with hierarchy can cause a lot of confusion.
7. Quotation problem
You might think of object-oriented programming with no hierarchy. We can use property clustering and inherit, extend, or override properties as needed. Perhaps this is a bit confusing, but it would be an accurate representation of the problem at hand.
There’s just one problem: The whole point of encapsulation is to keep pieces of data safe from each other to make computations more efficient, but it doesn’t work without a strict hierarchy.
What happens if one object A overwrites the hierarchy by interacting with another object B? What happens with the other relationships is not important, but when B is not A direct parent of A, A must contain all of B’s private references, or they will not interact.
However, if A contains information that subclasses of B also have, then that information can be modified in multiple places. Therefore, information about B is no longer secure, and encapsulation has been broken.
Although many object-oriented programmers use this architecture to build programs, it’s not object-oriented programming, it’s just a mess.
The risks of a single paradigm
What these five problems have in common is that they all have inappropriate inheritance. Since inheritance was not included in the original form of object-oriented programming, these problems may not be called object-oriented problems per se.
But object-oriented programming is not the only thing that can be overstated. In purely functional programming, it is extremely difficult to process user input or output messages on the screen. Object-oriented or procedural programming is much better for this.
But there are still developers who try to implement these things as pure functions and write dozens of lines of code that no one can understand. Using another paradigm, you can easily reduce your code to a few lines of readable code.
There’s no doubt that functional programming is getting more attention, whereas object-oriented programming has been getting a bit of a bad rap in recent years. It makes sense to learn about new programming paradigms and use them when appropriate. Regardless of the programming paradigm, there is no need to follow just one, and using different paradigms when appropriate can better solve problems.
Is object-oriented programming really going to be replaced?
Faced with an increasing number of problems, functional programming may be a more efficient option. The more you invest in data analysis, machine learning, parallel programming, the more you’ll like functional programming.
But object-oriented programmers are still in far greater demand than functional programmers. But that doesn’t mean you can’t be the latter, functional programmers are still in short supply.
Most likely, object-oriented programming will be around for a decade or so. Of course, it’s good to go a little edgy, but that doesn’t mean you should give up object-oriented programming. So for the next few years, don’t abandon it entirely, but at least make sure it’s not the only way you know how to program.
Write to the end
I believe you have a preliminary understanding of some of the problems facing the object. Point attention, don’t get lost, pay attention to programmer Zeng Zeng, share different Java knowledge every day. For more Java basics, I put together a GitHub repository of my own:Java little White training manual, you can check it yourself if you need to