This article will present the Interface Segregation Principle (ISP). Along with the introduction of this topic, examples from MechLynx project will be used (https://github.com/CharlieGearsTech/MechLynx)

SOLID principles were introduced by Robert C. Martin around 2000. These principles are “guidelines”, they are not rules due that the application of these principles for certain software systems will not be feasible or recommended in some cases. The goal of these principles is to create reusable software modules that are able to tolerate changes over time and are easy to understand.

ISP recommends making a fine grained interface for client specific features to prevent these features to changes of one set of source code and thereby force the recompilation and redeployment of other source code that does not need these features changes. This applies for statically typed languages (C++, Java,…). ISP does not apply to dynamically typed languages (Python, PHP, Ruby, ect) since these languages resolve dependencies at runtime and they don’t require to create header declarations (import #include,…).

ISP prevents the damage of depending on modules that contain features that you don’t require, for example, MechLynx has a conclusion widget which responsibility is to enlist the different diagnostics that the system inferred based on the user input. To set a conclusion uses this interface:

But the system has different conclusion types, such as, Transmission conclusion, Engine conclusion or Brakes conclusion, then all these SW entities will use setItem().

 

Certainly the conclusion_setter class is doing only one thing: set conclusions but the principal problem with this approach is that if any of these conclusions want to change, the logic for all of them can be affected. If Engine Conclusion, instead of uploading an icon, requires to follow a hyperlink, then this change is not required by the other Conclusions types but they will be chained to be compiled and be deployed with a feature that they don’t use.

A better approach is to “segregate” the customized features for each conclusion type to be allocated to a personalized interface, later to allocate the main processing to the class Conclusion_setter. By this way, this design complies with ISP:

Leave a Reply

Your email address will not be published.