TDD and the SOLID principles (Part 5 – ISP)

October 1, 2011

This is the 5th post in the series about TDD and its relationships with the SOLID principles. Here are the links to the previous parts:

Pat 1 – introduction

Part 2 – SRP

Part 3 – OCP

Part 4 – LSP

Part 5 – ISP (this post)

Part 6 – DIP

Part 7 – Conclusion

ISP – Interface Segregation Principle

“Make fine grained interfaces that are client specific”

This principle speaks for itself… but anyway I’ll “translate” it… Smile:

It is better to create many small interfaces than few big ones. Each interface should have very specific purpose. When some clients of your class need to access only part of what you supply, and another set of clients uses another part, then these sets of clients need different interfaces. This also makes it possible to split the class into few other single-responsibility classes in the future, if so needed.

Take for example a Pipe (or a message queue). Some clients only need to send stuff through it while others only need to receive. These clients need different interfaces.

In addition, when you add functionality to your class (or better, create a derived class), that only part of your clients need, then the new functionality should be exposed through a new interface (that possibly extends the old one), rather than adding it directly to the old interface. This way, clients that are already working correctly with the old interface doesn’t have to change or recompile.

ISP and TDD

This principle is one that comes very nicely with TDD: When you write a test for a client of your class that needs only one aspect of its functionality, you’ll need to mock only the interface that interests you and not a big interface that has many things that are not of interest to your test. Unfortunately, this is not exactly the case when you’re using a mocking framework (like Moles, Moq, RhinoMocks, etc), because the mocking framework saves you the redundant work, and so it makes it less obvious that you’re doing something wrong. This is why I advise people that are new to TDD, to try not to use a mocking framework in the beginning, and only use it once they feel confident enough with TDD, so that they are able to notice these smells even through the mocking framework “deodorizer”…

TDD also makes you think from the client perspective, making the different clients needs more obvious, which also leads you to use simpler, more client focused interfaces.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*