Article directory
"Design Pattern" Six Principles Series Links: "Design Pattern" One of the Six Principles: Summary of Single
Responsibility Summary of Principles Four of the Six Principles of "Design Patterns": Summary of the Principle of Interface Segregation Five of the Six Principles of "Design Patterns": Summary of the Principle of Dependency Inversion
The six principles reflect the underlying logic of many programming: high cohesion, low coupling, object-oriented programming, interface-oriented programming, abstract-oriented programming, and ultimately achieve readability, reusability, and maintainability.
The six principles of design patterns are:
- Single Responsibility Principle: Single Responsibility Principle
- Open Closed Principle: Open and Closed Principle
- Liskov Substitution Principle: Liskov Substitution Principle
- Law of Demeter: Law of Demeter (least known principle)
- Interface Segregation Principle: Interface Segregation Principle
- Dependence Inversion Principle: The principle
of dependency inversion combines the initials of these six principles (L is counted as one) is SOLID (solid, stable), which means the benefits of combining these six principles: establishing a stable, flexible , robust design.
This article introduces the fourth principle in SOLID: the interface segregation principle. It corresponds to the English letter "I" in SOLID.
1. Definition of interface isolation principle
The English translation of the interface segregation principle is "Interface Segregation Principle", abbreviated as ISP.
Robert Martin defined it in the SOLID principle as follows: "Clients should not be forced to depend upon interfaces that they do not use." Literally translated into Chinese: the client should not be forced to rely on interfaces that it does not need.
The "client" can be understood as the caller or user of the interface.
The purpose of the principle of interface segregation is to decouple systems so that they can be easily refactored.
The interface should be as small as possible, and the function should be as simple as possible. To put it bluntly, the granularity of the interface should be fine.
2. How to understand
The term "interface" can be used in many contexts. In life, we can use it to refer to socket interface and so on. In software development, we can regard it as a set of abstract conventions, or specifically refer to API interfaces between systems, or specifically refer to interfaces in object-oriented programming languages.
The key to understanding the principle of interface isolation is to understand the word "interface". In this principle, we can understand "interface" as the following three things:
- A collection of API interfaces
- A single API interface or function
- Interface concept in OOP
If you understand "interface" as a set of interfaces, it can be an interface of a microservice or an interface of a class library. If some interfaces are only used by some callers, we need to isolate this part of the interface and use it for this part of the caller alone, without forcing other callers to also rely on this part of the interface that will not be used.
If "interface" is understood as a single API interface or function, and some callers only need part of the functions in the function, then we need to split the function into multiple functions with finer granularity, so that the caller only depends on the one it needs Fine-grained functions.
If "interface" is understood as an interface in OOP, it can also be understood as an interface syntax in an object-oriented programming language. The design of the interface should be as simple as possible, and the implementation class and caller of the interface should not be dependent on unnecessary interface functions.
When applying this principle, you can refer to the following rules for measurement:
- The interface should be as small as possible, but within limits. An interface serves only one submodule or business logic.
- Customize services for classes that depend on interfaces. Only provide the methods that the caller needs, and block the methods that are not needed.
- Consider according to different standards of environment and business.
- Improve cohesion and reduce external interaction. Let the interface do the most things with the fewest methods.
Share a mind map from Java Shuoge :
3. The difference between the interface segregation principle and the single responsibility principle
The single responsibility principle is aimed at the design of modules, classes, and interfaces.
Compared with the single responsibility principle, the interface isolation principle focuses more on the design of the interface on the one hand, and on the other hand, its thinking angle is also different.
The interface segregation principle provides a standard for judging whether the responsibility of an interface is single: indirectly by how the caller uses the interface.
If the caller only uses part of the interface or part of the function of the interface, then the design of the interface is not enough to have a single responsibility.
2. Examples
To implement a music player, define an interface:
interface IMusicPlayer {
//开始
void start();
//停止
void stop();
//暂停
void pause();
//复原
void resume();
//获取歌曲时长
String getSongLength();
}
Here the principle of single responsibility is satisfied, but interface isolation is not satisfied.
If we now have a song displayer SongDisplayer that needs to display the length of the song, then we should also have a getSongLength() function. Do we directly implement the IMusicPlayer interface? To implement this interface, we must implement methods such as start() inside, but these methods It is definitely not what I need, nor what I should have. This is the problem, because the interface is not small enough, not clean, not pure, which obviously violates the principle of interface isolation, so we can split the interface:
//音乐播放器就仅限于对播放的控制
interface IMusicPlayer {
//开始
void start();
//停止
void stop();
//暂停
void pause();
//复原
void resume();
...
}
//歌曲展示器就仅限于对歌曲信息的展示
interface ISongDisplayer {
//获取歌曲时长
String getSongLength();
//获取歌曲名字
String getSongName();
...
}
When we implement the player, we can implement these two interfaces at the same time. If we only need to display song information, we only need to implement ISongDisplayerit .
public class MyPlayer implements IMusicPlayer,ISongDisplayer{
//……
}
This implementation is more convenient for maintenance and also complies with our interface isolation principle.
4. Summary
The interface should be as small as possible, as simple as possible, and irrelevant interfaces should not be redundant. The granularity is small, more coupled, more flexible, and will not hurt the bones.
reference:
"The Beauty of Design Patterns"
"Re-learning Java Design Patterns"
"Android source code design pattern analysis and actual combat"