Confusion on Single Responsibility Pattern (SRP) with modem example?2019 Community Moderator ElectionIs SRP...
Do authors have to be politically correct in article-writing?
Why is this code uniquely decodable?
Meaning of すきっとした
How to add multiple differently colored borders around a node?
Naming things the POV character doesn't know
Am I a Rude Number?
Find the number of ways to express 1050 as sum of consecutive integers
Table enclosed in curly brackets
I am on the US no-fly list. What can I do in order to be allowed on flights which go through US airspace?
Why is c4 a better move in this position?
Can chords be played on the flute?
What happens if a wizard reaches level 20 but has no 3rd-level spells that they can use with the Signature Spells feature?
ip vs ifconfig commands pros and cons
Why do neural networks need so many training examples to perform?
For Loop and Sum
Can I retract my name from an already published manuscript?
Can the Count of Monte Cristo's calculation of poison dosage be explained?
How to acknowledge an embarrassing job interview, now that I work directly with the interviewer?
How much time does it take for a broken magnet to recover its poles?
How do Japanese speakers determine the implied topic when none has been mentioned?
It took me a lot of time to make this, pls like. (YouTube Comments #1)
Is my plan for fixing my water heater leak bad?
Can a hotel cancel a confirmed reservation?
Can I become debt free or should I file for bankruptcy? How do I manage my debt and finances?
Confusion on Single Responsibility Pattern (SRP) with modem example?
2019 Community Moderator ElectionIs SRP (Single Responsibility Principle) objective?Is this a Single Responsibility Principle violation?Confused about implementing Single Responsibility PrincipleIs Visitor Pattern valid in this scenario?Single Responsibility Principle : Proxy Pattern for refactoringEnums and single responsibility principle (SRP)Large class with single responsibilitySingle Responsibility Principle Violation?Understanding Single Responsibility Pattern (SRP)Better pattern to ensure single responsibility
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 = {}
}
design-patterns object-oriented object-oriented-design single-responsibility
add a comment |
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 = {}
}
design-patterns object-oriented object-oriented-design single-responsibility
1
What doesn't seem right? YourModemImpl
class does indeed implement the methods individually.
– Kache
14 hours ago
Exactly. So, therefore, this still violates the SRP. ModemImpl still has more than "one reason to change".
– alex
14 hours ago
Please post the code with Martins fix. We shouldn't need the book handy to help you.
– candied_orange
14 hours ago
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
14 hours ago
add a comment |
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 = {}
}
design-patterns object-oriented object-oriented-design single-responsibility
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 = {}
}
design-patterns object-oriented object-oriented-design single-responsibility
design-patterns object-oriented object-oriented-design single-responsibility
edited 13 hours ago
candied_orange
53.8k17100188
53.8k17100188
asked 15 hours ago
alexalex
294
294
1
What doesn't seem right? YourModemImpl
class does indeed implement the methods individually.
– Kache
14 hours ago
Exactly. So, therefore, this still violates the SRP. ModemImpl still has more than "one reason to change".
– alex
14 hours ago
Please post the code with Martins fix. We shouldn't need the book handy to help you.
– candied_orange
14 hours ago
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
14 hours ago
add a comment |
1
What doesn't seem right? YourModemImpl
class does indeed implement the methods individually.
– Kache
14 hours ago
Exactly. So, therefore, this still violates the SRP. ModemImpl still has more than "one reason to change".
– alex
14 hours ago
Please post the code with Martins fix. We shouldn't need the book handy to help you.
– candied_orange
14 hours ago
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
14 hours ago
1
1
What doesn't seem right? Your
ModemImpl
class does indeed implement the methods individually.– Kache
14 hours ago
What doesn't seem right? Your
ModemImpl
class does indeed implement the methods individually.– Kache
14 hours ago
Exactly. So, therefore, this still violates the SRP. ModemImpl still has more than "one reason to change".
– alex
14 hours ago
Exactly. So, therefore, this still violates the SRP. ModemImpl still has more than "one reason to change".
– alex
14 hours ago
Please post the code with Martins fix. We shouldn't need the book handy to help you.
– candied_orange
14 hours ago
Please post the code with Martins fix. We shouldn't need the book handy to help you.
– candied_orange
14 hours ago
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
14 hours ago
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
14 hours ago
add a comment |
3 Answers
3
active
oldest
votes
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
12 hours ago
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.
– Filip Milovanović
12 hours ago
add a comment |
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
12 hours ago
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
12 hours ago
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.
– Martin Epsz
11 hours ago
Mechanically, @alex, actual code would just want anIData
and/or anIConnection
, to use the names from your question. It wouldn't care if theIData
is aModem
, a post office, or cannons & parachutes; it just cares that you can use it for dispatch & delivery. Nor would it care if theIConnection
is aModem
, 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.
– Justin Time
11 hours ago
@alex better now?
– candied_orange
42 mins ago
add a comment |
SRP is about reason for change, and people.
- 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
andwrite4bytes
) - The application logic guy is responsible for going in and providing higher-level semantics like
send
andreceive
.
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.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f387966%2fconfusion-on-single-responsibility-pattern-srp-with-modem-example%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
12 hours ago
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.
– Filip Milovanović
12 hours ago
add a comment |
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
12 hours ago
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.
– Filip Milovanović
12 hours ago
add a comment |
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.
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.
edited 13 hours ago
answered 13 hours ago
Filip MilovanovićFilip Milovanović
1,75439
1,75439
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
12 hours ago
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.
– Filip Milovanović
12 hours ago
add a comment |
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
12 hours ago
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.
– Filip Milovanović
12 hours ago
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
12 hours ago
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
12 hours ago
1
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.
– Filip Milovanović
12 hours ago
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.
– Filip Milovanović
12 hours ago
add a comment |
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
12 hours ago
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
12 hours ago
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.
– Martin Epsz
11 hours ago
Mechanically, @alex, actual code would just want anIData
and/or anIConnection
, to use the names from your question. It wouldn't care if theIData
is aModem
, a post office, or cannons & parachutes; it just cares that you can use it for dispatch & delivery. Nor would it care if theIConnection
is aModem
, 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.
– Justin Time
11 hours ago
@alex better now?
– candied_orange
42 mins ago
add a comment |
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
12 hours ago
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
12 hours ago
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.
– Martin Epsz
11 hours ago
Mechanically, @alex, actual code would just want anIData
and/or anIConnection
, to use the names from your question. It wouldn't care if theIData
is aModem
, a post office, or cannons & parachutes; it just cares that you can use it for dispatch & delivery. Nor would it care if theIConnection
is aModem
, 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.
– Justin Time
11 hours ago
@alex better now?
– candied_orange
42 mins ago
add a comment |
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.
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.
edited 44 mins ago
answered 13 hours ago
candied_orangecandied_orange
53.8k17100188
53.8k17100188
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
12 hours ago
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
12 hours ago
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.
– Martin Epsz
11 hours ago
Mechanically, @alex, actual code would just want anIData
and/or anIConnection
, to use the names from your question. It wouldn't care if theIData
is aModem
, a post office, or cannons & parachutes; it just cares that you can use it for dispatch & delivery. Nor would it care if theIConnection
is aModem
, 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.
– Justin Time
11 hours ago
@alex better now?
– candied_orange
42 mins ago
add a comment |
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
12 hours ago
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
12 hours ago
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.
– Martin Epsz
11 hours ago
Mechanically, @alex, actual code would just want anIData
and/or anIConnection
, to use the names from your question. It wouldn't care if theIData
is aModem
, a post office, or cannons & parachutes; it just cares that you can use it for dispatch & delivery. Nor would it care if theIConnection
is aModem
, 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.
– Justin Time
11 hours ago
@alex better now?
– candied_orange
42 mins ago
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
12 hours ago
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
12 hours ago
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
12 hours ago
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
12 hours ago
1
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.
– Martin Epsz
11 hours ago
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.
– Martin Epsz
11 hours ago
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.– Justin Time
11 hours ago
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.– Justin Time
11 hours ago
@alex better now?
– candied_orange
42 mins ago
@alex better now?
– candied_orange
42 mins ago
add a comment |
SRP is about reason for change, and people.
- 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
andwrite4bytes
) - The application logic guy is responsible for going in and providing higher-level semantics like
send
andreceive
.
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.
add a comment |
SRP is about reason for change, and people.
- 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
andwrite4bytes
) - The application logic guy is responsible for going in and providing higher-level semantics like
send
andreceive
.
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.
add a comment |
SRP is about reason for change, and people.
- 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
andwrite4bytes
) - The application logic guy is responsible for going in and providing higher-level semantics like
send
andreceive
.
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.
SRP is about reason for change, and people.
- 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
andwrite4bytes
) - The application logic guy is responsible for going in and providing higher-level semantics like
send
andreceive
.
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.
answered 13 hours ago
dnozaydnozay
1595
1595
add a comment |
add a comment |
Thanks for contributing an answer to Software Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f387966%2fconfusion-on-single-responsibility-pattern-srp-with-modem-example%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
What doesn't seem right? Your
ModemImpl
class does indeed implement the methods individually.– Kache
14 hours ago
Exactly. So, therefore, this still violates the SRP. ModemImpl still has more than "one reason to change".
– alex
14 hours ago
Please post the code with Martins fix. We shouldn't need the book handy to help you.
– candied_orange
14 hours ago
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
14 hours ago