00:00 In the previous lesson, I covered the Liskov substitution principle. In this lesson, I’ll be talking about interface segregation. The interface segregation principle states clients should not be forced to depend upon methods that they do not use. Interfaces belong to clients, not to hierarchies. In this case, they’re using the term client to mean classes and interfaces for the members you access on the class and its object. Essentially, if a class, especially a subclass, doesn’t use something, that something should probably be in a different class.
It defines three abstract methods: one for printing, one for faxing, and one for scanning. Yep, this is based on the real-world example from Uncle Bob’s paper that I mentioned earlier. In my first implementation, the
OldPrinter is a
Printer, and it overrides the
.print() method to print black and white. The
OldPrinter doesn’t support faxing or scanning, but as the
Printer is an abstract base class, I can’t just not implement those methods, so instead it implements them and raises a
02:02 This is a good case for mixins, those special kinds of classes that don’t have attributes discussed in part two of this course. The abstract printer still exists, but the only interface it declares is printing, which is appropriate for a printer.
02:35 And as the mixins implement the scanning and faxing functionality, this class is shorter, only having to override the one method. As the principle’s name implies, what you’re trying to do is segregate the interfaces into appropriate parts.
02:53 Generally speaking, the bigger the class, the wider its purpose (sometimes called fat classes). The wider its purpose, the harder it is to maintain. It becomes more difficult to find the right code and more likely that the different parts interleave, creating conditionals and edge cases. Instead, try to favor smaller, more specialized classes. And using mixins can help you with this instead of having a large number of abstract base classes.
Become a Member to join the conversation.