Five Principles of design pattern (SOLID)

Source: Internet
Author: User

S:Single Responsibility principle (Srp:singleresponsibilityprinciple)content:
as far as a class is concerned, there should be only one cause for it to change.
Origin of the problem:the T class includes responsibility T1, responsibility T2, and when the T class is modified due to T1 changes, the original T2 of the normal work does not work.
Cause:Responsibility Diffusion: A duty is divided into smaller, more granular duties.
Workaround:encapsulate different responsibilities into different modules or classes.
The goal is decoupling.:    if a class takes on too much responsibility, it is tantamount to coupling these responsibilities, and a change in responsibility can inhibit or weaken the ability of the class to perform other duties. ----------------------------------------------------------------------------- O:Opening and closing principle (Ocp:open-close priciple) Core idea:open to extensions: When new requirements change, existing code can be extended to accommodate the new situation.
Closed for modification: Once the class has been designed, it can do its work independently, rather than making any modifications to the class.
How to achieve:Fundamentals: Liskov substitution, synthesis/aggregation multiplexing principles
Implementation principle: Abstract programming. Because the abstract is relatively stable, so that the class depends on the fixed abstraction, so the modification is closed, and through the object-oriented inheritance and polymorphism mechanism, can realize the inheritance of the abstract body, by covering its methods to change the inherent behavior.
important means: package changes.
----------------------------------------------------------------------------- L:Richter substitution (lsp:the Liskov Substitution Principle)
content:
    subtypes must be able to replace their parent types.
     in the software to replace a base class object with its subclass object, the program will not produce any errors and exceptions, the reverse is not true, if a software entity uses a subclass object, then it is not necessarily able to use the base class object.
Application Tips:    use the base class to define the object as much as possible in the program, and then at run time to determine its subclass type, substituting the subclass object for the parent class object.
Precautions :(1) All methods of a subclass must be declared in the parent class, or the child class must implement all methods declared in the parent class. According to the principle of the substitution of the Richter scale, in order to ensure the extensibility of the system, the parent class is usually used in the program to define, if a method exists only in the subclass, does not provide the corresponding declaration in the parent class, the method cannot be used in the object defined in the parent class.
(2) When we use the Richter substitution principle, we try to design the parent class as an abstract class or interface, let the subclass inherit the parent class or implement the parent interface, and implement the method declared in the parent class, the runtime, the subclass instance replaces the parent class instance, we can easily extend the function of the system without modifying the code of the original subclass. Adding new functionality can be achieved by adding a new subclass.
----------------------------------------------------------------------------- I:Interface Isolation principle (isp:the Interface segregation priciple)
Defined:    The client should not rely on interfaces it does not need, and the dependency of one class on another should be based on the smallest interface.

Origin of the problem:

Class A relies on class B through interface I, Class C through interface I relies on Class D, and if interface I is not the smallest interface for Class A and Class B, then Class B and Class D must implement methods that they do not need.

Solution:

The bloated interface I is split into separate interfaces, and Class A and Class C are dependent on the interfaces they need, respectively. That is, the principle of interface isolation.

Precautions:
    • The interface is as small as possible, but there are limits. The fact that the interface can be refined to improve program flexibility is indisputable, but if it is too small, it can cause too many interfaces and complicate the design. So be sure to be modest.
    • Customizing the service for an interface-dependent class exposes only the methods it needs to the calling class, and the methods it does not need are hidden. A minimal dependency can be established only by focusing on providing a customized service for a module.
    • Increase cohesion and reduce external interaction. Enable the interface to do the most things with the least amount of method.
Differences from the principle of single responsibility:1. The principle of single duty focuses on responsibility; The interface isolation principle focuses on isolation of interface dependencies
2, the single responsibility principle is mainly the constraint class, Next is the interface and the method, he is aimed at the realization and the detail in the program, and the interface isolation principle mainly constrains the interface, mainly for the abstraction, for the program overall framework construction----------------------------------------------------------------------------- D:Dependency reversal (dip:the Dependency inversion Principle)
Content:A. High-level modules should not be dependent on low levels of modules, they should all rely on abstraction.
    B. Abstractions should not be dependent on specifics, but should be dependent on abstraction. The dependency inversion principle is based on the fact that:    In contrast to the variability of detail, the abstract things are much more stable. Structures built on the basis of abstraction are much more stable than structures built on the basis of detail.
Origin of the problem:    Class A is directly dependent on class B, and if you want to change Class A to dependency Class C, you must modify the code of Class A to achieve it. In this scenario, Class A is typically a high-level module that is responsible for complex business logic, and Class B and Class C are low-layer modules that are responsible for basic atomic operations, and if Class A is modified, it poses unnecessary risks to the program.
Solution:    Modifying Class A to dependent interface I, Class B and Class C each implement interface I, Class A through interface I indirectly with Class B or Class C, it will greatly reduce the chance to modify Class A.

In actual programming, we generally need to do the following 3 points:

    1. The low-level module should have an abstract class or interface as much as possible, or both.
    2. The declaration type of a variable is as abstract a class or interface as possible.
    3. Follow the Richter substitution principle when using inheritance.
There are three ways to implement dependency inversion:
1, through the construction function to pass the dependent object;

For example, the arguments that need to be passed in the constructor are implemented in the form of an abstract class or interface.

2, passing the dependent object through setter method;

that is, the arguments in the Setxxx method we set are abstract classes or interfaces that implement transitive dependent objects.

3, Interface declaration implementation of dependent objects, also known as interface injection;

That is, in the function declaration , the argument is an abstract class or interface, which implements the transitive dependent object, thus achieving the purpose of directly using the dependent object.

Essence: The essence of dependency inversion is contractual programming (interface-oriented programming), which makes the implementation of each class or module independent of each other by abstraction (abstract class or interface), which does not affect each other and allows for loose coupling between modules. The purpose of using interfaces or abstract classes is to make good specifications and contracts without involving any specific operations, and to give the task of presenting details to their implementation class to complete. If this principle is not implemented, it also means that the open and closed principle (for extended development, for modification closure) is not possible.



Five Principles of design pattern (SOLID)

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.