Agile Software Development –isp Interface Isolation principle

If the interface of a class is not cohesive, it means that the class has a "fat" interface. In other words, the "fat" interface of a class can be decomposed into multiple sets of methods. Each group of methods serves a different set of client programs.

The ISP acknowledges that some objects do need to have non-cohesive interfaces, but ISPs recommend that the client program should not see them as a single class presence. Instead, the client program should see more than one abstract base class with a cohesive interface.

Interface pollution

Consider a security system. In this system, there are some door objects that can be locked and unlocked, and the door object knows whether it is open or closed. This door is encoded into an interface so that the client can use objects that conform to the door interface without having to rely on a specific implementation of door.

 Public Interface door{    void  Lock ();     void Unlock ();     BOOL Isdooropen ();}

Now, consider a realization like this, timeddoor, if the door is open for too long, it will sound an alarm. To achieve this, the Timeddoor object needs to interact with another object called a timer.

 Public class timer{    publicvoid Register (int  timeout,timerclient client)    {}}  Publicinterface  timerclient{    void  TimeOut ();

If an object wants to get a timeout notification, it can call the timer's register function. The function has two parameters, one is the timeout time and the other is a reference to the Timerclient object, and its timeout function is called when the supermarket arrives.

How to connect the Timerclient class and the Timeddoor class, in order to notify the Timeddoor the corresponding processing code in the timeout?

The common solution is that door inherits the Timerclient, so Timeddoor inherits the Timeclient. This ensures that timerclient can register itself in a timer and receive a timeout message.

The problem with this approach is that door now relies on timerclient. But not all types of door require timed functions. In fact, the initial door abstract class and timing function have nothing to do with it. If you create a derived class of door that does not require a timing feature, you must provide a degenerate implementation of the timeout method in these derived classes, which may violate the ISP. In addition, applications that use these derived classes do not use the definition of the Timerclient class in time and must also be introduced. This has the unnecessary complexity and unnecessary repetition of the odor.

Separating the customer is separating the interface

The door interface and the Timerclient interface are used by completely different client programs. The timer uses timerclient, while the class that operates the gate uses door. Since the client program is separate, the interface should also remain separate.

　　Client programs should not be forced to rely on methods that are not used.

If the client program is forced to rely on methods that they do not use, then these client programs face changes due to changes in these unused methods. This inadvertently results in a coupling between all client programs. In other words, if a client program relies on a class that contains a method that it does not use, but other clients actually want to use the method, the client program is affected when other customers ask for the class to change. We want to avoid this coupling as much as possible, so we want to detach the interface.

class interface and Object interface

Think again about Timeddoor. It has two independent interfaces and is used by two independent customer-timer and door users. So implementing both interfaces requires manipulating the same data, so the two interfaces must be implemented in the same object. So how do you follow an ISP? How can we separate the interfaces that must be implemented together?

That is, the client of an object does not have to access it through the interface of the object, or it can be accessed through a delegate or through the base class of the object.

Detaching an interface through a delegate (adapter)

One solution is to create an object that derives from Timerclient and pass a request for that object to Timeddoor.

When Timeddoor wants to register a timeout request with the Timer object, it creates a doortimeradapter and registers it with the timer. When the timer object sends a timeout message to Doortimeradapter, Doortimeradapter passes the message to Timeddoor.

This solution follows the ISP principle and avoids the coupling between the door client program and the timer. Even if the timer is changed, it will not affect any door users. In addition Timeddoor does not have to have the same interface as Timerclient. Doortimeradapter converts the Timerclient interface to the Timeddoor interface. Therefore, this is a common solution.

However, the solution is somewhat less elegant. Every time you want to register a time-out request, you are going to create a new object. At the same time, the type conversion will invert some small but still existing run time and memory overhead.

Separating interfaces with multiple inheritance

In this model, Timeddoor inherits both door and Timerclient. Although both base class client programs can use Timeddoor, they are virtually no longer dependent on Timeddoor. This allows them to use the same object through the detached interface.

This solution is always preferred.

Conclusion

Fat classes can cause unhealthy and harmful coupling relationships between their client programs. When a client program asks for a change to the Fat class, it affects all other client programs. Therefore, client programs should rely solely on the methods they actually invoke. This can be achieved by decomposing the fat-like interface into multiple client-specific interfaces. Each client-specific interface declares only those functions that are called by its specific client or client group. The Fat class can then inherit all the client-specific interfaces and implement them. This relieves the dependencies between the client program and the methods that they do not call, and makes the client program independent of each other.

Excerpt from: [Mei]robertc.martin, Micahmartin, Aaron, Sun Yu translation Agile Software Development principles, patterns and practices (C # revision) [M], People's post and Telecommunications publishing house, 2013, 115-121,

Agile Software Development –isp Interface Isolation principle