Resolving ISP Violations

Yesterday we learned about SOLID’s Interface Segregation Principle (ISP). We examined an example where three use case classes, managing high-level business logic, were calling methods on a DataAccess class. 

Each of the use cases called different methods on DataAccess. ISP violations became apparent when a change in DataAccess for UseCase1 signified a recompiling and redeployment for the other two use cases, UseCase2 and UseCase3, even though they were not interested in this modification. Nonetheless, their dependency on DataAccess meant they were affected. This situation is not ideal.

Today we’ll be looking at a solution to our example ISP violation.

So, how could we fix this?

Is there some way in which we could isolate changes to DataAccess so that they only affect callers who are interested in them? 

Yes, there is. We could introduce small, segregated interfaces for each of the use case classes to only provide the methods on DataAccess that each use case needs.

Note: The open arrows mean ‘uses’ or ‘calls’ while the hollow arrows indicate an ‘implements’ relationship.

A new method on DataAccess for UseCase1 would also go into the IUseCase1DataAccess interface. At the same time, IUseCase2DataAccess and IUseCase3DataAccess remain unchanged as do UseCase2 and UseCase3 – we do not need to recompile them.

Nice. We have fixed the ISP violation.

ISP breaches at the architectural level are more problematic. Let’s explore those tomorrow as we wrap up our journey into the Interface Segregation Principle.