Low Level Design 105 | Single Responsibility Principle in SOLID | 2022 | System Design

Summary

This video delves into the Single Responsibility Principle (SRP), a key concept in SOLID design principles. Contrary to common misconceptions, SRP doesn't imply a class should have only one method or reason to change. Instead, it emphasizes that a class should have one reason to change, driven by a single 'actor' or stakeholder. The video uses Uncle Bob's 'Clean Code' to illustrate this with examples like an 'Employee' class and a 'Bill' class, showing how changes in one part of a class can affect other functionalities if not properly separated. The solution? Decomposing classes to ensure each handles a single responsibility, thus adhering to SRP and making software easier to maintain and less prone to unintended side effects from changes.

Takeaways

• 📚 The Single Responsibility Principle (SRP) suggests that a module or class should have one reason to change, meaning it should address the needs of one actor or stakeholder.
• 🚫 Contrary to common misconceptions, SRP does not imply that a class should have only one public method; rather, it emphasizes that changes to the class should be driven by a single business requirement.
• 👨‍🏫 Uncle Bob's book 'Clean Code' provides a detailed explanation of SRP, using examples to illustrate how a class can serve multiple methods corresponding to different stakeholders without violating the principle.
• 🔍 The term 'actor' in SRP refers to different stakeholders or departments within a system that might require changes to the functionality provided by a class or module.
• 💡 SRP is about ensuring that the impact of changes is isolated to the part of the system that is directly related to the stakeholder requesting the change, thereby minimizing unintended side effects.
• 🛠️ When a class is changed to meet the needs of one stakeholder but inadvertently affects the functionality used by another, it indicates a violation of SRP.
• 🔄 To adhere to SRP, it may be necessary to refactor a class into multiple classes, each with a distinct responsibility, allowing for independent changes without cross-functional impacts.
• 📈 The example of an 'Employee' class with methods for calculating salary, hours, and saving data illustrates how a single class can serve multiple actors, but changes in one area can ripple through to others if not properly designed.
• 🏢 The script uses a restaurant app scenario to further explain how SRP can be applied in practice, suggesting that classes like 'Bill', 'BillPrinter', and 'BillStore' should be separate to handle different responsibilities like calculating, printing, and storing bills.
• 🤔 SRP is subjective and requires judgment; it's about balancing the number of classes with the need to make the software easy to change and maintain without breaking existing functionality.

Q & A

What is the Single Responsibility Principle (SRP)?

The Single Responsibility Principle (SRP) is a software design principle that states a class or module should have only one reason to change, meaning it should only have one responsibility. It implies that the class should be designed in such a way that it encapsulates the functionality that caters to the needs of one particular stakeholder or group of stakeholders.

What does the term 'actor' mean in the context of SRP?

In the context of the Single Responsibility Principle, 'actor' refers to a stakeholder or a group of stakeholders who have a specific interest or requirement that could lead to changes in the software. It could be a department within a company, like the CFO, HR, or IT, each of which might require changes to the software for different reasons.

Why is it important to adhere to the Single Responsibility Principle?

Adhering to the Single Responsibility Principle is important because it helps in creating a modular and maintainable codebase. When a class has only one reason to change, it reduces the risk of unintended side effects when modifications are made. This principle contributes to a design where changes in one part of the system are less likely to affect other parts, thereby enhancing the overall stability and reliability of the software.

Can you provide an example from the script that illustrates the violation of SRP?

An example from the script that illustrates the violation of SRP is the 'Employee' class with methods like 'calculate salary', 'calculate hours', and 'save employee data'. These methods cater to different stakeholders (CFO, HR, and IT), and changes in one method due to the requirements of one stakeholder can inadvertently affect the functionality used by another stakeholder.

How can the violation of SRP be resolved according to the script?

The script suggests resolving the violation of SRP by decomposing the class into multiple classes, each with a single responsibility. For instance, creating separate classes like 'SalaryCalculator', 'HoursCalculator', and 'Store' for handling salary calculation, hours calculation, and data storage respectively, ensures that changes in one class do not impact the others.

What is theFacade Pattern mentioned in the script, and how does it relate to SRP?

TheFacade Pattern is a design pattern that provides a simplified interface to a complex subsystem. In the context of SRP, it can be used to create a unified interface for a set of classes that handle different responsibilities, thereby adhering to the principle by ensuring that changes in one part of the subsystem do not affect others.

How does the script explain the concept of a 'module' in relation to SRP?

In the script, a 'module' is explained as a collection of classes, functions, or a package that encapsulates a set of functionalities. It should be designed in such a way that it has only one reason to change, driven by the needs of one actor or stakeholder group.

What is the significance of decomposing a class into multiple classes as per SRP?

Decomposing a class into multiple classes as per SRP ensures that each class has a single responsibility and a single reason to change. This leads to a design where each class is focused on a specific business requirement or functionality, making the system easier to understand, maintain, and extend.

How does the script address the misconception that a class should have only one public method according to SRP?

The script clarifies that the misconception about SRP being that a class should have only one public method is incorrect. Instead, it emphasizes that as long as the changes in a class are driven by one primary stakeholder or group of stakeholders, the class can have multiple public methods.

What are some practical examples given in the script to explain SRP?

The script provides practical examples such as the 'Employee' class with multiple responsibilities and the 'Bill' class in a restaurant app that calculates the final amount, prints the bill, and saves the bill. These examples are used to illustrate how violating SRP can lead to issues and how decomposing these classes can resolve these issues.