![]() ![]() ![]() This phrase is a little more concrete, but it still doesn’t explain what a responsibility is and how small or large a responsibility should be for each particular method, class, module, or service. ![]() So, the SRP states that each component should have a single responsibility. The Single Responsibility Principle applies to the software that we develop on different levels: methods, classes, modules, and services (collectively, I’ll call all these things components later in this article). Let’s try to deconstruct it and look at what it actually means. The Single Responsibility Principle may feel a bit vague at first. Let’s pretend we’re a blind worshiper of the pattern and of the so-called database model and want to appeal to its niceties for creating a basic entity class which should model the data and behavior of generic users.This article explains the Single Responsibility Principle (SRP): what does it practically mean? And when and how should we apply it? What Does the Single Responsibility Principle Say? One that I find particularly instructive is the Active Record Pattern because of the momentum it has gained in the last few years. Let’s move along and code a few digestible examples so that we can see how to take advantage of the principle’s benefits.Ī Typical Violation of the Single Responsibility Principleįor obvious reasons, there’s plenty of situations where a seemingly-cohesive set of operations assigned to a class actually scope different unrelated responsibilities, hence violating the principle. If it ever needs to change in response to another, totally unrelated operation, then it’s clear the class has more than one responsibility. In other words, a class should only change in response to the execution of those semantically-related operations. What the principle attempts to promote is that classes must always be designed to expose only one area of concern and the set of operations they define and implement must be aimed at fulfilling that concern in particular and nothing else. There should never be more than one reason for a class to change. But how can one be pragmatic in more generic, day-to-day situations, and design classes whose concerns are decently cohesive? Even when there’s no straight answer to the question, it’s possible to adhere in general to the rules of the Single Responsibility Principle, whose formal definition states the following: It’s easy to stay away from Singletons without feeling a pinch of guilt. ![]() Singletons are entities unavoidably cursed with the obligation of performing at least two different tasks which aren’t even remotely related to each other. They can be also be blamed for doing two semantically-unrelated things at the same time: asides from playing their main role, whatever this might be, they’re responsible for controlling how the originating classes should be instantiated as well. We all know that Singletons have been condemned for years because they suffer all sort of nasty implementation issues, with the classic mutable global state by far the most infamous one. The so-called “God class” is quite possibly the most extreme and coarse example of a structure that packages literally piles of unrelated operations behind the fence of the same API, but there are other subtle, more furtive situations where assigning of multiple roles to the same class are harder to track down. One of the most notorious consequences of this rational associative process is that, at some point, we effectively end up creating classes that do too much. Most of the time we tend to group tasks in question by following an ad-hoc semantic sense in consonance with the nature of our own human mind. However, it’s admittedly pretty difficult to design such systems, at least in the first take. Robust software systems should be built up from a web of interrelated objects whose responsibilities are tight, neatly cohesive, boiled down to just performing a few narrowed and well-defined tasks. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |