Clients of Interfaces should not be forced
to Implement Interface Contracts
they do not require

ISP Abstract:

An Interface creates a “Behaves Like” inheritance relationship rather than an “Is A” relationship as with Class inheritance.

An Interface Defines a Contract

… Between the Implementing Class or Strut

The implementing software entity is required to implement the signatures of Properties, Methods, Indexers and Events within the Interface.

If an Interface has signatures that are not required for the Responsibility of a Class implementation then a “Not Implemented Exception” statement must reside in the consuming class in order for the contract to be fulfilled.

This violates ISP by forcing a class to create implementations that it does not require just to comply with the Interface contract.

 DESCRIPTION:

We use Interfaces to define abstractions, the signatures without implementations. We can then design to the “What” of a type and leave the “How” up to the implementing Class or Strut.

This is very powerful as we can define a collection of similar State and Behavior responsibility objects through a single Interface reference. The type can be swapped out at run-time.

If an interface defines a contract that has multiple responsibilities the ability to design to a single purpose abstraction is lost.

We can no longer define a collection of related objects to be managed at run time.

Dependency Inversion and Inversion of Control containers can no longer define interchangeable types.

When an Interface is discovered that violates ISP we should segregate the signatures into common State and Behaviors.

The legacy consuming classes and struts can then string a collection of Interfaces together to comply with the original contractual requirements. This will prevent regressive testing problems.

This segregation allows the Developer to create New Classes or Struts that only implement the responsibility that the new segregated interface has defined.

The new class will now comply with the Single Responsibility Principle (SRP) a well.

These actions will prevent the Developer from being part of the problem by adding other responsibilities to an already SRP violated Software Entity.