Welcome to part four of the SOLID OOP design pattern series. You may wish to subscribe to the blog to stay tuned in as I post new issues in this series..
SOLID is not a language, it’s not a framework, it’s a set of principles to help guide your team to design better applications. Using these principles will help ensure your code is adaptive to change. In this series, I’ll be using C# for examples, but the same principles apply to any OOP language: Python, Java, C++, etc.. Using SOLID design principles does require a fundamental understanding of classes, interfaces, and class inheritance.
The fourth letter in SOLID stands for ISP: Interface Segregation Principle. This principle states, ““many client-specific interfaces are better than one general-purpose interface.” I have to confess, I kinda cheated by showing you this principle in my last post on the Liskov Substitution Principle. We used ISP to create a specific interface(IBallerPay.cs) for special employees with offshore accounts, fixing our LSP violation.
ISP helps prevent fat interfaces, aka Interface Bloat. This isn’t Lord of the Rings style programming here, we don’t create one interface to rule them all. Dare to do so and I can’t promise Nazgul won’t come and find you while you sleep. So why does it matter if we stick methods and contracts inside interfaces we deem worthy?
Imagine if we created an interface implementing unnecessary methods to all of our subclass. We’d be introducing unnecessary code, since every subtype would have to implement or override these methods whether or not they needed them. At the same time, we’d ensure any changes to our “God” interface would require changes to every inheriting class. On the other hand, if we create specific interfaces then we eliminate unnecessary code, keeping code clean and maintainable. When creating our interfaces, we must ask ourselves if every subtype will need to implement the defined properties and methods.
Next we’ll wrap up our SOLID principles with DIP: Dependency Inversion Principle