Core rule of object-oriented design patterns-javascript tips-js tutorial

There is a classic book called design patterns, which talks about 21 classic design patterns. We suggest you take a look. 1. Single responsibility

For a class, there should be only one reason for its change.
If a class has too many responsibilities, it is equivalent to coupling these responsibilities. A change in responsibilities may weaken or suppress the class's ability to fulfill other responsibilities. This coupling will lead to a fragile design. When a change occurs, the design will be unexpectedly damaged.
What software design really needs to do is to discover responsibilities and separate them from each other. If you have more than one motive to change a class, this class has more than one responsibility.

2. Open and closed

Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified. That is to say, the extension is open, and the change is closed.
With such a design, the system can maintain relatively stable requirements, so that the system can continuously launch new versions after the first version.
No matter how close the module is, there will be some changes that cannot be closed to it. Since it cannot be completely closed, the designer must choose which change should be closed for the module he designed. He must first guess the most likely types of changes, and then construct an abstraction to isolate those changes.
Take action immediately when changes occur.

When we first wrote the code, we assumed that the change would not happen. When a change occurs, we create an abstraction to isolate similar changes that occur later.
In the face of requirements, changes to the program are made by adding new Code, rather than changing the existing code.
We hope that we will know the possible changes shortly after the development work starts. The longer it takes to identify possible changes, the more difficult it is to create a correct abstraction.
The open-closed principle is the core of object-oriented design. Following this principle can bring about the huge benefits that object-oriented technology claims, that is, maintenance, scalability, reusability, and flexibility. Developers should only abstract those parts that present frequent changes in the program. However, it is not a good idea to abstract each part of the application. Rejecting immature abstractions is just as important as abstraction itself.

3. Reverse dependency

High-level modules should not depend on underlying modules. Both of them should depend on abstraction.
Abstraction should not depend on details. Details should depend on abstraction.
Abstraction should not depend on details. Details should depend on abstraction. For interface programming, do not implement programming.
Dependency inversion can be said to be a sign of object-oriented design. It doesn't matter which language is used to write a program. If the programming is based on abstract programming rather than detailed programming, that is, all dependencies in the program are terminated from abstract classes or interfaces, that is, object-oriented design, and vice versa, that is, procedural design.

4. Lishi replacement

If a software object uses a parent class, it must be applicable to its subclass and cannot detect the difference between the parent class object and the Child class object. That is to say, in the software, replace the parent class with its Child class, and the behavior of the program remains unchanged.
Child types must be replaced with their parent types.
Only when the child class can replace the parent class and the functions of the software unit are not affected can the parent class be reused. The Child class can also add new behaviors based on the parent class.

5. Merging/aggregation multiplexing

Try to use synthesis/aggregation, and try not to use class inheritance.
Preferential use of object merging/aggregation will help you keep each class encapsulated and concentrated on a single task, so that the tired and class inheritance layers will maintain a small scale, and it is unlikely to grow into an uncontrollable giant.

6. dimit's Law

If the two classes do not need to communicate with each other directly, then the two classes should not interact directly. If one class needs to call a method of another class, it can be forwarded by a third party.
In the structure design of classes, each class should minimize the access permissions of members. That is to say, a class encapsulates its own private State, do not disclose fields or behaviors that other classes know.
Its fundamental idea is to emphasize the loose coupling between classes.

The weaker the coupling between classes, the more conducive to reuse. A class with weak coupling is modified and will not affect related classes.

Auxiliary materials:

Common creation-type design modes (do not mention other types and read your own books)

The Creation Mode hides how instances of these classes are created and put together. What the entire system knows about these objects is interfaces defined by abstract classes. In this way, the creation mode provides great flexibility in what it creates, who it creates = How it is created, and when it is created.

1. Factory Method)

Defines an interface used to create objects so that the subclass determines which class to instantiate. The factory mode delays the instantiation of a class to its subclass.
The Creation Mode abstracts the instantiation process and helps a system to create, combine, and express its objects independently. The Creation Mode encapsulates information about the specific classes used by the system. Allows the customer to configure a system with a 'product' object with a very different structure and function. The configuration can be static or dynamic during compilation, that is, it can be specified again during runtime.
Generally, the design should start with the factory method. When the designer finds that more flexibility is required, the design will evolve to other creation modes. When the designer balances the design standards, understanding multiple creation modes gives the designer more options.

2. Abstract Factory)

Provides an interface for creating a series of or related dependent objects without specifying their specific classes.

3. Builder Mode)

Separates the construction of a complex object from its representation, so that different representations can be created during the same construction process.
Cohesion and coupling cohesion describes the closeness between components of a routine. Coupling describes the closeness between a routine and other routines. The purpose of software development should be to create such a routine: internal integrity, that is, high cohesion, and the relationship with other routines is small, direct, visible, and flexible, this is loose coupling.
Separating the construction of a complex object from its representation can easily change the internal representation of a product and separate the Construction Code from the representation code. In this way, the customer does not need to care about the product creation process, but only needs to tell me what it needs, I can use the same build process to create different products for the customer.

4. Prototype)

Use a prototype instance to specify the object type and copy the prototype to create a new object.
It is usually easier to create a prototype and clone them than to manually instantiate the type with the appropriate state each time.

5. Singleton)

Ensure that a class has only one instance and provides a global access point to it.
For some classes, an instance is very important. A global variable can make an object accessible, but it cannot prevent the customer from instantiating multiple objects. The advantage of a singleton is that the class itself is responsible for saving its unique instance. This class ensures that no other instance can be created, and the singleton also provides a method to access the instance. In this way, you can strictly control how and when the customer accesses a unique instance.