Design Principle [Interface Segregation Principle], I only do what I can do

1. What is the interface isolation principle

The Interface Segregation Principle (ISP) refers to the use of multiple dedicated interfaces instead of a single general interface, and the client should not rely on interfaces it does not need. This principle guides us to pay attention to the following points when designing interfaces:
1. The dependence of a class on a class should be based on the smallest interface.
2. Create a single interface instead of a huge and bloated interface.
3. Try to refine the interface as much as possible, and the methods in the interface should be as few as possible (not the less the better, it must be moderate).

Two, examples

The interface isolation principle conforms to the design idea of ​​high cohesion and low coupling that we often say, so that the class has good readability, scalability and maintainability. When we design the interface, we need to spend more time thinking about it, considering the business model, including making some predictions about possible changes in the future. Therefore, for abstraction, understanding of business models is very important. Let's look at a piece of code and write an abstraction of animal behavior:

// IAnimal 接口
public interface IAnimal {
    
    
	void eat();
	void fly();
	void swim();
}
// Bird实现
public class Bird implements IAnimal {
    
    
	@Override
	public void eat() {
    
    }
	@Override
	public void fly() {
    
    }
	@Override
	public void swim() {
    
    }
}
// Dog实现
public class Dog implements IAnimal {
    
    
	@Override
	public void eat() {
    
    }
	@Override
	public void fly() {
    
    }
	@Override
	public void swim() {
    
    }
}

It can be seen that the swim() method of Bird may only be empty, and the fly() method of Dog is obviously impossible. At this time, we design different interfaces for different animal behaviors, respectively design IEatAnimal, IFlyAnimal and ISwimAnimal interfaces, look at the code:

public interface IEatAnimal {
    
    
	void eat();
}

public interface IFlyAnimal {
    
    
	void fly();
}

public interface ISwimAnimal {
    
    
	void swim();
}

Dog can only eat and swim:

public class Dog implements ISwimAnimal,IEatAnimal {
    
    
	@Override
	public void eat() {
    
    }
	@Override
	public void swim() {
    
    }
}

Let's compare the class diagram:
insert image description here

3. Summary

The key to understanding the "interface segregation principle" is to understand the word "interface". There are three different interpretations here.

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.

Difference between Interface Segregation Principle and 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.

Guess you like

Origin blog.csdn.net/A_art_xiang/article/details/130563520