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

71–80 of 125 posts

Re: I don't love the single responsibility principle

#71

Post by gphil »

doorhammer wrote: post #70
kasey_junk wrote: post #62

Earlier quoted context omitted.

By that definition, I could just as easily argue that requiring different files for every class reduces cohesion. The idea that class definitions and file definitions are in any way related is a leaky abstraction.

I've never been a fan of the class-file coupling. It pulls me out of the mental model I'm trying to build in my head and forces me to think about file organization which is almost always inconsistent with the language semantics I'm dealing with. I've used IDE's that make this more or less painful, but none that actually solved it. If anyone has any suggestions on one that does, I'd be interested to try it out. I don'…

I think it's this podcast, where Rich Hickey explains codeq:

http://thinkrelevance.com/blog/2012/10/12/rich-hickey-podcas...

Re: I don't love the single responsibility principle

#72

Post by kyllo »

joevandyk wrote: post #54
usea wrote: post #24

I like many of the author's points. Pragmatism, thinking instead of blindly following principles, pushing back against size as a metric for measuring responsibility. I think Robert Martin's work absolutely deserves examination and critique. However, I don't share the author's definitions of simple and complex. Stating that "binding business rules to persistence is asking for trouble" is flatly wrong. Au contraire, It…

Unfortunately here, Rails encourages putting each class into a separate file, so you have 10 classes spread over 10 files, which does increase complexity. I dislike having a class/module per file.

In Django (the closest thing Python has to Rails) the convention is to put all your models in one models.py file. I also prefer it this way.

Re: I don't love the single responsibility principle

#73

Post by zachrose »

kyllo wrote: post #72
joevandyk wrote: post #54

Earlier quoted context omitted.

Unfortunately here, Rails encourages putting each class into a separate file, so you have 10 classes spread over 10 files, which does increase complexity. I dislike having a class/module per file.

In Django (the closest thing Python has to Rails) the convention is to put all your models in one models.py file. I also prefer it this way.

Interesting. In CommonJS modules, a file can only export one thing. You could namespace multiple things into one exported object, though I find that granular dependencies can lead to insights about how reusable your modules really are.

Re: I don't love the single responsibility principle

#74

Post by mercurial »

kasey_junk wrote: post #64
zenbowman wrote: post #59

Earlier quoted context omitted.

I definitely still see it, "best practices" once enshrined, change slowly.

Wow, that's terrible, but I'd prefer if you referred to those people as "out of date OO people" as opposed to "hardcore OO people". Even though I don't consider myself a "hardcore OO" person now, when I did this would bother me.

I concur. Many programmers, when attempting to reuse code, still reach blindly for inheritance in 2014.

Re: I don't love the single responsibility principle

#75

Post by mercurial »

rectangletangle wrote: post #67
d0m wrote: post #23

I rarely ever use classes anymore. My life is complicated enough, I like my code to be simpler. I used to be proud of my complex classes hierarchy and clever designs.. now simple objects and mostly functions. I don't and won't argue with anyone who prefer to use class hierarchies, but it really annoys me when I need to spend 5mins wrapping my mind around all those class relationships where a simple imperative (or fun…

Couldn't have said it better. Classes are useful, but only occasionally so. About the only time I find myself using classes is when there's several functions that have a very strong relationship to a particular portion of state (like when using an ORM). The rest of the time it's referentially transparent functions.

My beef with plain functions is that you can't mock them properly. But apart from this, yes. Referential transparency as much as possible.

Re: I don't love the single responsibility principle

#76

Post by Arkadir »

mercurial wrote: post #75
rectangletangle wrote: post #67

Earlier quoted context omitted.

Couldn't have said it better. Classes are useful, but only occasionally so. About the only time I find myself using classes is when there's several functions that have a very strong relationship to a particular portion of state (like when using an ORM). The rest of the time it's referentially transparent functions.

My beef with plain functions is that you can't mock them properly. But apart from this, yes. Referential transparency as much as possible.

What situation would require to mock a function ?

Re: I don't love the single responsibility principle

#77

Post by Arkadir »

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…

The most important rule about the future is that You Aren't Gonna Need It. If the future is known then it is called "requirements". Design is for protecting you from the unknown future: allowing code to be changed in arbitrary, unforeseen ways.

As for coupling and cohesion: if modules are too small, they usually lack cohesion ; if module are too big, they usually have high internal coupling. The sweet spot is in the middle. And you can create low-cohesion, high-coupling modules if you want :-)

Re: I don't love the single responsibility principle

#78

Post by derefr »

platz wrote: post #66
alttab wrote: post #58

Earlier quoted context omitted.

This is the single most important trick for factoring out shitty code. I cannot believe how many times reification collapsed complexity in our code base, or how not using it was the source of bugs. If you have cascading ifs, there is a good chance there is a huge set of ifs for every place this type system is missing. Meaning, if you wanted to add another "case" to a feature, you are modifying cascading ifs in 5-10 p…

So to reify a type involves making an abstraction, which is odd because reify seems the inverse of making an abstraction...

The abstraction already existed in your mental model. You're reifying it by making it something the code can refer to/reflect on/pass around.

Re: I don't love the single responsibility principle

#79

Post by derefr »

d0m wrote: post #23

I rarely ever use classes anymore. My life is complicated enough, I like my code to be simpler. I used to be proud of my complex classes hierarchy and clever designs.. now simple objects and mostly functions. I don't and won't argue with anyone who prefer to use class hierarchies, but it really annoys me when I need to spend 5mins wrapping my mind around all those class relationships where a simple imperative (or fun…

I also went through the stages of using classes with inheritance, and then using plain functions on untyped Plain-old-Data objects.

There's a third stage, though: using classes without inheritance, but with interface/protocol declarations. This is made much easier in the latest generation of languages (Go, Rust, Elixir) that infer the interfaces/protocols which a given piece of data supports, allowing you to use interfaces/protocols without classes.

Re: I don't love the single responsibility principle

#80

Post by nercury »

"The purpose of class is to minimize complexity" "The purpose of class is to organize code" "A class should have one, and only one, reason to change"

What?

What about: "The purpose of class is to encapsulate state".

If there is no inner fields in class, there is no reason for class. There is no state.

One or more fields in class means that they make sense when looking at all of them together, as a "state". If some method changes something, the all state encapsulated by class means something else.

It is possible to extrapolate all other guidelines from this basic starting point.

Post reply on HN