S.O.L.I.D is the acronym for several important coding principles (programming Priciple) in object-oriented design and programming (Ood&oop).
||the single Responsibility principle
|| single responsibility principle
||the Open Closed principle
|| The Liskov Substitution Principle
|| Richter substitution principle
||the Dependency inversion Principle
|| dependency inversion principle
||the Interface segregation Principle
|| interface separation principle
Steve Smith has a solidify Your ASP at Microsoft TechEd 2009 in May, Derick.bailey's solid development principles–in Motivationa L Pictures A good explanation of the solid principle.
Single Responsibility Principle:
There is only one reason when a class needs to be modified (there should never is more THAN A-REASON for a class-to-change). In other words, to have a class take only one type of responsibility, this class needs to be decomposed when the class takes on other types of responsibility.
Open Closure Principle
Software entities should be extensible and non-modifiable. In other words, the extension is open, and the modification is closed. This principle is one of the most abstract and difficult to understand in many object-oriented programming principles.
The principle of the Richter replacement
When an instance of a subclass should be able to replace any instance of its superclass, there is a is-a relationship between them
Dependency Inversion principle
1. High-level modules should not be dependent on low-layer modules, both should be dependent on abstract
2. Abstractions should not be dependent on detail, and details should be dependent on abstraction
Interface Separation Principle
You cannot force users to rely on interfaces that they do not use. In other words, using multiple specialized interfaces is better than using a single total interface.
These principles are very basic and important object-oriented design principles. It is because of the fundamental nature of these principles that understanding and integrating these principles requires a lot of experience and knowledge. The above picture is a good commentary on these principles.
The five basic principles of object-oriented
in the past, the class in the program has been used to encapsulate the inheritance polymorphism is object-oriented design, but it is not
encapsulation, inheritance, polymorphism is only the three main object-oriented features, but in the design of the program is not to say that the structure of the class used (or reflected) these three properties are object-oriented,
In fact, the real object-oriented design is to meet the following five principles,
five basic principles of object-oriented
Single responsibility principle (SRP)
Open closure principle (OCP)
Richter replacement principle (LSP)
Dependency inversion principle (DIP)
Interface isolation principle (ISP) Single Responsibility principle (SRP) • A class should have only one reason for it to change (simplest, easiest to understand and least likely to be a design principle)
Employee Class Examples:
For example, in the staff category, the engineers, sales staff, sales managers are in the staff class, the results will be very confusing, under this assumption, each method in the staff class is to determine what is the case, from the class structure will be very bloated, and the above three types of staff, No matter what kind of change in demand, the staff class will change! This is what we don't want to see!
Open closure principle (OCP) • Open and closed, open to extensions, and closed to changes! Expansion is to extend the existing modules, when the actual application of our software changes, the emergence of new requirements, we need to expand the module, so that it can meet the new requirements!
Change closure is when we extend the module, do not need to have program code and DLL for the source to modify or recompile the file!
This principle is very helpful to us in designing the class, insisting on this principle must consider the interface encapsulation, the abstract mechanism and the polymorphic technology as far as possible!
Richter replacement principle (LSP) • Subclasses can replace the parent class and appear anywhere the parent class can appear • This principle is also in the implementation of GOF advocate for interface programming!
In this principle, the parent class should be implemented using interfaces or abstract classes whenever possible!
Subclass by implementing the parent class interface, can be used for the parent class place!
With this principle, our clients are implemented by subclasses when using the parent class interface!
This means that we rely on the parent interface, declaring a parent class interface on the client, and using its subclasses to implement the
At this point the subclass must be able to replace any of the parent classes, and the benefit is that the new subclass of the parent class interface is extended to the new requirements without affecting the current client's use!
Dependency inversion principle (DIP) • In traditional structured programming, the top-level modules are usually dependent on the following sub-modules for
Called High-level dependency low!
So the dip principle is to reverse this dependency, so that high-level modules do not rely on low-layer modules, so called the dependency inversion principle!
ISP interface Isolation Principle • This principle means that it is much better to use multiple specialized interfaces than to use a single interface!
I have realized that in my actual programming, in order to reduce the definition of the interface, a lot of similar methods are placed in an interface, and finally found that the maintenance and implementation of the interface is too much effort, and the interface is defined by the operation of the client as a commitment, of course, the less the better, the more concise, the better, Too much commitment brings you a lot of energy and time to maintain!
The solid principle of object-oriented design