4

I address this question to people with advanced knowledge in the field of software architecture. I am trying to understanding the idea of Single Responsibility Principle (SOLID) related to the idea of elimination of code redundancy. My perception of code duplication was that code duplication is something wrong that needs to be fixed and eliminated. Actually I am reading the “Clean Architecture” (Robert C. Martin) and my perception changed and I am a little confused.

The SRP emphasizes the actor, so Robert Martin writes “A module should be responsible to one, and only one, actor”. As an example R. Martin talks about two classes (modules). The first class contains the method “calculatedPay()” specified by the accounting deparament. The other class contains the method “reportHours()” specified by another actor, the human resource department. Both functions share common algorithm (for example something like hour calculation). The natural approach would be to move the common algorithm to another class and eliminate the code duplication. After that both functions would call the algorithm in the new class. Imagine the accounting department needs to change the algorithm (in the new class). After the change the human resource department uses a new (invalid) algorithm. There is a problem and the problem is caused by breaking the SRP. The algorithm class (module) is responsible to two actor. On the other hand, we would have unnecessary code duplication, which makes me restless.

Maybe my dogmatic approach about code duplication is wrong, and there is nothing wrong to have the same code in many places. Isn't it? If I look at it from a different perspective, then I see there are multiple algorithms / or just code parts used by multiple clients (actors). And sometimes the used code needs to be change. It is something naturally for me. What would be the another way? That’s why I do not quite understand why not to place the duplication into another class. Another example with a different view, two classes with one function each, sharing common algorithm but both specified by the accounting department. There is no SRP break, because there is only one actor by the same problem still exists, because the one change can invalidate the another class. This is somehow very inaccurate...

Maybe I don’t understand the SRP and the idea behind...

Anon271828
  • 41
  • 4
  • Possible duplicate of [Can't seem to understand SOLID principles and design patterns](https://stackoverflow.com/questions/13692126/cant-seem-to-understand-solid-principles-and-design-patterns) – jtate Feb 05 '19 at 20:53

4 Answers4

4

As you will read later in the book:

Architects often fall into a trap —a trap that hinges on their fear of duplication. Duplication is generally a bad thing in software. We don’t like duplicated code. When code is truly duplicated, we are honor-bound as professionals to reduce and eliminate it. But there are different kinds of duplication.

There is true duplication, in which every change to one instance necessitates the same change to every duplicate of that instance. Then there is false or accidental duplication. If two apparently duplicated sections of code evolve along different paths —if they change at different rates, and for different reasons— then they are not true duplicates.

I think he explains very well your doubt.

With experience and continuos attention you will understand how to use SRP principale along with code duplication.

My personal opinion is that as you dig deeper in design patterns and architecture, you'll face some philosophical questions that cannot be (100%) answerd by stackoverflow users ;)

noiaverbale
  • 1,550
  • 13
  • 27
  • 2
    You are right. I want to complement that by saying DRY, we are talking about *logical* duplications, instead of code similarity. They are not necessarily the same. – Seideun Apr 20 '22 at 06:24
0

SRP is just a marketing term, that tried to promote the much older (and much better defined) cohesion and coupling concepts. I would suggest to just go back to those terms whenever there is a question about SRP.

Those do not say anything about code duplication as such, but they do imply that "data" should be always accompanied with all associated behavior.

That means, that there can not really be "duplicated code" that does the same thing, since it wouldn't have access to the same data as the original (since data is always encapsulated).

However, there can be duplicated code that does essentially the same thing, but for a different concept, with its own, but perhaps similar data. These things also would change for different reasons, so it would be inline with what Uncle Bob says I guess.

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
0

I would like to add: no design decision has to be static.

It might be a good decision at some point of time to extract duplicated code and share it from a single place. As requirements change it might be necessary to rethink this decision and "duplicate" the code again before changing it specifically for one user.

plainionist
  • 2,950
  • 1
  • 15
  • 27
0

I've faced same questions a few semesters ago. The importence and core concept of understanding SRP is also to understand redundant code.

First you must familiarise yourself with the concept of redundant code. Let's take a VERY simple example:

Actor1 uses class A:

Which has the responsibility to calculate given specific inputs from the Actor1 and Actor1 ONLY then return the result.

Actor2 will use class B:

Which has the responsibility to calculate something different given specific inputs from the Actor2 and then return the result. However designing the class we realize part of the calculation contains the same code as Class A contains.

This is an example where class B will contain redundant code if we proceed with our design, because it will contain duplicated code, that already exists in class A.

The solution:

According to SOLID (Open/closed principle) we are NOT allowed to go back and change class A and allow class B to use it. The reason is that we are not allowed to remove/modify any code existing in class A. The reason being we might break the code from Actor1 or another unknown actor.

So instead we write a class C which extends class A, so the specific calculation can be used via class C, and therefore may be used by both class B and any other calss in the future.

Hope this answered your question!