Six Principles of interface design

I. Principle of single responsibility

Single Responsibility Principle, abbreviated as SRP.

Definition: There should never is more than one reason for a class-to-change.

There should be and only one cause for class changes.

Division of duties? A single definition and level?

should be based on actual business conditions. Focus on the point of change.

In practice, classes are difficult to do with a single function, but the interface should be as single as possible.

Two. The Richter replacement principle

Liskov Substitution Principle, hereinafter referred to as LSP.

Definition: Functions that use pointers or references to base classes must is able to use objects of derived classes without Knowin G it.

(All references to base classes must be able to transparently use objects of their subclasses)

The Richter substitution principle defines a specification for good inheritance:

1. Subclasses must fully implement the method of the parent class

2. Subclasses can have their own personalities (attributes and methods).

3. Input parameters can be magnified when overriding or implementing a method of the parent class.

4. The output can be scaled down when you overwrite or implement a method of the parent class.

Note: It is important to use the parent class or interface when calling other classes in the class, and if the parent class or interface cannot be used, the design of the class has violated the LSP principle.

Three. Dependency Inversion principle

Dependence inversion Principle, short dip

Definition: Modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

Translation comes with three meanings:

1. High-level modules should not be dependent on low-layer modules, both should rely on their abstraction.

2. Abstraction should not depend on details.

3. Details should be based on abstraction.

Streamlined definition: interface-oriented programming.

Test-driven Development Test-driven development is the best embodiment of the dependency inversion principle.

Test-driven development requires that you write the test class first, and the test passes the implementation class, which requires you to think about the interface definition first.

Three ways to rely:

1. The constructor passes the dependent object.

The 2.Setter method passes a dependent object.

3. An interface declares a dependent object.

Best Practices:
1. Each class has as much as possible an interface or abstract class, or both abstract classes and interfaces.
2. The surface type of the variable is as far as the interface or abstract class.
3. No class should derive from a specific class.
4. Try not to overwrite the method of the base class.
5. Combined with the Richter replacement principle.

Four. Interface Isolation principle:
Interface--This refers to the interface defined with the interface keyword.
Defined:
1.Clients should not being forced to depend upon interfaces this they don ' t use. (The client should not rely on interfaces it does not need)
2.The dependency of one class to anther one should depend on the smallest possible interface. (Dependencies between classes should be based on the smallest interface)

Summary: Create a single interface, do not build a bloated and huge interface.

In layman's terms: the interface is as thin as possible, and the methods in the interface are as few as possible.

How to refine? What program is refined to?

There is no unified standard, should be based on business reasonable subdivision, suitable for business is the focus.

Ensure the pure junction of the interface:
1. The interface should be as small as possible.
2. The interface should be high cohesion.
3. Customized services.
4. There is a limit to the design of the interface.

Best Practices:
1. An interface serves only one sub-module or business logic.
2. Through the business logic compression interface in the public method, the interface often to review, as far as possible to get the interface to "flesh", rather than "fat doodle" a lot of methods.
3. The interface has been contaminated, as far as possible to modify, if the risk of a large change, the use of adapter mode for conversion processing.
4. Understand the environment and refuse to follow blindly. Each project or product has specific environmental factors, do not blindly follow the master's design, according to the business logic of the best interface design.

Five. Dimitri Law
Law of Demeter, LOD. Also known as the least knowledge principle (Least knowledge Principle, LKP).
In layman's terms: A class should know the least about the classes that it needs to be coupled or called, and how complex the internals of your (coupled or called classes) are to me, and that's your thing, I'll call the public method you provide, and nothing else will concern you.

Low COUPLING requirements:
1. Communicate only with friends
Friend class: The class that appears in the member variable, the input and output parameters of the method. The class inside the method body does not belong to a friend class.
2. There is also a distance between friends
Dimitri law requires the class "shy" point, try not to publish too many public methods and non-static variables, as far as possible, more introverted, use private, package-private, protected and other access rights.
3. It's your own.
If a method is placed in this class, it is placed in this class without increasing the relationship between the classes and not negatively affecting the class.
4. Use serializable sparingly

Six. Opening and closing principle
Software entities like classes, modules and functions should is open for extension but closed for modifications. (a software entity such as class, Modules and functions should be open to extensions, closed for modifications)

Software entities include the following sections:
1. Modules that are separated by certain logical rules in the project and software products.
2. Abstractions and classes.
3. Methods.

Three types of changes:
1. Logical Changes
2. Sub-module changes
3. Visible view Changes

Six principles of interface design