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

41–50 of 125 posts

Re: I don't love the single responsibility principle

#41

Post by zenbowman »

userbinator wrote: post #34
jdminhbg wrote: post #14

Earlier quoted context omitted.

> 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.

only worry about intra-object complexity That reminds me of this, not sure if it's satirical or not: http://www.antiifcampaign.com/ Basically it's advocating removing if/switch statements and replacing them with polymorphic method calls. I understand that polymorphism has its value, but think that it's only valuable when, for lack of a better phrase, the thing that's being polymorphosed is "big and varied" enough tha…

Great point. Squeezing unrelated objects into class hierarchies to avoid a couple of trivial "ifs" is the ultimate destroyer of readability.

Re: I don't love the single responsibility principle

#44

Post by kasey_junk »

fleitz wrote: post #36
kasey_junk wrote: post #25

Earlier quoted context omitted.

Unless it fails to meet the requirements or is written in such a way that will require more maintenance...

Well, I'm assuming we're comparing code that works. Maintenance is generally a red herring, it's best to use statistical methods to determine the likelihood of maintenance. Usually if you're doing lots of maintenance you have other problems in your code / workflow, such as mistaking your codebase for your database.

"Well, I'm assuming we're comparing code that works."

That is an interesting assumption given that in many problem domains proving that the code works as specified is the hardest problem.

"Maintenance is generally a red herring, it's best to use statistical methods to determine the likelihood of maintenance."

I really dislike anyone who makes general claims about the entirety of software development. I for one spend way more time changing existing code than writing new code. I know that there are problem domains where that is not the case so I don't recommend my methods for those spaces.

What are these statistical methods you are referring to?

"Usually if you're doing lots of maintenance you have other problems in your code / workflow, such as mistaking your codebase for your database."

Or you are working in a problem domain that shifts a lot, or where requirements specification is more expensive than deployment opportunity costs, or in a legacy system.

Re: I don't love the single responsibility principle

#45

Post by kasey_junk »

zenbowman wrote: post #40
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.

Agreed. I find the best advice comes from people who have built significant systems that are both complex and innovative for their time. Rob Pike and Dennis Kernighan's The Practice of Programming is one of my favorites for this reason. They tend to recommend solutions that are highly dependent on the problem to be solved. Trying it the other way round, i.e. fitting the problem to an idealized solution, rarely works,…

"As an example, creating a function and calling it twice from two similar classes is much easier to read than inventing an intermediate class that is an ancestor of the two (something I see very often from the hardcore OO folks)."

You really see this a lot? As far as I can remember using inheritance over composition for de-duplicating code has been considered bad practice in OO circles for at least 15 years.

Re: I don't love the single responsibility principle

#46

Post by jbangerter »

Likewise with many here, I agree with most of the author's points, especially that one should think for one's self, which sklivvz did very well.

However, the fear of many little objects smells strikes me as backwards. Unix systems are built with and used by many little utilities. As a result, a few simple commands can be strung together to make quick work of interacting with the system. Often, I find that the hardest utilities to master are the ones with the broadest scope. My experiences with large objects are similar.

Re: I don't love the single responsibility principle

#47

Post by thibauts »

This obviously is mostly smoke and mirrors. Uncle Bob recycles Separation of concerns [1] and overshadows it in the process. You won't define what are good or bad boundaries in code anymore than you will define "5 easy rules to author a great piece of fiction". The computer doesn't give a damn about separated concerns, it's all about communication between humans. As such it is a matter of feeling, dare I say emotion, and not a matter of laws and rules. Ultimately our ability to break problems in sub-problems tends to be bounded by the words we have at our disposal.

The TCP/IP stack exemple in the Wikipedia article linked below hints at SoC pretty well in my opinion. One layer allow the layer above to disregard details about the physical link. The next layer makes cross-network addressing transparent. The next one allows apps to disregard packet ordering and loss, and so on. Each layer solves a problem for the one above. Yet one can have multiple responsibilities. This is all about cognitive load.

A system described in code is nothing more than a proposed consensus around tools, names, boundaries, paradigms to be used to talk and think about a solution to a problem. The ultimate measure of success is this: our ability to tame the binary beast. If "change" plays a role (it sure does) it's probably not the main or only metric. Well ... when you're not selling "ability to change" consulting and books to software companies, this goes without saying.

[1] http://en.wikipedia.org/wiki/Separation_of_concerns

Re: I don't love the single responsibility principle

#49

Post by Fargren »

donatj wrote: post #42

I'm not an expert but I think he is misinterpreting what is meant by 'change' entirely. My reading of it is as in the class only has one reason to change (state). Correct me if I'm wrong.

The SRP, as I was taught it, means that there must for each class only one kind of change in the requirements of the program that requires a change in the class. "Kinds of change" are quite vaguely defined, though.

Re: I don't love the single responsibility principle

#50

Post by thibauts »

Cymen wrote: post #12

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 tra…

"Instead of thinking out of my box for once, I'll biker about OP that's probably not a craftsman (tm) and assume pretty much anything about him and his bad intentions provided it helps me rationalize my fear in a belief-preserving way".

So no thanks, I don't want Uncle Bobby to save me, I don't need an encyclopedia either. Have a good day my friend. (Go easy on the blue pill ...)

Post reply on HN