![]() If you don’t have immediate problems with your code (e.g. There are a couple of ways to spot these kinds of violations. In this case, I would refactor this code and move this functionality to its own class. These responsibilities are coupled, and both have their own reasons to change.įor example, if I want to add functionality to not only support XML config files but also JSON config files, I need to change this class, which potentially leads to regression in the “create and manage Logger objects” functionality. All of the sudden, we have another responsibility besides creating and managing Logger objects: reading configuration from a file system. This LoadConfiguration method is responsible for reading an XML file containing the configuration for the LoggerFactory to use. There is however one method feels out of place, and that’s the LoadConfiguration method: It does multiple things (showing that a class doesn’t just have to do one thing), but they are all related to this one responsibility. In this project, there’s a class LogFactory that is responsible for creating and managing Logger objects. That is one of the things that make Open Source great: we can be exposed to others’ work and learn from it. Chances are that you’ll find potential issues like this in any reasonably sized project, either introduced consciously or unconsciously. I selected this project not because it has low quality code but because it is a medium sized project and has multiple contributors. NET framework that deals with logging and is similar to frameworks like Log4j in Java. An example violation in the wildĪgain, let’s look at some code from the NLog framework, a. So DRY and SRP only conflict with each other when not applied properly. One way to avoid duplicate code blocks is to put everything in a single class, but this could lead to a class that has multiple responsibilities that are coupled through the shared code block. But this is sometimes misinterpreted as avoiding duplicate blocks of code. Don’t Repeat Yourself is a principle that says that you should not duplicate business logic in your application. It’s good to realize the connection between SRP and Don’t Repeat Yourself (DRY) when DRY is not applied properly. These designs can break and lead to regression (unwanted change in functionality) when changing some code to satisfy new requirements for one of the responsibilities. If a class has multiple responsibilities those responsibilities become coupled, leading to fragile designs. In other words: we want to have one axis of change on which changes can happen, instead of multiple axes that can cross each other. Why do we want this? Because we want to be able to safely change behavior related to a responsibility without unintentionally change behavior that is related to another responsibility. The Single Responsibility Principle states that we want to group only those things that satisfy a single responsibility. Cohesion is making sure that things that are related are grouped together, and things that aren’t related are not. Instead, this principle is all about cohesion. If not, you’d end up with classes that only have a single public method. This is not the case: a class can do multiple things. Martin, is a derivative of the work of Tom DeMarco and Meilir Page-Jones and states:Ī class should have only one reason to change.Ī common misconception about this principle is that people think it means that a class should do only one thing. ![]() The Single Responsibility Principle, introduced by Robert C. That’s why I searched for some examples of these issues in Open Source projects and use them in this series. The SOLID principles are often explained by using simple examples, but that sometimes makes it hard to spot them in your own code for a real project. SOLID is an acronym for the following design principles: This time, we’ll discuss the Single Responsibility Principle. ![]() Last time, we looked at the Liskov Substitution Principle. This blog is part of a series explaining the SOLID design principles by looking at code from real projects or frameworks. Reading Time: 7 minutes SOLID violations in the wild: The Single Responsibility Principle
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |