Interface Segregation Principle

This is the fifth in a series of (hopefully) amusing posts into Robert Martin’s SOLID principles. It’s written as a dialog between Socrates and a student named Loej in the spirit of the dialectic method popularized by Plato. In this post, the principle explored is the “The Interface Segregation Principle”. I hope you find this enjoyable.

Socrates, who is the narrator of the dialogue.

Loej, who is but a blink of data in the maelstrom of the Net.

Socrates: We have we made great progress in our understanding of the SOLID principles. So far we have discussed the Single Responsibility Principle, the Open/Closed Principle and the Liskov Substitution Principle. Do you recall what each of these mean?

Loej: Yes. The Single Responsibility Principle says that a software entity should have only a single responsibility. Robert Martin further clarified this to mean that a class should have only one reason to change.

**Socrates: **Nicely stated. And the Open/Closed principle?

Loej: Easy enough. Software entities should be open to extension and closed for modification.

Socrates: And the Liskov substitution principle?

Loej: The Liskov substitution principle…

Socrates: Yes?

Loej: It said something about sets and subsets.

Socrates; Right. But what did we infer from it?

Loej: Oh. A consumer of a base class should remain ignorant of its subclasses.

Socrates: Great. Did we get a bit more from it?

Loej: Right. It says that descendants shouldn’t dictate the behavior of their parents.

Socrates: And also?

Loej: A descendant should guarantee the behavior of its parents or it shouldn’t inherit from it.

Socrates: Precisely! Another way to state the entire thing is that the the preconditions of a derived class routine must be the same or weaker to the base class and the post conditions of a derived class routine must be the same or stronger than the base class.

Loej: Uh.. I’ll take your word on that one.

Socrates:Today we discuss the I in solid, the Interface Segregation principle.

Loej: Ok. What does that mean?

Socrates: The interface segregation principle says that clients should not be forced to depend upon interfaces that they do not use.

Loej: Well that seems straightforward enough to enforce.

Socrates: Well it is now and it’s so fundamental in .NET today thanks to Interfaces it is often an afterthought. But originally Robert Martin had to use multiple inheritance to support it.

Loej: How is that? I heard multiple inheritance is bad.

Socrates: C++ doesn’t have interfaces as a language feature, so if you want to support more than one abstract interface without mucking up your inheritance hierarchy, you need to use it.

Loej: And in Java and C# we use interfaces?

Socrates: Exactly. If we follow the advice to the letter, almost every client should have its own custom interface.

Loej: Well, the benefits seem obvious.

Socrates: There’s another benefit Robert Martin didn’t discuss. Let me ask you, how many things can you keep in your head at once?

Loej: 7 +/- 2. I’ve heard that statistic a number of places.

Socrates: What if I told you you could remember much more than 7 +/- 2?

Loej: How so?

Socrates: By a process cognitive scientists call “chunking”. Try to remember these letters. A, M, T, I, F, A, N, S, L, H, P, C…

Loej: I’m already lost. I told you, I can only do about seven letters.

Socrates: But what about these letters? AAPL, MSFT, INTC

Loej: Oh I recognize those. Those are the stock symbols for Apple, Microsoft, and Intel.

Socrates: Did you know the second group had the same exact letters as the first group?

Loej: Really?

Socrates: Indeed. But you remembered the second group much easier. Why is that?

Loej: Because they were put together into meaningful stock symbols. I recognize those.

Socrates: And the first?

Loej: A tangled mess of letters. But what does this have to do with this principle?

Socrates: When interfaces are more targeted, they chunk more naturally. Similar to how the Single responsibility principle focuses each software entity to a specific purpose, so the interface segregation principle focuses each interface to a specific purpose, typically one per client.

Loej: I see. Like grouping the letters into stock symbols. I can see the benefit . It’s much easier to deal with small simple things than large things.

Socrates: Yes. But for the record, of all the SOLID principles, I am most dubious of this one.

Loej: Didn’t you just spend the last five minutes convincing me of this principle? What gives?

Socrates: I believe this principle is slightly misguided. To split up large interfaces into small ones always will achieve looser coupling, but high cohesion is a different matter. There is no guarantee of high cohesion. For example. Are these groups of letters easier to grasp than the random letters? AMTI FANS LHPC.

Loej: Not really, no.

Socrates: And yet they have been segregated into groups of the same size – 4 each.

Loej: But if you are really dividing up an interface based on client needs it wouldn’t be so arbitrary.

Socrates: True, this is contrived. But why should client dependencies dictate your design any more than other aspects?

Loej: What do you mean?

Socrates: In a domain driven design, quality interfaces are a natural aspect of the system. To segregate interfaces by client technology without the domain driving the process seems unnecessarily technical.

Loej: I see.

Socrates: One more to go Loej! until next time!