Low Level Design 105 | Single Responsibility Principle in SOLID | 2022 | System Design | Summary and Q&A

TL;DR

The Single Responsibility Principle states that a module should have only one reason to change or be modified by a single actor, ensuring clear and modular code.

Key Insights

• 📚 The Single Responsibility Principle (SRP) states that a module (class, function, package, etc.) should have a single responsibility or reason to change. It should cater to changes requested by one primary stakeholder or group of stakeholders.
• 💻 Uncle Bob's example illustrates how violating SRP by encapsulating multiple functionalities within one class can lead to unintended consequences and dependencies between different actors or stakeholders.
• 💼 In the example of an "Employee" class, the "calculate salary" and "calculate hours" methods are used by different stakeholders (CFO and HR department), leading to unintended side effects and breaking the SRP.
• 🔄 Changes requested by one stakeholder can impact other methods and introduce bugs, highlighting the importance of adhering to the SRP and separating functionality into separate classes.
• ⚙️ Adhering to the SRP can be achieved by decomposing one class into multiple classes, such as creating a "SalaryCalculator" class, "HoursCalculator" class, and a "Store" class, with each class handling distinct responsibilities.
• 🛠️ Separating responsibilities allows for easier maintenance, as changes made for one stakeholder don't impact the functionality required by others, promoting modular and independent code.
• 🧾 Another example with a "MenuItem" and "Bill" class demonstrates how violating SRP can lead to issues when making changes to database implementation or bill printing, emphasizing the need for separation of concerns.
• 👍 Design decisions related to SRP should be subjective, based on judgment and business requirements, aiming to create a design that is easy to change and fulfills the necessary functionality.

Transcript

Read and summarize the transcript of this video on Glasp Reader (beta).

Questions & Answers

Q: What is the Single Responsibility Principle?

The Single Responsibility Principle states that a module, such as a class or function, should have only one responsibility or reason to change. This ensures that code remains modular and prevents dependency issues.

Q: How does breaking the Single Responsibility Principle impact code?

Breaking the Single Responsibility Principle can lead to dependency issues, as changes from one actor or stakeholder can inadvertently affect other functions within the module. This can result in bugs and make the code more difficult to maintain and modify.

Q: How can the Single Responsibility Principle be implemented?

To implement the Single Responsibility Principle, classes can be decomposed into smaller, more focused classes, each catering to a single responsibility. This allows for easier maintenance and reduces the risk of dependencies between different parts of the code.

Q: Can a module have more than one public method and still adhere to the Single Responsibility Principle?

Yes, a module can have more than one public method as long as the changes to those methods are requested by a single primary stakeholder or group of stakeholders. As long as the changes fulfill a single business requirement, the module is considered to adhere to the Single Responsibility Principle.

Q: What happens when a module has changes requested by different stakeholders?

If a module has changes requested by different stakeholders, it means that the module is encapsulating different functionalities catering to different actors in the system. This breaks the Single Responsibility Principle and can lead to issues when making changes that inadvertently affect other functionalities within the module.

Q: How does the Single Responsibility Principle contribute to code maintainability?

By adhering to the Single Responsibility Principle, code becomes more modular and easier to maintain. Each module has a clear responsibility, making it easier to understand, modify, and test. Changes can be made to a specific module without impacting other parts of the codebase.

Q: Are there any limitations to the Single Responsibility Principle?

The Single Responsibility Principle is subjective, and there is no definitive answer to how many responsibilities a module should have. It ultimately depends on business requirements and design judgment. However, ensuring that a module has a clear and singular responsibility can lead to more maintainable and flexible code.

Summary & Key Takeaways

• The Single Responsibility Principle states that a module, such as a class or function, should have only one responsibility or reason to change.

• Breaking the principle leads to dependency issues and potential bugs, as changes from one actor or stakeholder can impact other functions within the module.

• The principle can be implemented by decomposing classes into smaller, more focused classes, each catering to a single responsibility.