Design Pattern Six Principles (4): interface Isolation principle

Definition: The client should not rely on interfaces it does not need, and the dependency of one class on another should be based on the smallest interface.

The problem is that class A relies on class B through interface I, Class C relies on class D through interface I, and if interface I is not the smallest interface for Class A and Class B, then Class B and Class D must implement methods that they do not need.

Solution: Split the bloated interface I into separate interfaces, and Class A and Class C are dependent on the interfaces they need. That is, the principle of interface isolation.

For example, the principle of interface isolation:

(Figure 1 design that does not follow the principle of interface isolation)

This figure means that class A relies on Method 1, Method 2, Method 3 in interface I, and Class B is the implementation of Class A dependency. Class C relies on Method 1, Method 4, Method 5 in interface I, and Class D is the implementation of Class C dependency. For Class B and Class D, although they all have methods that are not available (that is, the method of marking the red font in the figure), but because of the implementation of interface I, it is also necessary to implement these methods that are not available. Unfamiliar to the class diagram can be understood by reference to program code, the code is as follows:

Interface I {PublicvoidMethod1 ();PublicvoidMethod2 ();PublicvoidMethod3 ();PublicvoidMETHOD4 ();PublicvoidMethod5 (); } class a{PublicvoidDepend1 (i i) {i.method1 ();}PublicvoidDepend2 (i i) {i.method2 ();}PublicvoidDepend3 (i i) {i.method3 ();}} Class B implements i{PublicvoidMethod1 () {System.Out.println ("Class B method to implement Interface I1 "); }PublicvoidMethod2 () {System.Out.println ("Class B method to implement Interface I2 "); }PublicvoidMethod3 () {System.Out.println ("Class B method to implement Interface I3 "); }For Class B, method4 and METHOD5 are not required, but because of the two methods in interface A,So in the implementation process, even if the method body of the two methods is empty, these two methods are not useful to implement.PublicvoidMethod4 () {}PublicvoidMethod5 () {}} class c{PublicvoidDepend1 (i i) {i.method1 ();}PublicvoidDepend2 (i i) {i.method4 ();}PublicvoidDepend3 (i i) {i.method5 ();}} Class D implements i{PublicvoidMethod1 () {System.OUT.PRINTLN ("Class D method to implement interface I1 "); }For Class D, METHOD2 and method3 are not required, but because of the two methods in interface A,So in the implementation process, even if the method body of the two methods is empty, these two methods are not useful to implement.PublicvoidMethod2 () {}PublicvoidMethod3 () {}PublicvoidMETHOD4 () {System.OUT.PRINTLN ("Class D method to implement interface I4 "); } public void method5 () {System.< Span class= "Hljs-keyword" >out.println ("Class D implements the method of interface I 5");}} 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 ())}}           

As you can see, if the interface is too bloated, as long as the method appearing in the interface, regardless of the usefulness of the classes that depend on it, the implementation class must implement these methods, which is obviously not a good design. If the design is modified to conform to the interface isolation principle, the interface I must be split. Here we split the original interface I into three interfaces, split the design 2 as shown:

(Figure 2 follows the design of the interface isolation principle)

Routinely post code for a friend who is unfamiliar with class diagrams:

Interface I1 {PublicvoidMethod1 (); }Interface I2 {PublicvoidMethod2 ();PublicvoidMethod3 (); }Interface I3 {PublicvoidMETHOD4 ();PublicvoidMethod5 (); } class a{PublicvoidDepend1 (I1 i) {i.method1 ();}PublicvoidDepend2 (I2 i) {i.method2 ();}PublicvoidDepend3 (I2 i) {i.method3 ();}} Class B implements I1, i2{PublicvoidMethod1 () {System.Out.println ("Class B method to implement Interface I11 "); }PublicvoidMethod2 () {System.Out.println ("Class B method to implement Interface I22 "); }PublicvoidMethod3 () {System.Out.println ("Class B method to implement Interface I23 "); }} class c{PublicvoidDepend1 (I1 i) {i.method1 ();}Publicvoid depend2 (I3 i) {i.method4 ();} public void depend3 (I3 i) { I.method5 (); }} class D implements I1, i3{public void method1 () {system. OUT.PRINTLN ("Class D implements the method of interface I1 1");} public void method4 () {System.< Span class= "Hljs-keyword" >out.println ("Class D Implements interface I3 method 4");} public void method5 () {System.< Span class= "Hljs-keyword" >out.println ("Class D Implements interface I3 method 5");}}      

The meaning of the principle of interface isolation is: Establish a single interface, do not set up a huge bloated interface, as far as possible to refine the interface, the interface of the method as little as possible. That is, instead of trying to create a very large interface for all classes that depend on it, we need to create a dedicated interface for each class. In this example, the interface isolation principle is used to change a large interface to 3 dedicated interfaces. In programming, it is more flexible to rely on a few dedicated interfaces than to rely on an integrated interface. Interface is a design-time external set of "contract", through the decentralized definition of multiple interfaces, can prevent the proliferation of foreign changes, improve the system flexibility and maintainability.

Speaking of which, many people will feel that the interface isolation principle is similar to the previous single principle of responsibility, it is not. One is that the principle of single responsibility focuses on responsibility, while the interface isolation principle focuses on the isolation of interface dependencies. Second, the principle of single responsibility is mainly constrained class, the next is the interface and method, it is the implementation and details of the program, and the interface isolation principle mainly constrains the interface interface, mainly for the abstract, the overall framework of the program for the construction.

When using the interface isolation principle to constrain the interface, the following points should be noted:

1, the interface as small as possible, but to have a limit. The refinement of the interface can improve the design flexibility is not a fact, but if too small, it will result in an excessive number of interfaces, resulting in complex designs. So be sure to be modest.

2, to customize the service for the class that relies on the interface, exposes only to the calling class the method it requires, and the method it does not need is hidden. A minimal dependency can be established only by focusing on providing a customized service for a module.

3, improve cohesion, reduce external interaction. Enable the interface to do the most things with the least amount of method.

4, the use of interface isolation principle, must be moderate, the interface design too large or too small are not good. When designing interfaces, it is only when you spend more time thinking and planning that you can accurately practice this principle.

Design Pattern Six Principles (4): interface Isolation principle