5. Inferface Segregation Principle (ISP)

Question 1

What does ISP state?

Answer 1

That clients should not be forced to depend on methods they do not use.

Question 2

What kind of interfaces should we prefer according to ISP?

Answer 2

We should prefer small, cohesive interfaces to large, “fat” ones.

Question 3

What is the interface of a type in the context of ISP?

Answer 3

Whatever can be accessed by client code with an instance of that type.

Question 4

What is a client in the context of ISP?

Answer 4

The code that is interacting with an instance of an interface. It’s the calling code.

Question 5

What does violating ISP results in?

Answer 5

It results in classes that depend on things they don’t need. This increases coupling and makes it harder to change or swap out individual implementations because the number of clients that might break is much larger.

Question 6

What does having more dependencies than needed cause?

Answer 6

1. More coupling
2. More brittle code
3. More difficult testing
4. More difficult deployments

Question 7

What are the three common indicators that ISP is being violated?

Answer 7

1. Large interfaces
2. NotImplementedException
3. Code that uses only a subset of a larger interface

Question 8

What can we do to implement ISP when dealing with a large legacy interface that violates it?

Answer 8

We can break it into smaller interfaces, and then at places where an error is occurring, we can implement the pieces of the now broken interface.

Question 9

How does violating ISP negatively impact compliance with LSP?

Answer 9

Large interfaces are harder to fully implement, and thus, more likely to only be partially implemented, and therefore, to not be substitutable for their base type.

Question 10

How does ISP relate to cohesion?

Answer 10

The Interface Segregation principle relies heavily on cohesion — small, cohesive interfaces are preferable to large interfaces whose methods are only loosely related to one another.

Question 11

How does ISP relate to PDD?

Answer 11

You shouldn’t break up interfaces just to satisfy the principle but rather use the principle to help identify the source of some pain you’re experiencing with the codebase.

Question 12

What is a potential drawback of not following PDD when implementing ISP?

Answer 12

If you try to preemptively follow ISP everywhere, you could end up with a bunch of single-method interfaces that are much more difficult to use, group together, and understand than a few cohesive interfaces.

Question 13

Once identified, how should we fix ISP violations?

Answer 13

1. For interfaces you control:
   Break up the interfaces into smaller ones — if the original interface is still being used, you can compose it from smaller ones for backward compatibility.
2. For interfaces you don’t control:
   Create small, cohesive interfaces that follow the adapter design pattern — your code should work with the adapter interface that you control and it, in turn, can work with the original large interface where only the adapter knows about the underlying large interface.
3. Generally:
   It’s easy to follow ISP if you let client code define interfaces the code will work with. In fact, it’s impossible to violate ISP in this case.

Question 14

How can we identify how exactly to implement ISP on a large interface?

Answer 14

By looking at a place where the interface is being used, identifying which parts of the interface it uses, and then, if a given part is another interface or method, diving in and seeing what individual parts of that are being used.

Question 15

What are the key takeaways of this module?

Answer 15

1. Prefer small, cohesive interfaces to large, expensive ones
2. Following ISP helps with SRP and LSP
3. Break up large interfaces by using
   a. Interface inheritance
   b. Adapter design pattern