How you know, the SRP is about "a class should have only one responsibility, do only one job, have only one reason for change, etc.". This principle is fundamental to writing clean, maintainable, and testable code. I read it in each book contains SOLID description.
But what does it mean: "one responsibility, one job, one reason for change"? Which of my own classes or those in the public libraries follow SRP and which do not?
For example, is LnkedList following SRP or not? Actually no. This class violates SRP because it has multiple responsibilities:
- adding elements to the list,
- removing elements from the list,
- managing the list's head and tail,
- provides some queue methods,
- do many other things.
But I didn't find an answer to this fundamental question in many books for beginner developers.
I think it's a million-dollar mistake - the reason why we have thousands of programmers who know the description of the SRP but don't know what it should look like in code. These programmers write complicated and ugly code that is difficult to read, understand, test, and change.
You may have heard of "spaghetti code" or seen it. If not, I'll show it to you:
@Service
class SomeService {
fun f1() {
...\\ if-else blocks
val v2 = f2()
...
return v1
}
fun f2() {
...\\ if-else blocks
val v3 = f3()
...
return v2
}
fun f3() {
...
return v3
}
}
This class has three public functions that call each other and can be called from outside the class. If you want to modify one of these functions, you need to search for all the places it is used. And these places may look like the SomeService class...
Now, you understand how violating SRP can ruin your project from its begin. What can you do to avoid SRP violations? Only two rules need to be followed:
1) class should have only one public function
@Service
class DoSomeBusinessFunction(
private val doCommonFunction: DoCommonFunction,
) {
fun execute() {
...
val v2 = doOtherBusinessFunction.execute()
val v4 = f4(v2)
...
return v1
}
private fun f4(v2: Value2) {
...
return v4
}
}
@Service
class DoOtherBusinessFunction(
private val doCommonFunction: DoCommonFunction,
) {
fun execute() {
...
val v3 = doCommonFunction.execute()
...
return v2
}
}
@Service
class DoCommonFunction {
fun execute() {
...
return v3
}
}
2) If you want to create a function that behaves differently for different business scenarios, forget about trying to modify it and follow the "KISS" principle by using "magical" shortcuts like Ctrl + C, Ctrl+ V. Create a new class that has a new public function with a new behavior:
@Service
class DoSomeBusinessFunctionV1 {
private val doOtherBusinessFunction: DoOtherBusinessFunction,
) {
fun execute() {
...
val v2 = doOtherBusinessFunction.execute()
...
return v1
}
}
@Service
class DoSomeBusinessFunctionV2 {
private val doCommonFunction: DoCommonFunction,
) {
fun execute() {
...
val v3 = doCommonFunction.execute()
...
return v1
}
}
This approach keeps your code clean and gives you the following benefits:
1) simplifies code reading and understanding
2) simplifies unit tests writing
3) simplifies code changing
4) teaches junior developers to understand programming principles and apply them in practice.
SOCIAL SHARE CARD GENERATOR