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!

enter image description here

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 = {}

  • 1
    What doesn't seem right? Your ModemImpl class does indeed implement the methods individually.
    – Kache
    Mar 3, 2019 at 16:36
  • Exactly. So, therefore, this still violates the SRP. ModemImpl still has more than "one reason to change".
    – alex
    Mar 3, 2019 at 16:42
  • Please post the code with Martins fix. We shouldn't need the book handy to help you. Mar 3, 2019 at 17:15
  • There is no code from his fix he just drew a UML diagram as his solution that pointed the Modem class to IConnection and IDataChannel. See the edit to my post I put a link to a picture that shows an example of what he drew.
    – alex
    Mar 3, 2019 at 17:20

3 Answers 3


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.

  • Huh interesting. So even after his solution, he knows that the Modem class still violates SRP. So do you think of an implementation of Modem class that will not violate SRP?
    – alex
    Mar 3, 2019 at 18:40
  • 1
    You just create two separate classes. But his point is that we don't work in an ideal world. E.g., you may be using a framework that makes it in some way difficult to to separate the implementation (e.g., because of the way it's structured, or the way it works, or for performance reasons), so that the cost of separation outweighs the benefits - and this is something that you (and your team) have to consider (it's kind of part of what your job is about). A lot of design has to do with thinking about trade-offs: you pay something to gain something, so it's about deciding if the cost is worth it. Mar 3, 2019 at 19:03
  • @alex: actually, I don't think the Modem class really violates the SRP on its level of abstraction. See my former answer to a similar question here.
    – Doc Brown
    Mar 4, 2019 at 7:29
  • @DocBrown: Interesting - it's certainly one way to think about it. If I understood you well, it comes down to taking different conceptual views on what the different responsibilities are on each side of the architectural boundary (e.g. layers). Mar 4, 2019 at 11:26
  • 2
    @FilipMilovanović: yes, that is probably another way to express it. The responsibility of the Modem class from the outside is clear: provide an abstraction for a "hardware modem", which has all these 4 functionalities related to the 4 methods, so it makes no sense to split this API up any further. How the class is implemented internally is a different question, Modem could be just a facade to at least two or more other classes, one dealing with the connection and one with the data transmission. So "SRP" is always dependent on the level of abstraction we look at, ...
    – Doc Brown
    Mar 4, 2019 at 12:09

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.

  • Thanks for the answer. So could you clarify how you mean "the rest of the system neither knows how messed up the impl. class is? " Is that because I may have some class "Computer" that programs to use the IModem interface?
    – alex
    Mar 3, 2019 at 18:38
  • I'm also a little confused here. So is there no better way to create the Modem class so that it doesn't violate the SRP?
    – alex
    Mar 3, 2019 at 18:39
  • 1
    If it needs to handle both connection and messaging, then no. Maybe you don't need a Modem class and would be better served with two classes? Objects in OOP don't need to correspond one-to-one with real life objects. Consider creating a ModemConnection class and a ModemData class. Mar 3, 2019 at 19:54
  • Mechanically, @alex, actual code would just want an IData and/or an IConnection, to use the names from your question. It wouldn't care if the IData is a Modem, a post office, or cannons & parachutes; it just cares that you can use it for dispatch & delivery. Nor would it care if the IConnection is a Modem, a satellite, or hundreds of dogs on hills barking in code; it just cares that it can create and end a connection to a distant entity. Mar 3, 2019 at 20:24
  • @alex better now? Mar 4, 2019 at 6:42

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.