Interface isolation principle of object-oriented design principle

The interface isolation principle is defined as follows:

Interface Isolation principle (Interface segregation Principle, ISP): use multiple specialized interfaces instead of a single total interface, that is, the client should not rely on interfaces that it does not need.

Based on the interface isolation principle, when an interface is too large, we need to split it into smaller interfaces, and the client using that interface needs only to know the methods associated with it. each interface should assume a relatively independent role, do not do the things that should not do, the work should be done. the "interface" here often has two different meanings: one refers to the set of method features that a type has, is merely a logical abstraction, and the other refers to a specific "interface" definition of a language, with strict definitions and structures, such as interface in the Java language. For these two different meanings, the way the ISP is expressed and what it means is different:

(1) When the "interface" is understood as a set of all the method features provided by a type, this is a logical concept, the division of the interface will directly bring the division of the type. The interface can be understood as a role, an interface can only represent a role, each role has its own specific interface, this principle can be called " role Isolation Principle ."

(2) If the "interface" is understood as a narrow language-specific interface, then the ISP expression means that the interface only provides the behavior that the client needs, the client does not need to hide the behavior, should provide the client with the smallest possible separate interface, rather than provide a large total interface . In an object-oriented programming language, implementing an interface requires implementing all of the methods defined in the interface, so it is not always convenient to use a large total interface, in order to make the interface a single function, it is necessary to put the methods of the large interface in different small interfaces according to their responsibilities, in order to ensure that each interface is more convenient to use. And all assume a single role. The interface should be as thin as possible, and the methods in the interface should be as few as possible, each interface contains only one client (such as a submodule or business logic Class) required methods, this mechanism is also called " Custom Service ", that is, to provide different clients with different interfaces.

The following is a simple example that deepens the understanding of the principle of interface isolation:

The   Sunny software developer designed 1 interfaces for the customer data display module of a CRM system, where the method Dataread () is used to read data from a file, and the method Transformtoxml () is used to convert the data to XML format. Method Createchart () is used to create a chart, Method Displaychart () is used to display a chart, method CreateReport () is used to create a text report, and Method Displayreport () is used to display a text report. diagram 1  initial design scheme chart        in the actual use of the interface is not flexible, for example, if a specific data display class without data conversion (the source file itself is the XML format), but because the implementation of the interface, it will have to implement the Declaration of the Transformtoxml () Method (you need to provide at least one empty implementation), and if you need to create and display a chart, you need to implement a method to create and display a text report, unless you want to implement a chart-related method, or the program compiles with an error.       is now refactored using the interface isolation principle.

In Figure 1, because there are too many methods defined in the interface Customerdatadisplay, that is, the interface takes too much responsibility, on the one hand, the implementation class of the interface is very large, in different implementation classes have to implement all the methods defined in the interface, the flexibility is poor, if there are a large number of empty methods, will result in a large number of useless code in the system, affecting the quality of the code, on the other hand because the client program for the large interface, will be on a certain program to break the packaging of the program, the client sees the method should not be seen, no custom interface for the client. Therefore, the interface needs to be reconstructed according to the principle of interface isolation and the principle of single responsibility, and some of these methods are encapsulated in different small interfaces, ensuring that each interface is convenient to use and assumes a single role, each of which contains only one client (such as a module or class) that is required for the method.

By using the interface isolation principle, the refactoring of this example is shown in structure 2:

Fig. 2 Structure diagram after reconstruction

in the use of interface isolation principle, we need to pay attention to the granularity of the control interface, the interface can not be too small, if too small will lead to the system interface flooding, not conducive to maintenance, the interface can not be too large, too large interface will violate the principle of interface isolation, flexibility is poor, use is very inconvenient. in general, interfaces only contain methods that are customized for a particular class of users and should not force customers to rely on methods that they do not use.

Extended In the book "Agile Software Development-principles, patterns and practices", ROBERTC. Martin introduces the principle of interface isolation from the point of view of "interface pollution", and you can refer to the 12th chapter of this book-the Interface Isolation principle (ISP) for in-depth learning.

Interface isolation principle of object-oriented design principle