Interface separation principle of OOD design principles (ISP)

The interface segregation principle is Robert C. Martin (!) The fourth article (original) of engineering notebook, a column written in C ++ reporter in 1996, describes how to deal with the troubles caused by interface "bloated. This principle has only one sentence in summary: clients shocould not be forced to depend upon methods that they do not use. Customers should not be forced to rely on methods they do not need.

The popular ISP statement is generally as follows: it is better to use multiple special interfaces than to use a single total interface; from the perspective of a customer class, the dependence of a class on another class should be based on the smallest interface. This is all a meaning.

The following figure shows the relationship:

[Note] the customer class only lists the methods it actually implements. In fact, many languages require that all the Virtual Methods of the parent class be implemented in the subclass in the inheritance relationship, unless this method is in the parent class and provides the default implementation method.

The interface baseinterface defines five methods. Three customers depend on this interface. Consumera only depends on the A1 () and A2 () Methods of baseinterface; consumerb only depends on the B1 () and B2 () Methods of baseinterface; consumerc only depends on baseinterface C1 (). This is a typical design that violates the ISP principles. What are the problems with this design? Suppose that the definition of the A1 () method needs to be changed, or consumera requires that the A3 () method be added. What is the result? Obviously, because this change requires the modification of baseinterface, all customers dependent on baseinterface (consumera/B/c) will be affected (re-compile, deploy, test, etc )! Consmerb and consumerc are not very jealous?

Let's review: how is this interface designed? One case is that the interface functions or responsibilities are not taken into account during the design. One brain lists all possible methods, and the other is more common: at the beginning, only one customer consumera needs two methods A1 (). A2 () then, according to the abstract-oriented requirements, an interface baseinferface is abstracted. There are two other methods. Later, a new customer called consumerb proposed a new method that required B1 () and B2 (). Therefore, the two were added to baseinferface. This process continues. As we accumulate step by step, baseinterface becomes increasingly bloated.

The correct design should be to split the interface. The sharding principle can be used to group methods according to the requirements of SRP according to their responsibilities and functions. Each method is abstracted into an interface, and each customer only depends on a specific interface, such:

At this time, if interfacea is modified and the new method A3 () is added, you only need to modify consumera. Other customers will not be affected!