Twenty-three classic design patterns have been finished, and here are some basic principles, so that the peacetime development can better experience.

SRP(Single Responsibility Principle)

There should never be more than one reason for a class to change.” In other words, every class should have only one responsibility.

Definition: a class or module should have one and only one reason to change. In JS, this applies more to objects and functions.

The hardest part is deciding on a single responsibility in the context of a specific scenario. It’s not a good idea to break down a module too thin to apply this principle, so we need to make a trade-off between convenience and stability.

The proxy pattern and decorator pattern mentioned earlier are reflected.

OCP(Open-Closed Principle)

Software entities should be open for extension, but closed for modification.

Definition: software entities such as classes, modules, and functions should be open for extension and closed for modification. Modules should be extended as far as possible without modifying the original code.

In normal development, it is necessary to separate the changing parts from the unchanging parts. When designing a structure, consider the parts that may change in the future as much as possible.

You can do this by placing hooks and using callback functions.

The publish and subscribe mode, template method mode, policy mode and responsibility chain mode mentioned before are all embodied.

LSP Liskov Substitution Principle

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Definition: all references to a base class must transparently use objects of its subclasses.

For example, if class A can be used somewhere, and class B inherits from class A, that place must be able to use class B.

This principle tells us that if we want to implement a new function when we inherit a class, we should write a new method instead of overwriting a method already implemented by the parent class.

Classes and inheritance are rarely written in normal front-end development, and this principle is rarely used.

Interface Segregation Principle (ISP)

Many client-specific interfaces are better than one general-purpose interface.

Definition: a client should not rely on interfaces it does not need, and dependencies between classes should be based on the smallest interface. The simple answer is to create a single interface, not a bloated interface. That is, the interface should be as detailed as possible, and the methods in the interface should be as few as possible.

For example, interface A has five methods. Class B implements interface A, but only uses three of them. In this case, interface A can be split.

Js has no interface, ignore it.

DIP(Dependency Inversion Principle)

Depend upon abstractions, not concretions

Definition: Programs rely on abstract interfaces, not concrete implementations. Simply put, program the abstraction, not the implementation, which reduces the coupling between the client and the implementation module.

This is often referred to as interface oriented (or base class) programming.

However, js does not have interfaces and abstract classes, so this principle does not apply.

The above five principles are often seen as SOLID principles, but there are several other principles.

Principle of Least Knowledge (LOD)

Definition: a software entity should interact with as few other entities as possible. Each software unit has minimal knowledge of other units and is limited to those closely related to its own unit.

Entity in front of more corresponding objects, functions, facade mode can be seen as the application of this principle.

The principle of least knowing is also known as the Law of Demeter (LOD), the sister of Zeus (wikipedia).

The Greek goddess of Agriculture.

The Demeter project was named after Demeter because we were working on a hardware description language Zeus and we were looking for a tool to simplify the implementation of Zeus. We were looking for a tool name related to Zeus and we chose a sister of Zeus: Demeter.

Later we promoted the idea that Demeter-style software development is about growing software as opposed to building software. We introduced the concept of a growth plan which is basically a sequence of more and more complex UML class diagrams.

Growth plans are useful for building systems incrementally.

I was using a hardware language called Zeus, and then I found a tool to optimize Zens, and I named it Demeter in order to connect them.

Here’s another excerpt from the “JavaScript Design, Development and Implementation” book about the advice between the two names:

Many people prefer to use the name Demeter’s Rule, perhaps because it’s cooler. But this book refers to Head First

Design Patterns suggests something called the least knowledge principle. One, because it’s a better name, and the other

While “rules” give the impression that they must be enforced, principles are only guidelines, and no principle is required in actual development

Subject to compliance. For example, while following the principle of minimum knowledge reduces dependencies between objects, it can also increase the number of objects that are too large to be difficult

To maintain the third party object. As with the single responsibility principle, whether you choose to make your code conform to the least knowledge principle in practical development,

It depends on the circumstances.

CARP(Composite/Aggregate Reuse Principle)

Definition: Use composition/aggregation rather than inheritance for reuse purposes.

KISS principle

Keep It Simple, Stupid, in your design.

The principle of YAGNI

Definition: Don’t do what You don’t need for the time being.

DRY principle

Definition: Don’t Repeat Yourself.

The total

All principles help us write code that is easy to maintain and expand, not to implement or over-design for the sake of implementation.

Some code that doesn’t need to be changed at all in the future can be implemented in the simplest way and refactured for the second or third time.

The application of design patterns and ground rules must be context-specific, and empty talk is meaningless.

We just need to understand these principles first and then experience them in daily development.