The characteristics of sub-class expression must not be more than the parent class

Inheritance is a form of abstraction, and if a subclass throws out an exception that is more abstract than the parent class, it is equivalent to showing more attributes than the parent class , which is incompatible with the design principle of inheritance.

The five principles of OO mean

SRP (a Class A duty, a method to do only one thing),
OCP (open for expansion, closed for modification),
LSP (where the parent class appears, you can use subclass overrides),
DIP (Dependency abstraction, interface-oriented programming),
ISP (using multiple small interfaces instead of a total interface, one interface representing a role).
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.

What is the so-called substitution principle? In development we usually implement some subclasses to achieve the extension of function, for example, if we have a base class B, a pointer of type B or a reference as a parameter of a function, then we create subclass C inherits from B, if some unexpected exception occurs when a pointer to Class C object is passed as a parameter, It violates the LSP.

Objective
Subclass types can completely replace base class types without exception

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,
Of the methods in the subclass.front-facing conditionsMust be the same or looser than the pre-condition of the overridden method in the superclass;
The post condition of a method in a subclass must be the same as or stricter than the post condition of the method being 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.

 Public class Parent {    publicvoid  Earnmoney () {        System.out.println ("Parent earn money !" );    }} class extends Parent {    @Override    publicvoidthrows  interruptedexception {        super. Earnmoney ();        Thread.Sleep (+);    }}

 Public class Parent {    publicvoidthrows  exception{        System.out.println (" Parent Earn money! " );    }} class extends Parent {    @Override    publicvoidthrows  interruptedexception {        super. Earnmoney ();        Thread.Sleep (+);    }}

The

Subclass expression must not have more features than the parent class (GO)