Tag Info

I'm not sure it is an anti-pattern as such but it would seem to violate the SRP. But that being said, there were probably perfectly good reasons the developer did what they did at the time. Despite the great strides made in design patterns and various methodologies, software entropy will continue to be an unfortunate feature of legacy systems. I'd be ...

The logic is riddled with compiler directives that change it's internal behavior based on which .Net project it happens to be compiled in. Compiler directives aren't the problem, they're just the means used to create the alleged problem. You'd probably have the same objection if you had to comment out and uncomment various blocks of code based on ...

"It depends" Compiler directives can be exceptionally useful tools. They can provide ironclad rules that keep development (debug) acceptable aspects out of production (release) builds. Likewise, an assembly can be made more lightweight by removing tracing instructions once the build is switched to release. On the other hand, they can be abused. I once ...

I think you're taking this from a backwards approach. Anti-patterns are a way of naming things that are known to have bad characteristics - they are diseases, not symptoms. It's really the symptoms we care about, even if we haven't named this specific disease yet. The way you should be talking about this is in terms of actual functional defects or deficits ...

I think the definition of SRP as "having one reason to change" is misleading for exactly this reason. Take it exactly at face value: the Single Responsibility Principle says a class or function should have exactly one responsibility. Having only one reason to change is a side effect of only doing one thing to begin with. There's no reason you can't at least ...

Isn't it a better idea to only really start to apply SRP when requests to change the code start coming in? Ideally, you'll already have a good idea what the responsibilities of the various parts of the code are. Split into responsibilities according to your first instincts, possibly taking into account what the libraries that you are using want to do ...

"Print" is very much like "view" in MVC. Anyone who understands the basics of objects would understand that. It is a system responsibility. It is implemented as a mechanism — MVC — that involves a printer (the View), the thing being printed (the Module) and the printer request and options (from the Controller). Trying to localize this as a class or module ...

Flup is headed in the right direction. The "single responsibility principle" originally applied to procedures. For example, Dennis Ritchie would say that a function should do one thing and do it well. Then, in C++, Bjarne Stroustrup would say that a class should do one thing and do it well. Notice that, except as rules of thumb, these two formally have ...

Yes, the Single-Responsibility-Principle should be applied to new code. But! What is a responsibility? Is "prints a report a responsibility"? The answer, I believe is "Maybe.". Let's try to use the definition of SRP as "having only a single reason to change". Suppose you have a function that prints reports. If you have two changes: change that function ...

A reason for change is, ultimately, a change in specification or information about environment where the application runs. So a single responsibility principle is telling you to write each component (class, function, module, service ...) so that it needs to consider as little of the specification and of the execution environment as possible. Since you know ...

When you are designing a new system, it is wise to consider the kind of changes you may have to make during its lifetime and how expensive those will be given the architecture you are putting into place. Splitting your system into modules is an expensive decision to get wrong. A good source of information is the mental model in the head of the business' ...

I think you're misunderstanding SRP. The single reason for change is NOT about changing the code but about what your code does.

Of course, the YAGNI principle will tell you to apply SRP first when you need it. But the question you should ask yourself is: do I need to apply SRP first and only when I have to actually change my code? To my experience, the use of SRP makes sense much earlier, namely when you have to find out where and how to apply a specific change in your code. For ...

(This answer is an expansion of my comment on the original question.) Honestly, I think you're taking the concept of single responsibility a little too far. Getters and setters are incidental to the functioning of the class whether you do it by direct access to public members or use methods (or properties) to do it. You're making the the argument that ...

There are two distinct levels at which you can apply the SRP. The first level is the level of individual functions/methods. Each should do only one task (and judging by the method names, none of the methods of Config break the SRP). The second level is the level of a class. Here the concept of a single responsibility becomes a bit more abstract, but a good ...

Your config class has the responsibility of tracking configuration, which is implements by holding private references to certain data, and providing access to them through mutator methods. This does not break the SRP, because the class itself still has a single responsibility; the mutators simply help it accomplish that responsibility by abstracting access ...