\n\nRepost of https://dev.to/rhuzaifa/is-it-practical-to-use-interface-segregation-principle-3ojl
\n
SOLID is a very popular design concept in programming. Interface Segregation is part of SOLID Design. You may ask, what is SOLID?
\n\n\nSOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.
\n
In code, you have best-practices and rules. SOLID designs are like best-practices.
\nIt says
\n\n\nClients Should Not Be Forced To Depend Upon Interfaces That They Do Not Use.
\n
Pretty straightforward.
\n✔️ Create smaller and specific interfaces (role interfaces).
\n❌ Classes can implement interfaces they don’t use.
Consider
\n\n\nA client depends upon a class that contains interfaces the client does not use, but other clients do use, then the first client will be affected by the changes other clients force upon the class used by the first client.
\n
The Goal of this principle is to avoid these situations.
\nThe pattern for other SOLID principles like Single Responsibility and Open Close is much similar : To avoid code breakages in the long run.
\nUsing the Bird example much similar to that discussed in Liskov Substitution.
\ninterface Bird {\n fly(): void;\n walk(): void;\n}\n\nclass Duck extends Bird{\n\tfly(){\n\t\t// Duck can fly\n\t}\t\n\twalk(){\n\t\t// Duck can walk\n\t}\n}\n\nclass Ostrich extends Bird{\n\tfly(){\n\t\t// Ostrich cant fly... throw some error\n\t}\t\n\twalk(){\n\t\t// Ostrich can walk\n\t}\n} Here fly() is enforced to an Ostrich class by the Duck class, since both implement the same interface and Duck does use fly(). It is a clear violation of the Interface Segregation Principle.
Using the Interface Segregation Principle we refactor our code to be
\ninterface BirdFly{\n\tfly(): void;\n}\n\ninterface BirdWalk{\n\twalk(): void;\n}\n\nclass Duck extends BirdFly, BirdWalk{\n\tfly(){\n\t\t// Duck can fly\n\t}\t\n\twalk(){\n\t\t// Duck can walk\n\t}\n}\n\nclass Ostrich extends BirdWalk{\n\twalk(){\n\t\t// Ostrich can walk\n\t}\n} We have now made role-specific interfaces and there is no inadvertent coupling.
\nDefinitely, It is best to follow this principle whenever possible. However, if your requirements are satisfied and you can work around the inadvertent coupling, then sure you can avoid this principle.
\nDo you use Interface Segregation? Be sure to tell me your opinion in the comments.
\nWhy The Dependency Inversion Principle Is Worth Using.
","frontmatter":{"title":"Is It Practical To Use Interface Segregation Principle?","date":"March 31, 2021","description":"Explore the Interface Segregation Principle of SOLID design, which advocates for creating specific interfaces to prevent clients from depending on methods they do not use."}}},"pageContext":{"slug":"/blog/is-it-practical-to-use-interface-segregation-principle/","previous":{"fields":{"slug":"/blog/2-simple-tips-to-clean-nested-if-else-conditions/"},"frontmatter":{"title":"2 Simple Tips To Clean Nested IF/ELSE Conditions."}},"next":{"fields":{"slug":"/blog/why-the-dependency-inversion-principle-is-worth-using/"},"frontmatter":{"title":"Why The Dependency Inversion Principle Is Worth Using"}}}},"staticQueryHashes":["2276319502"]}