TDD and the SOLID principles (Part 2: SRP)

August 26, 2011

Table of contents:

Part1 – Indrocution

Part 2 – SRP (this post)

Part 3 – OCP

Part 4 – LSP

Part 5 – ISP

Part 6 – DIP

Part 7 – Conclusion


In the previous post I introduced the SOLID principles and their relation to TDD in general. And as promised, I’m diving into each of these principles and explain their relationships with TDD.

The first principle, which I’ll be talking about in this post, is the Single Responsibility Principle or SRP in short.

SRP is the principle that is easiest to understand, but not as easy to get right. In short, as its name implies, it means that a class should have only one responsibility, and not intermix responsibilities that are separable. It implies that classes should be kept as simple as possible, and anything that is not part of the class’s main responsibility should be the responsibility of some other class. In fact, this principle applies even more to interfaces than to classes. SRP implies cohesion and lack of coupling.

SRP can bee looked at as the basic principle that the rest of the principles (mainly OCP) only clarify for more specific circumstances.

Sometimes when you’re looking at a class it’s very clear that it violates the SRP. But often the line is not so clear, and only when the code evolves and you’re refactoring, then you notice the multiple responsibilities. Clearly TDD provides you with the safety net of tests while you’re refactoring your code. But it’s not the only way that TDD helps you adhere to the Single Responsibility Principle. If your class annexes additional responsibilities, your tests become complex and cumbersome. But in TDD, because you strive to write the simplest tests first then you’re more likely to write the tests for a new class in the first place rather than a complex test for an existing one.

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>


one comment

  1. AndreasJuly 28, 2012 ב 5:01

    Impressed with the series so far but one thhguot did come to mind in this episode regarding the data model you are using between client and server.Instead of two lists, surely it would be better to just manage one serverid and one clientid per record (or associated id if a record is shared by more than one client)That way the client knows what records to send to the server by those with no server id, and the client can also request from the server those records with no client id (created on server only)Obviously both client and server (poss just server) would still need some dedupe logic to merge records where a record was created on both client and server prior to synch.On another note, instead of batching updates to the server from the client, might be better to just have a queue and keep updates singular to keep it singleRgds@ddreaper