Architecture And The ISP

Today we are concluding our explorations of the Interface Segregation Principle (ISP). When we started on this journey, we discovered that depending on methods we don’t call can cause trouble. However, the Interface Segregation Principle announces the solution with its name – isolate and split up a dependency into multiple small, segregated interfaces. You can find the previous articles here and here.

However, the ISP not only applies to source code dependencies. It operates at an architectural level too.

Imagine we have a system S using a framework F. In turn, F references another framework, X.

Assume that there are some features of X that F does not use. System S, via framework F, is dependent on all code in X, whether called by F or not. 

Now, the developers of X have made modifications to their code. They’ve changed a feature that is not being called by F (and therefore S). Unfortunately, they have also introduced a bug that is destabilising X. That could have the potential to cause problems in S. S could become unstable and crash due to changes in X that it is not interested in. 

Upshots:

• In .NET projects, only reference assemblies you need – nothing more. 
• Be wary of third-party frameworks. Any modifications to these may harm your system.