The five principles of OO refer to SRP, OCP, LSP, DIP, ISP.
SRP--(single Responsibility Principle sole responsibility principle)
ocp--Opening and closing principle (Closed for modification; Open for Extension)
The recently collated documents are provided to you, here on the LSP focus on the introduction, hope for everyone to help, in the learning and use of OO design, we should understand: the advent of OO enables software engineers to use closer to the real-world approach to describe the software system. However, after all, the software is based on the abstract level of things, how close to the real, can not replace the real or be replaced by the real.
The five principles of OO design are not isolated from each other. There is a certain correlation between each other, one can be the strengthening or the foundation of another principle. Violating one of these may also violate the rest of the principles. Therefore, these principles should be assimilated, keep in mind!
The five principles of OO refer to SRP, OCP, LSP, DIP, ISP.
1. SRP (single Responsibility Principle sole responsibility principle)
A single responsibility is easy to understand and easy to implement. The so-called single duty is a design element that only does one thing. What is "doing one thing"? To put it simply is to be nosy. In reality, if you want to concentrate on one thing, anyone has the confidence to do it well.
As the high-level principle of OO, OCP advocates the use of "abstract (abstraction)" and "polymorphic (polymorphism)" To change the static structure of the design into dynamic structure and maintain the sealing of the design.
2. OCP: Opening and closing principle, very simple, a word: "Closed for modification; Open for Extension "--" closed for changes, open for expansion ". Open and close principle there is nothing to say, I will boil it down to a high-level design general principles. The intent of the OCP is simple: the software is changing. Neither high-quality design nor poor design can avoid this problem. The OCP demonstrates that software design should be as stable as possible and easy to meet different needs. Why the OCP? The answer is simple--reuse.
3.lsp--Richter Replacement principle
As the high-level principle of OO, OCP advocates using "abstract (abstraction)" and "Polymorphism (polymorphism)" To change the static structure in design to dynamic structure, while maintaining the closed "abstraction" of the design is the function provided by the language. Polymorphism is implemented by inheritance semantics. So, the question arises: "How do we measure the quality of the inheritance relationship?" ”
In 1987, Liskov proposed a principle of inheritance "inheritance should ensure that any property proved about Supertype objects also holds for subtype Objects. " --"inheritance must ensure that the properties owned by the superclass remain in the subclass." "That is, when an instance of a subclass should be able to replace any instance of its superclass, there is a is-a relationship between them.
This principle is called Liskov Substitution principle--the Richter replacement principle.
Let's look at the nature of the LSP. When we learn oo, we know that an object is a combination of a set of States and a series of behaviors. State is the intrinsic property of an object, and behavior is the external characteristic of an object. The LSP stated that objects in the same inheritance system should have common behavioral characteristics.
This point shows the essential difference between OO inheritance and the inheritance in daily life. As an example: the biological classification system of the penguin belongs to the birds. We imitate this system and design such classes and relationships.
Class "Bird" There is a way fly, penguins naturally inherited this method, but penguins can not fly, so, we in the Penguin class covered the Fly method, tell the method caller: Penguins will not fly. It's perfectly logical. However, this violates the LSP, Penguin is a child of birds, but penguins can not fly! It is important to note that the "bird" here is no longer a bird in biology, it is a class, an abstraction in the software.
Some people will say that penguins can not fly very normal ah, and so write code can be compiled normally, as long as the use of this class of customer code to add a sentence to judge. But that's where the problem lies! First of all, the customer code and the "Penguin" code is probably not designed at the same time, in today's software outsourcing layer after layer of development mode, you do not even know the origin of the two modules, there is no way to modify the customer code. The client program is likely to be part of the legacy system and is probably no longer maintained, and who should be responsible if the customer code has to be modified because of the design of a "penguin"? (probably God, who told him to let "penguins" can't fly.) ^_^) "Modify customer code" directly violates the OCP, which is the importance of OCP. Violating the LSP will make the existing design impossible to close!
The revised design is as follows:
The LSP does not provide a solution to the problem, but only raises the question. As a result, engineers began to focus on how to ensure the behavior of objects. In 1988, B. Meyer proposed design by contract (contract design) theory. DBC draws on a set of methods to ensure object behavior and its state from a formal approach, the basic concept is simple:
Before each method call, the method should verify the correctness of the passed parameters, only the correct ability to execute the method, or assume that the caller violates the contract and does not execute. This is called a pre-condition (pre-condition).
Once a pre-condition check is passed, the method must be executed and must ensure that the execution result conforms to the contract, which is called a post condition (post-condition).
The object itself has a check condition to verify its state to ensure that the object's nature does not change, which is called invariant (invariant).
These are the constraints of a single object. In order to satisfy the LSP, when there is an inheritance relationship, the precondition of the method in the subclass must be the same or looser than the predecessor condition of the method overridden in the superclass, and the post condition of the method in the subclass must be the same or stricter than the post condition of the method overridden in the superclass.
4.DIP Dependency Inversion principle
The principle of dependency inversion (dependence inversion Principle) is to rely on abstraction, not on specifics.
Simply put, the dependency inversion principle requires the client to rely on abstract coupling. Principle statement:
Abstraction should not be dependent on detail; details should be dependent on abstraction;
To program for the interface, do not program for implementation.
5.ISP Interface Isolation principle
Using multiple specialized interfaces is better than using a single total interface. Generalized interface: An interface is equivalent to a role in a script, and the role of the actor on a stage is equivalent to the implementation of the interface. So an interface should simply represent a role, not a role. , if the system designs multiple roles, then each role should be represented by a specific interface. Narrow Interface (Interface): The principle of interface isolation is that the same role provides a wide, narrow, different interface to deal with different clients.
The Five principles of oo: SRP, OCP, LSP, DIP, ISP
