Interface Segregation Principle, the ISP interface isolation principle advocates that using multiple dedicated interfaces is better than using a single total interface.
The dependence of one class on another class should be established on the smallest interface.
An interface represents a role, and different roles should not be handed over to an interface. The unrelated interfaces are merged together to form a bloated large interface, which is a pollution to the role and interface.
"Customers should not be forced to rely on methods they do not use. Interfaces belong to customers, not the class hierarchy they are in." This is very clear. In simple terms, don't force customers to use methods they do not use. If users are forced to use methods they do not use, then these customers will face changes caused by changes in these methods they do not use.
In the use case, provide the methods needed by the caller and block unnecessary methods. It meets the principle of interface isolation. For example, in the e-commerce system, there are three places that will be used in the order category.
According to the Interface Isolation Principle (ISP), the dependence of one class on another class should be established on the smallest interface.
That is to say, for a portal, it can only rely on an interface with a query method.
The UML structure is as follows:
Let's look at an example of Java interface writing that ignores the principle of interface isolation:
interface I { public void method1(); public void method2(); public void method3(); public void method4(); public void method5(); } class A{ public void depend1(I i){ i.method1(); } public void depend2(I i){ i.method2(); } public void depend3(I i){ i.method3(); } } class B implements I{ public void method1() { System.out.println("Method1" to implement interface I"); } public void method2() { System.out.println("Method 2 of Class B implements Interface I"); } public void method3() { System.out.println("Method 3 of Class B implements Interface I"); } //For class B, method4 and method5 are not required, but since there are these two methods in interface A, //In the implementation process, even if the method body of these two methods is empty, these two methods must be implemented. public void method4() {} public void method5() {} } class C{ public void depend1(I i){ i.method1(); } public void depend2(I i){ i.method4(); } public void depend3(I i){ i.method5(); } } class D implements I{ public void method1() { System.out.println("Method1" to implement interface I"); } //For class D, method2 and method3 are not required, but because there are these two methods in interface A, //So even if the method body of these two methods is empty during the implementation process, these two methods that have no effect must be implemented. public void method2() {} public void method3() {} public void method4() { System.out.println("Method 4 of Class D implements Interface I"); } public void method5() { System.out.println("Method 5 of Class D implements Interface I"); } } public class Client{ public static void main(String[] args){ A a = new A(); a.depend1(new B()); a.depend2(new B()); a.depend3(new B()); C c = new C(); c.depend1(new D()); c.depend2(new D()); c.depend3(new D()); } } It can be seen that if the interface is too bloated, as long as the methods appear in the interface, regardless of whether they are useful to the classes that depend on it, these methods must be implemented in the implementation class. This is obviously not a good design. If this design is modified to comply with the principle of interface isolation, interface I must be split. Here we split the original interface I into three interfaces. The split design is shown in the figure below:
As usual, post the program code for reference for friends who are not familiar with the class diagram:
interface I1 { public void method1(); } interface I2 { public void method2(); public void method3(); } interface I3 { public void method4(); public void method5(); } class A{ public void depend1(I1 i){ i.method1(); } public void depend2(I2 i){ i.method2(); } public void depend3(I2 i){ i.method3(); } } class B implements I1, I2{ public void method1() { System.out.println("Method 1 of Class B implements interface I1"); } public void method2() { System.out.println("Method 2 of Class B implements interface I2"); } public void method3() { System.out.println("Method 3 of Class B implements interface I2"); } } class C{ public void depend1(I1 i){ i.method1(); } public void depend2(I3 i){ i.method4(); } public void depend3(I3 i){ i.method5(); } } class D implements I1, I3{ public void method1() { System.out.println("Method 1 of Class D implements Interface I1"); } public void method4() { System.out.println("Method 4 of Class D implements Interface I3"); } public void method5() { System.out.println("Method 5 of Class D implements Interface I3"); } } The meaning of the principle of interface isolation is: establish a single interface, do not establish a huge and bloated interface, try to refine the interface, and try to fewer methods in the interface. In other words, we need to establish a dedicated interface for each class, instead of trying to establish a huge interface for all classes that depend on it to call. In this example, the principle of interface isolation is adopted when changing a huge interface to three dedicated interfaces. In programming, relying on several dedicated interfaces is more flexible than relying on one comprehensive interface. Interfaces are "contracts" set for external settings during design. By defining multiple interfaces, the spread of external changes can be prevented and the flexibility and maintainability of the system can be improved.
Speaking of this, many people will feel that the principle of interface isolation is very similar to the previous single responsibility principle, but it is not. First, the principle of single responsibility focuses on responsibilities; while the principle of interface isolation focuses on isolation of interface dependence. Second, the principle of single responsibility is mainly constraint classes, followed by interfaces and methods, which are aimed at the implementation and details in the program; while the principle of interface isolation mainly constrains interface interfaces, mainly aimed at abstraction, and aimed at the construction of the overall program framework.
When using the principle of interface isolation to constrain interfaces, the following points should be paid attention to:
The interface should be as small as possible, but it should be limited. Refining the interface can improve programming flexibility is a fact that it is not profitable, but if it is too small, it will cause too many interfaces and complicate the design. So it must be moderate.
Customized services for classes that depend on interfaces, only the methods it needs to be exposed to the called class, and the methods it does not need are hidden. Only by focusing on providing customized services for a module can you establish a minimum dependency relationship.
Improve cohesion and reduce external interactions. Use the least amount of interface to accomplish the most things.
When using the principle of interface isolation, it must be moderate. It is not good to have too large or too small interface design. When designing interfaces, only by spending more time thinking and planning can this principle be accurately practiced.