Interface Segregation

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.

00:38 Let me show you an example using code.

00:43 Consider a Printer abstract class and its two implementations, the OldPrinter and the ModernPrinter. Printer inherits abstract base class to signal that it’s a partial implementation.

00:56 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 NotImplementedError.

01:31 Let me scroll down to look at the ModernPrinter.

01:36 This one also implements Printer, this time printing in color, but unlike the old one, the ModernPrinter supports faxing and scanning.

01:46 The OldPrinter is in clear violation of the interface segregation principle. It is forced to implement things it doesn’t use. Let’s see how this could be done better.

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:18 Then faxing and scanning are built using mixins. The OldPrinter extends Printer, still overriding the .print() method, while the ModernPrinter does that as well as incorporating the mixins.

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.

03:23 You’re four letters into SOLID. The last principle is up next.