Confusion on Single Responsibility Principle (SRP) with modem example?

Question

I am currently reading through Robert Martins book "Agile Software Development" book and I am struggling to see how his modem example provides any benefit.

He says that he has an interface that violates the SRP

interface Modem 
{
  public void dial(String pno);
  public void hangup();
  public void send(char c);
  public char recv();
}

So he decides to break it up so that the Modem Implementation relies on a Connection interface and Data channel Interface. However then when Modem implements Connection and Data Channel Interfaces, his class Modem must still implement the methods individually!

To me, this doesn't seem right. I believe I may have a misunderstanding and hoping someone can point me where I'm wrong. Here is my implementation in Scala that represents my understanding.

I hope someone may be able to point me to where I'm wrong. Note In Scala a Trait is similar to an in an interface. For all intents of this example please assume that the Trait is just another word for "Interface" and that the return type "Unit" is the same as "Void".

trait IDataChannel {

  def send(message: String)
  def receive(): String

}

trait IConnection {

  def dial(number: String)
  def hangup()

}

trait IModem extends IConnection with IDataChannel{}

class ModemImpl extends IModem {

  def hangup(): Unit = {}

  def receive() = { "hi" }

  def send(message: String): Unit = {}

  def dial(number: String): Unit = {}

}

Answer 1

I can see why you are confused as his writing presumes a little more design savviness on the part of the reader, and so is a little handwavy.

Responsibilities are dependent on the domain and on how software evolves ("reason to change", not as imagined solely by the developer, but as established (possibly over time) by business needs - by the outside forces that drive changes in the codebase). To create maintainable code, you (and your team) have to figure these out and structure your software over time to support those kinds of changes. (Note that initially, doing design doesn't pay off in an obvious way, which is why it's not easy for less experienced developers to see its utility; on top of that there is risk of "overdesign". But later on, if you don't consider it, you get in trouble.)

So he starts with the assumption that it has somehow been established that connection management and data communication are two distinct responsibilities - in the sense that when you look at the change requests they generally don't change together.

Then he talks about the responsibilities of the interface itself - which you could read as different reasons for the interface to change. This is of interest, because, even though it has no implementation, it's a static peace of code that other code depends on. One of the major concerns in design is controlling the directions and the structure of dependencies, because changes propagate backwards along dependency arrows (which is why DIP is a technique to stop that propagation - it reverses the arrow at some point).

He doesn't say much about how separating the interface allows you to achieve (or rather, increase) independent evolvability of the client code that calls the two interfaces. But if I had to fill in the blanks: this relies on the discipline and design knowledge of the developers, in the sense that they can now, in client code, leverage this to separate the "orchestration" of these calls (the "orchestration", the logic of what is called and when - being the responsibility of the clients). This may be as simple as two different client classes, or something more involved, where the clients reside in separate DLLs. On top of that, clients do not know if the interface is implemented by a single class, or two separate classes, or a whole subsystem. So that gives you flexibility to change the implementation behind the interface.

He also says, and this is important, if these two don't change separately (either because they don't change at all, or because their changes are strongly correlated), you shouldn't apply SRP or ISP just for the sake of it.

An axis of change is an axis of change only if the changes occur. It is not wise to apply SRP or any other principle, for that matter if there is no symptom.

So, you don't do design once - yes, you come up with something initially, but you develop it and reconsider it over time.

As for the SRP violation in the implementation - in the paragraph just below the text you've read so far, he acknowledges that, and writes:

Note that [...] I kept both responsibilities coupled in the ModemImplementation class. This is not desirable, but it may be necessary. There are often reasons, having to do with the details of the hardware or operating system, that force us to couple things that we'd rather not couple. However, by separating their interfaces, we have decoupled the concepts as far as the rest of the application is concerned.

We may view the ModemImplementation class as a kludge or a wart; however, note that all dependencies flow away from it. Nobody needs to depend on this class. Nobody except main needs to know that it exists. Thus, we've put the ugly bit behind a fence. Its ugliness need not leak out and pollute the rest of the application.

So there's a fair bit of depth to it - understanding the domain, understanding practical considerations, understanding trade-offs, etc.

Answer 2

SRP actually stands for Single Responsibility Principle. Mr. Martin is correct that the Modem interface violates SRP. You are correct that ModemImpl violates SRP. Neither separate the Connection and Data responsibilities. Mr. Martin was fixing the interface. He has not fixed the Modem class. One thing to understand about these principles is that they can be applied in stages as you make the code better.

Usually when SRP is focused on interfaces the Interface Segregation Principle is mentioned. When this is followed the rest of the system neither knows nor cares how messed up your implementation class is, so long as it can be used the way it needs to use it.

Now that the interface is fixed, and presumably the code that uses it, the implementation can be fixed painlessly, or it can be ignored while you work on more important things secure in the knowledge that at least this SRP violation isn't spreading around the code base.

To understand that better imagine what the using code might be. When data comes in it will need to wait if there is no connection. If data cannot be sent immediately it must be buffered or discarded. This couples the act of sending data to the connection state. If you have access to all four methods it's very temping to go ahead and manage all that.

However, if all you want to think about is sending and receiving it's very nice to focus on the Data interface and let the connection issue be something elses problem.

UDP is perfectly happy sending sending packets into oblivion. It doesn't care if they get there or not. If you're doing something like this why would you even want access to those other methods? If being sure that the modem is connected is something elses job don't make it look like we have to deal with it or some ambitious bug hunter will mistakenly think they have to deal with it and now the SRP violation is spreading in the code base. Don't make me think about things I don't need to think about.

Answer 3

SRP is about reason for change, and people.

1. The network guy is responsible for going in and writing the connection related code, and provide you basics for how to send packets (e.g. read4bytes and write4bytes)
2. The application logic guy is responsible for going in and providing higher-level semantics like send and receive.

problem

trait IModem extends IConnection with IDataChannel{}

You wouldn't do that, as this IModem violates SRP. Your ModemImpl class would just consume those traits.

So he decides to break it up so that the Modem Implementation relies on a Connection interface and Data channel Interface. However then when Modem implements Connection and Data Channel Interfaces, his class Modem must still implement the methods individually!

Traits / Interfaces are what other parts of the software consume, so the interfaces are okay wrt. SRP. The implementation is up you, and you hide those details from the other parts of the system. SRP does not do away with coupling, and you need to resolve that in the implementation, but conceptually the traits are clean.