The Interface Segregation Principle is derived from two more specific rules of OO design - Few Interfaces and Small Interfaces. It can be summed up as "Favour many client specific interfaces over one general purpose interface". An interface is the part of a module (class) which is available for other modules to access (so its public parts).

By the sound of it, Few Interfaces sounds like it's in contradiction to the above summation ("Favour many client interfaces ..."), but it's not. Few Interfaces actually refers to the dependencies between interfaces, and states that every interface should communicate with as few others as possible. There are several benefits to this.

The first is concerned with composibility and decomposibility. If you want to compose a system from already existing modules, it is best that these modules do not rely too much on other modules (the much-championed code reuse OOP always promised).

The second is concerned with understandibility - a module which does not depend on the features of other modules is more self-contained and therefore easier to understand.

The third is concerned with stability - a module which does not depend on too many other modules is not as likely to cease working due to changes in other modules. Errors will not propagate as far from their source.

The Small Interfaces part of the principle is related to the above. It states that when modules communicate, they should exchange as little information as possible. This helps minimise the negative effects mentioned above by encouraging modules to be as self-contained as possible.

And so, we finally arrive at the Interface Segregation Principle. If we favour specialised interfaces over more general ones, then we encourage modules to be small and have few dependencies. A general, large module would have to communicate with a lot more modules because it has a less specific task to accomplish, and it would have to exchange a lot more information.

Log in or register to write something here or to contact authors.