nterface egregation rinciple in C++ is the fourth & by far the simplest design principle of a series SOLID as a Rock design principles. The SOLID design principles focus on developing software that is easy to maintainable, reusable & extendable. In this article, we will see a code violating ISP, a solution to the same code, guideline & benefits of ISP. I S P By the way, If you haven’t gone through my previous articles on design principles, then below is the quick links: RP – Single Responsibility Principle S CP – Open/Closed Principle O SP – Liskov Substitution Principle L SP – Interface Segregation Principle I IP – Dependency Inversion Principle D The code snippets you see throughout this series of articles are simplified not sophisticated. So you often see me not using keywords like override, final, public(while inheritance) just to make code compact & consumable (most of the time) in single standard screen size. I also prefer struct instead of class just to save line by not writing “public:” sometimes and also miss , constructor, , prefix std::, deleting dynamic memory, intentionally. I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible rather than the standard way or using Jargons. virtual destructor copy constructor Note: If you stumbled here directly, then I would suggest you go through first, even if it is trivial. I believe it will encourage you to explore more on this topic. What is design pattern? All of this code you encounter in this series of articles are compiled using C++20(though I have used features up to C++17 in most cases). So if you don’t have access to the latest compiler you can use which has preinstalled boost library as well. Modern C++ https://wandbox.org/ Intent Clients should not be forced to depend on interfaces that they do not use. Interface Segregation Principle is very much related to the Single Responsibility Principle. What it really means is that you should always design your abstractions in such a way that the clients that are using the exposed methods do not have to get the whole pie instead. That imposing the clients with the burden of implementing methods that they don’t actually need. Motivation: Violating the Interface Segregation Principle = ; = ; = ;
}; IMachine { { } { } { }
}; IMachine { { } { } { }
}; ; struct Document { struct IMachine virtual void print (Document &doc) 0 virtual void fax (Document &doc) 0 virtual void scan (Document &doc) 0 : struct MultiFunctionPrinter // OK override void print (Document &doc) override void fax (Document &doc) override void scan (Document &doc) : struct Scanner // Not OK override void print (Document &doc) /* Blank */ override void fax (Document &doc) /* Blank */ override void scan (Document &doc) // Do scanning ... As you can see, as far as MultiFunctionPrinter was concerned it’s ok to implement print(), fax() & scan() methods enforced by IMachine interface. But what if you only need a Scanner or Printer, some dev still inherits IMachine & leave unnecessary methods blank or throw NotImplemented exception, either way, you are doing it wrong. Solution: Example of Interface Segregation Principle in C++ = ;
}; = ;
}; IPrinter { ;
}; IScanner { ;
}; IPrinter, IScanner { }; IMachine {
    IPrinter&   m_printer;
    IScanner&   m_scanner;

    Machine(IPrinter &p, IScanner &s) : printer{p}, scanner{s} { } { printer.print(doc); } { scanner.scan(doc); }
}; /* -------------------------------- Interfaces ----------------------------- */ { struct IPrinter virtual void print (Document &doc) 0 { struct IScanner virtual void scan (Document &doc) 0 /* ------------------------------------------------------------------------ */ : struct Printer override void print (Document &doc) : struct Scanner override void scan (Document &doc) : struct IMachine : struct Machine override void print (Document &doc) override void scan (Document &doc) This gives the flexibility for the clients to combine the abstractions as they may see fit and to provide implementations without unnecessary cargo. As explained in the . You should avoid classes & interfaces with multiple responsibilities. Because they change often and make your software hard to maintain. You should try to . Single Responsibility Principle split up the interface into multiple interfaces based on role Benefits => Faster Compilation If you have violated ISP i.e. stuffed methods together in the interface, and when method signature changes, you need to recompile all the derived classes. This is an important aspect for some compiled languages like which is well known for . While another way around is self explainable. C++ slow compilation => Re-usability also mentions that — lead to inadvertent coupling between classes. Thus, an experienced dev knows coupling is the bane of re-usability. Martin “fat interfaces” — interfaces with additional useless methods => Maintainability The much more universal ISP benefit is that by avoiding unneeded dependencies, the system becomes easier to understand; lighter to test; quicker to change. Similarly, to the reader of your code, it would be harder to get an idea of what your class does from the class declaration line. So, if dev sees only the one god-interface that may have inherited other interfaces it will likely not be obvious. Compare MyMachine : IMachine to MyMachine : IPrinter, IScanner, IFaxer The latter tells you a lot, the former makes you guess at best. Yardstick to Craft Interface Segregation Principle Friendly Software in C++ This principle comes naturally when you start decomposing your problem space by identifying major roles that take part in your domain. Hence, it’s never a mechanical action. Following a single question to your self may help you to rectify your design: Do I need all the methods on this interface I’m using? Closing Notes Even though big interfaces are a potential problem, the ISP isn’t about the size of interfaces. Rather, it’s about whether classes use the methods of the interfaces on which they depend. So ISP is poor guidance when designing software, but an excellent indicator of whether it’s healthy or not. Previously published at http://www.vishalchovatiya.com/interface-segregation-principle-in-cpp-solid-as-a-rock/

SOLID Design: Interface Segregation Principle in C++

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

7 Advanced C++ Concepts You Should Know

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

7 Advanced C++ Concepts You Should Know

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps