The ProductRepository class mixes public and private product logic. From that API alone, there are many possibilities where an error could lead to leaking restricted data to public users. That is also true because the class exposes the private logic to the public-facing consumers; someone else could make a mistake.We are ready to rethink the class now that we identified the responsibilities. We know it has two responsibilities, so breaking the class into two sounds like an excellent first step. Let’s start with extracting a public API:
namespace AfterSRP;
public class PublicProductReader
{
public ValueTask<IEnumerable<Product>> GetAllAsync()
=> throw new NotImplementedException();
public ValueTask<Product> GetOneAsync(int productId)
=> throw new NotImplementedException();
}
The PublicProductReader class now contains only two methods: GetAllAsync and GetOneAsync. When reading the name of the class and its methods, it is clear that the class handles only public product data. By lowering the complexity of the class, we made it easier to understandNext, let’s do the same for the private products:
namespace AfterSRP;
public class PrivateProductRepository
{
public ValueTask<IEnumerable<Product>> GetAllAsync()
=> throw new NotImplementedException();
public ValueTask<Product> GetOneAsync(int productId)
=> throw new NotImplementedException();
public ValueTask CreateAsync(Product product)
=> throw new NotImplementedException();
public ValueTask DeleteAsync(Product product)
=> throw new NotImplementedException();
public ValueTask UpdateAsync(Product product)
=> throw new NotImplementedException();
}
The PrivateProductRepository class follows the same pattern. It includes the read methods, named the same as the PublicProductReader class, and the mutation methods only users with private access can use.We improved our code’s readability, flexibility, and security by splitting the initial class into two. However, one thing to be careful about with the SRP is not to over-separate classes. The more classes in a system, the more complex assembling the system can become, and the harder it can be to debug and follow the execution paths. On the other hand, many well-separated responsibilities should lead to a better, more testable system.It is tough to define one hard rule that defines “one reason” or “a single responsibility”. However, as a rule of thumb, aim at packing a cohesive set of functionalities in a single class that revolves around its responsibility. You should strip out any excess logic and add missing pieces.A good indicator of the SRP violation is when you don’t know how to name an element, which points towards the fact that the element should not reside there, that you should extract it, or that you should split it into multiple smaller pieces.
Using precise names for variables, methods, classes, and other elements is very important and should not be overlooked.
Another good indicator is when a method becomes too big, maybe containing many if statements or loops. In that case, you can split that method into multiple smaller methods, classes, or any other construct that suits your requirements. That should make the code easier to read and make the initial method’s body cleaner. It often also helps you get rid of useless comments and improve testability. Next, we explore how to change behaviors without modifying code, but before that, let’s look at interfaces.
Leave a Reply