What is a paradigm

In the beginning, the paradigm can be thought of as a particularly intelligent, adaptive technique that solves specific types of problems. In other words, it's similar to someone who needs to know a whole lot about a problem. After understanding the various aspects of the problem, finally put forward a set of the most common, most flexible solution. The specific problems may have been seen and resolved before. However, the previous scheme may not be the most perfect, and you will see how it is expressed in a paradigm.

Although we call it "design paradigm", they are not actually confined to the design field. When thinking of "paradigm", it should be divorced from the traditional thinking mode of analysis, design and implementation. Instead, a "paradigm" is a specific expression of a complete set of ideas in a program, so it can sometimes occur in the analysis phase or in the advanced design phase. This is interesting because the paradigm has a form that is implemented directly in the form of code, so it may not be expected to be exposed before low-level design or implementation (and in fact, unless you really go into those stages, you generally don't realize that you need a paradigm to solve the problem).

The basic concept of paradigm can also be seen as the basic concept of programming: Add a new layer of abstraction! As long as we abstract something, it is the equivalent of isolating specific details. And the most compelling motivation behind this is "to isolate the changes that have been made to what remains unchanged." Another reason to do this is that once you discover that part of a program can change for one reason or another, we generally want to prevent those changes from reproducing within the code. This not only lowers the cost of maintaining the code, but also makes it easier to understand (the result is also reduced overhead).
In order to design a powerful and maintainable application project, the most difficult part is finding what I call "lead change". This means finding the most important thing that is causing the system to change, or looking at the most expensive part of the cost. Once you have discovered the "lead change", you can set a focus for yourself and start your own design around it.
So the ultimate goal of the design paradigm is to isolate the changed content in the code. If you look at it from this point of view, you will find that the book has actually adopted some design paradigms. For example, inheritance can be imagined as a design paradigm (similar to one implemented by a compiler). Inside objects that have the same interface (that is, things that remain unchanged), it allows us to express the difference in behavior (that is, what is changing). Synthesis can also be imagined as a paradigm, because it allows us to modify--dynamic or static--to implement the object of the class, and therefore to modify how the class works.
In the book "Design Patterns", you can see another paradigm: "inheritors" (i.e. Iterator,java 1.0 and 1.1 irresponsibly call it enumeration, that is, "enumeration"; Java1.2 's collection is changed back to the "successor" salutation). When we iterate through the set and select different elements one by one, the inheritors can effectively hide the implementation details of the collection. With inheritors, you can write out common code to take action on all elements in a sequence without caring about how the sequence is built. In this way, our generic code can be used with any collection that generates an inheritance.