Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don't love the single responsibility principle

sklivvz.com

Post reply on HN
Print view View original

11–20 of 125 posts

Re: I don't love the single responsibility principle

#11

Post by samrift »

I agree that the SRP is certainly a subjective rather than objective principle, and possibly general guidance that can and should be broken in specific circumstance. This article points that out but rather than try to apply prescriptive guidance around making it more objective in specific scenarios, the author seems to believe that its subjective nature is too flawed to fix.

What's the issue?

> A good, valid principle must be clear and fundamentally objective. It should be a way of sorting solutions, or to compare solutions.

Okay, I'm listening. What is your alternative?

> It's not a clear-cut principle: it does not tell you how to code. It is purposefully not prescriptive. Coding is hard and principles should not take the place of thinking.

And.... we're right back to subjective and general again. Set up a straw man only to knock it down with an identical straw man.

Of course, reducing coupling and raising cohesion makes the class responsible for less and less... So are we back at the authors interpretation of the SRP? Seems like it to me.

Re: I don't love the single responsibility principle

#12

Post by Cymen »

So Uncle Bob talks about SOLID. There is one S there and then we have O, L, I and D. Applying SOLID is a balance of all of these things. We are craftsmen applying knowledge and skill to code. Trying to figure out SRP in isolation is not practical. When you attempt to apply SRP in balance with the other principles, you get more of the give and take that matches reality. There are trade offs and deciding what those trade offs are is your responsibility as a developer.

What the blog post is about is more of a: "I do things this way". Now I'm on a team and my team mate wants to do things a different way. Instead of realizing I'm on a team and it is matter of balancing abilities to make a cohesive software product, I'm going to bicker about why my team mate is wrong. And I'm going to write a big blog post about it and look at SRP in isolation instead of applying the same cohesive viewpoint (that I claim my team mate is missing) to understanding SRP.

Re: I don't love the single responsibility principle

#13

Post by hderms »

wellpast wrote: post #8

>> The future is pretty irrelevant, so asking to design based on future requirements is uncanny. The future is irrelevant? That's exactly what design is for -- to protect you from the future. If you didn't care about the future there would be no need to design at all. A good way to evaluate various candidate designs is to imagine future use cases and ask which design holds up better. A good design will respond really…

I think that putting cohesion and coupling on a 1 dimensional axis is kind of disingenuous. There are an infinite number of design changes that could be made and some of them increase coupling, some of them increase cohesion and all number of variations between the two variables. The best designs will find cohesion and coupling at local maximums.

Re: I don't love the single responsibility principle

#14

Post by jdminhbg »

romaniv wrote: post #3

This article speaks about one of the many, many reasons I don't like Robert Martin's approach to programming. If some principle results in a handful of single-method classes that don't really do anything on their own, the principle is not a good basis for design. I find the author's alternative much more useful in practice.

> If some principle results in a handful of single-method classes that don't really do anything on their own, the principle is not a good basis for design.

Absolutely agree. Proponents of approaches like this tend to only worry about intra-object complexity, and ignore the fact that a vast, complicated object graph is also hard to reason about.

Re: I don't love the single responsibility principle

#15

Post by hderms »

To me it makes sense to think about how much state is being mutated in a given class. If you have a class with 200 different properties that are changing somewhat orthogonally to each other, you probably need to think things through and separate concerns a bit. Still kind of an 'arbitrary principle' but another way of looking at things. You want to encapsulate the moving parts but you don't want to throw every moving part in a giant bag.

Designating a class as having a single responsibility is an easy way to ensure that there is a minimal amount of state per class, but if the abstractions you are creating with this principle aren't logical than you are still left with a lot of moving parts someone has to think about when making modifications.

All these principles mostly only work if the system is also being designed rationally. Applying principles arbitrarily to a messy codebase will not necessarily get you a good design (and probably not) but thinking about these principles when making design decisions can sometimes be useful.

Re: I don't love the single responsibility principle

#18

Post by dragonwriter »

jdminhbg wrote: post #10

In an OOP design where objects already encapsulate both state and behavior, describing the ideal state of affairs as "single responsibility" seems kind of optimistic.

I think "state and behavior" is a bad way of thinking about it; in OOP design objects provide behavior. Its true that they encapsulate state, but the state (ideally) is simply that state necessary to provide the intended behavior. The behavior covers the area of responsibility, the state is part of the implementation of the behavior.

Re: I don't love the single responsibility principle

#19

Post by Glyptodon »

[deleted] wrote: post #16

[deleted]

Even the author says "Without any reference to the SRP it's obvious that this class needs fixing." He just makes an allowance that it's pretty much not worth fixing if your app is small enough and basic enough, IE it might be good enough design if the app in question does not do anything besides draw rectangles and calculate their area.

Re: I don't love the single responsibility principle

#20

Post by AnimalMuppet »

hderms wrote: post #15

To me it makes sense to think about how much state is being mutated in a given class. If you have a class with 200 different properties that are changing somewhat orthogonally to each other, you probably need to think things through and separate concerns a bit. Still kind of an 'arbitrary principle' but another way of looking at things. You want to encapsulate the moving parts but you don't want to throw every moving…

More cynically: Trying to apply a set of principles (any set) instead of thinking will likely lead to trouble.
Post reply on HN