answerrefa.blogg.se

1. #UNCLE BOB SINGLE RESPONSIBILITY PRINCIPLE SOFTWARE#
2. #UNCLE BOB SINGLE RESPONSIBILITY PRINCIPLE CODE#

The SRP is closely related to the concept of coupling. The more you know about these requests, the more you can separate your decisions and apply the SRP perfectly. They might be requests from your managers or even improvements from your perspective. These requests are the source of the reason to change. As a result, you have to be aware of any potential request for change that might violate the SRP in your code. Yes, defining the responsibility and reason to change is tricky. Or the message queuing tool may be changed. For example, data persistence may be changed from files to databases or from one database to another. Each of these responsibilities may be changed in the future. SRP suggests that every module has one reason to change and has one responsibility. The distributed system level might be caching, message queuing, proxy, or load balancer.

#UNCLE BOB SINGLE RESPONSIBILITY PRINCIPLE CODE#

Responsibility at the code level might be data persistence, logging, validation, third-party integration, or the business logic itself. Responsibility is the answer to the question of how something is done. The Auth class delegates sending the SMS task to another class SmsProvider which encapsulates its implementation in a way that the Auth class doesn’t know how the SmsProvider does its implementation. Encapsulation and delegationĪs you can see, the Auth class has a method login that is responsible for its business logic and sending an SMS to the user after logging in. On the other hand, when a class is multi-purpose, it often ends up coupling things that shouldn’t be related together and making it harder to use. Or a class can delegate a specific task to another instance of a class that encapsulates doing this task in an abstracted way. And when this class is a single-purpose, it does this purpose perfectly, and we can use it easily. This separation could be done using encapsulation and delegation.Ī class should encapsulate doing a specific task in a specific way.

#UNCLE BOB SINGLE RESPONSIBILITY PRINCIPLE SOFTWARE#

I think we agree that the better we’re able to separate the what and the how a class does, the better our software design is. To better understand this principle, we must keep another two principles in mind, encapsulation, and delegation. OK, first of all, you can think of a module as a function, class, component, or even microservice. So I am writing this article to share my approach to following this principle. I was always thinking of these questions. To be honest, this definition was very tricky for me. Or in contrast, you can think of some questions like what is the module exactly? What is the reason to change? And what does it relate to the responsibilities? You can think this definition is so easy to implement. “Each software module should have one and only one reason to change.” Uncle Bob

Martin (Uncle Bob) defines the Single Responsibility Principle as: