Five Principles of OOP

 

Basic Principles

• Encapsulation change encapsulate what varies.
• The code to an interface rather than to an implementation is not implemented for the interface.
• Combination is preferred, rather than favor composition over inheritance

SRP: the single responsibility principle single responsibility

Each object in the system should have only one separate responsibility, and all objects focus on the completion of their own responsibilities.

Every object in your system shocould have a single responsibility, and all the object s services shocould be focused on carrying out that single responsibility.

 

1. Each responsibility is a design change. When the demand changes, the demand changes are reflected in the changes of class responsibilities. When the objects in your system have only one reason for change, you have followed the SRP principle.
2. If a class has too many responsibilities, these responsibilities are coupled. A change in responsibility may weaken or suppress the ability of other responsibilities of this category. This design will lead to a fragile design. When a change occurs, the design will be unexpectedly damaged.
3. SRP makes the system easier to manage and maintain because not all problems are involved.
4. Cohesion cohesion is actually another name of the SRP principle. If you write high cohesion software, it means that you have applied the SRP principle well.
5. How can we determine whether a responsibility is an object? You try to let this object fulfill this responsibility by yourself. For example, "the book reads the content by yourself" is clearly not the responsibility of the book.
6. Only when a change occurs can the changed axis have practical significance. If there is no indication, it is unwise to apply SRP or any other principles.

Dry: Don't repeat yourself Principle

Avoid code duplication by extracting public parts and placing them in one place.

Avoid duplicate code by Using acting out things that are common and placing those thing in a single location.

 

1. Dry is simple, but it is the key to ensuring that our code is easy to maintain and reuse.
2. What do you actually do when you try to avoid repeated code? It is to ensure that every requirement and function is only implemented once in your system, otherwise there will be a waste! There is no intersection between system use cases, so our code should not be repeated. From this perspective, dry is not just about code.
3. Dry focuses on information and behavior in the system in a single, obvious position. Just like you can guess the position of a regular expression in. net, you can guess it because it is reasonable.
4. Dry principle: how to effectively split system functions! The clear division of duties ensures the uniformity of code to a certain extent.
   

OCP: Open-Close principle Principle

Class should be closed for modification and open for extension;

Classes shoshould be open for extension, and closed for modification.

 

1. OCP focuses on flexibility. changes are made by adding code, rather than modifying existing code;
2. OCP applications are limited to changes that may occur. Similar changes that may occur in the future are isolated by creating abstractions.
3. The OCP principle conveys the idea that once you write code that can work, you must strive to ensure that this code can always work. This is a bottom line. A little higher requirement, once our code quality reaches a level, we need to do our best to ensure that the code quality does not roll back. Such requirements prevent us from solving a problem by means of a live solution, or by letting ourselves flow; for example, the Code has added numerous processes for specific data, and more special code is available. The Code intent is ambiguous and degrades.
4. The mechanism behind OCP: encapsulation and abstraction. Blocking is based on abstraction, and display is obtained using abstraction. inheritance is the simplest example of OCP. In addition to subclass and method overloading, we also have some more elegant methods for implementation, such as combination;

How can I change the source code without changing the source code (disabling modification? The answer is abstraction. The mechanism behind OCP is abstraction and polymorphism.

1. There is no appropriate model that can adapt to all situations! There must be changes and it is impossible to completely close them. It is not a good idea to abstract every part of the program. The correct approach is that developers only abstract the frequently changed part. Rejecting immature abstractions is just as important as abstraction itself.
2. OCP is the core of many claims by Ood. If this principle is applied effectively, we can gain stronger maintainability, reusable flexibility, and robustness. LSP is one of the main principles that OCP has become possible.

LSP: The liskov substitution principle

The subclass must be able to replace the base class.

Subtypes must be substitutable for their base types.

 

1. LSP focuses on how to use inheritance well.
2. You must know whether to use a method or extend it, but it is definitely not changed.
3. LSP clearly pointed out that the IS-A relationship of OOD is in terms of the behavior mode, the behavior mode can be reasonable assumptions, is the customer program relies on.
4. LSP makes us come to an important conclusion: If a model is isolated, it is not really effective. The validity of the model can only be expressed through its customer program. It must be examined based on reasonable assumptions made by the intended user. The assumption is unpredictable and will not be handled until the design odor appears.
5. LSP violations may also violate OCP

Dip: Dependency inversion principle

The high-level module should not depend on the underlying module, both of which should depend on abstraction.

Abstraction should not depend on details. Details should depend on abstraction.

1. What is a high-level module? The high-level module includes important policy selection and business model in applications. These high-level modules differentiate their applications from others.
2. If the high-level module depends on the underlying module, it is very difficult to reuse the high-level module in different contexts. However, if the high-level module is independent of the underlying module, the high-level module can be easily reused. This principle is the core principle of the Framework Design.
3. The inversion here is not only the inversion of dependency, but also the inversion of interface ownership. When dip is applied, we will find that customers often have abstract interfaces, and service providers derive from these abstract interfaces.
4. This is the famous principle of Hollywood: "Don't call us we all call you." The underlying module implements the interface declared in the high-level module and called by the high-level module.
5. By putting the image upside down, we created a more flexible, persistent, and easy-to-change structure.
6. The simple heuristic rule of dip: dependent on abstraction; this is a simple statement. The suggestion of this rule should not depend on a specific class, that is to say, the program summarizes all dependencies and should be planted in abstract classes or interfaces.
7. If a class is stable, it does not cause any harm. However, most of our own classes are unstable. By hiding them behind abstract interfaces, they can isolate instability.
8. Dependency inversion can be applied to any place where one class sends messages to another class.
9. The dependency inversion principle is the basic underlying mechanism to realize the benefits of many Object-oriented technologies, and is the symbol of object-oriented.

ISP: interface isolation principle

Customer programs should not be forced to rely on methods they do not need.

 

1. The interface is not highly cohesive. An interface can be divided into N groups of methods, so this interface needs to be processed by ISP.
2. The division of interfaces is determined by the customer program that uses it. The customer program is a separate interface and should also be separated.
3. When an interface contains too many behaviors, leading to abnormal dependencies between their customer programs, what we need to do is to separate the interfaces and implement decoupling.
4. After applying the ISP, the customer program will see multiple cohesive interfaces.