Five Principles of OO

When learning and using OO design, we should understand that the emergence of OO enables software engineers to describe software systems in a way closer to the real world. However, software, after all, is built on an abstract level. how close it is to the truth cannot replace the truth or be replaced by the truth.
The five principles of OO design are not isolated from each other. There is a certain correlation between them. One can be the strengthening or foundation of another principle. Violation of one of them may also violate other principles. Therefore, these principles should be integrated and kept in mind!
The five principles of OO refer to SRP, OCP, LSP, dip, and ISP.
1. SRP (single responsibility principle)
A single responsibility is easy to understand and implement. A single responsibility means that a design element only does one thing. What is "only one thing "? To put it simply, you just need to be nosy. In reality, if you want to concentrate on one thing, anyone can do well with confidence.
As a high-level principle of OO, OCP advocates the use of "abstract action" and "polymorphism" to change the static structure in the design to a dynamic structure to maintain the closeness of the design.
2. OCP: Open Close Principle ) It is very simple: "Closed for modification; open for extension" -- "Closed for change; open for extension ". The principle of opening and closing is actually nothing to mention. I will attribute it to a high-level General design principle. The motivation for OCP is simple: software changes. Both high-quality design and poor design cannot avoid this problem. OCP demonstrates that the software design should be as stable as possible and easily meet different needs. Why is OCP required? The answer is also simple-reuse.
3. LSP-liskov substitution principle )
As a high-level principle of OO, OCP advocates the use of "abstract action" and "polymorphism" to change the static structure in the design to a dynamic structure, maintaining the design closeness "abstraction" is a function provided by languages. Polymorphism is implemented by inheritance semantics. As a result, the question arises: "How do we measure the quality of the inheritance relationship ?"
In 1987, liskov proposed an inheritance principle "inheritance shoshould ensure that any property proved about supertype objects also holds for subtype objects. "--" inheritance must ensure that the properties of the superclass are still valid in the subclass." That is to say, when a subclass instance should be able to replace any of its superclasses, There Is A is-a relationship between them.
This principle is referred to as liskov substitution principle -- Lishi replacement principle.
Let's take a look at the essence of LSP. When learning Oo, we know that an object is a combination of States and a series of behaviors. A State is an internal feature of an object, and a behavior is an external feature of an object. What LSP expresses is that objects in the same inheritance system should have common behavior characteristics.
This shows the essential difference between inheritance of OO and inheritance in daily life. For example, penguins belong to birds in the biological classification system. We mimic this system and design such classes and relationships.

There is a method fly in the "bird" category. Penguins naturally inherit this method, but penguins cannot fly. Therefore, we cover the fly method in the penguin category, callers who tell the method: penguins will not fly. This is totally in line with common sense. However, this violates LSP. Penguins are child birds, but penguins cannot fly! It should be noted that the "bird" here is no longer a bird in biology. It is a class and abstract in software.
Some people may say that penguins cannot fly normally.CodeIt can also be compiled normally, as long as you add a judgment in the Customer Code that uses this class. However, this is the problem! First of all, the customer code and the penguin Code may not be designed at the same time. In today's software outsourcing development model, you don't even know where the two modules are, so you can't modify the customer code. CustomerProgramIt is likely that it is part of the legacy system, and it is likely that it is no longer maintained. If such a "Penguin" is designed and the Customer Code must be modified, who should take responsibility for this part? (Maybe it's God. Who told him that "Penguins" cannot fly. Pai_^) "modifying Customer Code" directly violates OCP, which is the importance of OCP. Violation of LSP will prevent the existing design from being closed!

LSP does not provide a solution to this problem, but just raises such a problem. As a result, engineers began to focus on how to ensure the behavior of objects. In 1988, B. Meyer proposed the design by contract (contractual design) theory. DBC draws on a set of methods to ensure the object behavior and its own state from the formal method. The basic concept is simple:

Before each method is called, The method should verify the correctness of the input parameters. Only the method can be executed correctly. Otherwise, the caller is deemed to be in violation of the contract and will not be executed. This is called pre-condition ).
Once the pre-condition verification is passed, the method must be executed and the execution result must comply with the contract. This is called post-condition ).
The object itself has a set of check conditions for its own status to ensure that the nature of the object does not change, which is called invariant ).
These are constraints for a single object. In order to satisfy the LSP, when there is an inheritance relationship, the preconditions of the methods in the subclass must be the same or looser than those of the methods covered in the superclass; the post-condition of the method in the subclass must be the same or stricter than the post-condition of the method covered in the superclass.

4.Dip Dependency inversion principle(Dependency inversion principle)
Dependence inversion principle: It depends on abstraction and not on specifics.
In short, the dependency inversion principle requires the client to rely on abstract coupling. Principles:
Abstraction should not depend on details; details should depend on abstraction;
Programming for interfaces is not implemented.

5.Interface segregation principle)
It is better to use multiple dedicated interfaces than to use a single total interface. Generalized interface: an interface is equivalent to a role in the script, and the actors playing this role on a stage are equivalent to the interface implementation. Therefore, an interface should represent a role rather than a role ., If the system designs a Togo role, each role should be represented by a specific interface. Narrow interface: The interface isolation principle means that the same role provides wide and narrow interfaces to deal with different clients.

Http://blog.csdn.net/haitang416/article/details/4321246