SOLID – Interface Segregation Principle
This is the fourth newsletter in the series covering the topic of the SOLID Object Oriented Principles for software development. Unlike the other principles we have covered up to this point, Single Responsibility, Open/Closed, and Liskov Substitution, the Interface Segregation Principle is less transferable to languages that are not object oriented.
If I were to summarize the principle into one sentence it would be, “it is better to have more tightly defined interfaces rather than fewer comprehensive interfaces.”
Like everything in the SOLID principles, this principle can be taken to extremes. It is possible to have a huge number of interfaces and classes as a result of segregation. Common sense needs to be taken into account. A rule of thumb might be, if you can foresee a realistic potential for the need to separate an interface into smaller interfaces because the interface contains features that do not apply to all implementations, then it makes sense to break it out.
This is where refactoring comes into play. Perhaps your interface was too general when you started out. That doesn’t mean you can’t break the interface out into smaller more granular interfaces at a later date. It just takes more work; especially if you don’t have automated unit tests to prove your refactoring work hasn’t broken your business requirements.
The key is how well you can predict the future. Segregate if you know the potential for future separation is probable.
We all know you can’t future proof code.
Reader Comments:
Sean:
I’m enjoying your series on SOLID development practices. But for some reason I didn’t receive today’s newsletter.
Editor:
If you miss a newsletter in your inbox or you want to look for past Newsletters, the contents are available at http://bitonthewire.wpengine.com/nlarchive.aspx. Today’s editorial will be presented. Also, there is a search box you can enter keywords and locate previous content.
Chike:
I can see how this is useful for a re-engineering dissertation that I’ll be commencing at some point this year.
I shall be following keenly and keeping the articles archived.
Kevin:
Very good article. You note that these substitution principles do not directly apply to SQL but do conceptually apply. I definitely agree with this concept.
When I develop stored procedures for a specific application I always start with a theme of re-usability; what tool set can I develop for this project ( or what tools can I borrow from the last project) which will prevent duplication of code. I suppose this is almost a bottom up approach where the bottom layer is very generic and the top layer – interface layer – is very specific. I think too many times database systems are written before they are designed resulting in redundant, non- re-useable code which is not readily extensible and expensive to maintain.
Have you been able to apply these principles to your SQL work? Do you have techniques making your database code more manageable? Perhaps you’re finding these principles helpful writing web applications using patterns such as MVC, or MVVM. Maybe you are even getting one of those aha moments as these principles expose why those patterns work in a certain fashion? Share your experience with us by writing to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
How to Manage Without Micromanaging (Part 1)
Project or team management isn’t about controlling the project or group. It’s about managing the inevitable changes that naturally occur with ease and confidence. This series introduces a different way to approach the natural flow of project events. These articles changes one’s mindset to more “commanding” the essence of the desired outcome versus controlling every step in the journey.
Featured White Paper(s)
Top 10 Tips for Optimizing SQL Server Performance
read more)