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

101–110 of 125 posts

Re: I don't love the single responsibility principle

#101

Post by dllthomas »

mercurial wrote: post #100
JackMorgan wrote: post #96

Earlier quoted context omitted.

This is highly dependent on your language. A language where functions can be passed as values allows functions to be injected as parameters (for polymorphic behavior). In Clojure, you can even replace a function definition just for unit tests without dependency injection at all. For example, with-redefs. This allows you to replace a given function anywhere in the whole codebase with any lambda. This rebinding only la…

Hm, that may be true for Clojure (or Python, as long as you don't redefine anything important), but I wouldn't how to do that with Haskell, for instance.

It's true that you can't replace arbitrary pieces with no source changes in Haskell. On the other hand, there are a few approaches to making this easier - implicit parameters seems made for this kind of thing, "foo = fooBy whatever" as a pattern leaves it easy to swap in an alternative; and of course keeping functions pure it becomes less necessary to swap out internal bits because they don't matter.

Re: I don't love the single responsibility principle

#102

Post by koide »

Arkadir wrote: post #76
mercurial wrote: post #75

Earlier quoted context omitted.

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 ?

when you require unit tests to finish quickly for functions doing io or otherwise time consuming processes. this being a good idea or not I'll leave to the threads about dhh's tdd article

Re: I don't love the single responsibility principle

#103

Post by unclebobmartin »

SRP is very simple. If two different people want to change a class for two different reasons, then pull those reasons into two different classes.

That is the SRP.

Example: A class that analyzes a data stream and prints a report. The data analysis will interest one group of people. The format of the report will interest another, different, group. The first group will ask for changes to the algorithms. The second will ask for changes to the format. The principle says to separate those two concerns.

This goes all the way back to David Parnas and the separation of concerns. His papers that describe it are freely available on the web. I suggest that they be studied, because they are full of wisdom and insight.

Re: I don't love the single responsibility principle

#104

Post by unclebobmartin »

SRP is very simple. If two different people want to change a class for two different reasons, then pull those reasons into two different classes.

That is the SRP.

Example: A class that analyzes a data stream and prints a report. The data analysis will interest one group of people. The format of the report will interest another, different, group. The first group will ask for changes to the algorithms. The second will ask for changes to the format. The principle says to separate those two concerns.

This goes all the way back to David Parnas and the separation of concerns. His papers that describe it are freely available on the web. I suggest that they be studied, because they are full of wisdom and insight.

Re: I don't love the single responsibility principle

#105

Post by DiscoBeat »

jbangerter wrote: post #46

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…

You got a point. Let me add that little objects allow you change inheritance for composition more easily.

Re: I don't love the single responsibility principle

#106

Post by Arkadir »

koide wrote: post #102
Arkadir wrote: post #76

Earlier quoted context omitted.

What situation would require to mock a function ?

when you require unit tests to finish quickly for functions doing io or otherwise time consuming processes. this being a good idea or not I'll leave to the threads about dhh's tdd article

I would argue that functions have no business performing global side-effects in the first place --- these things are better expressed as state encapsulators (such as objects) anyway.

Re: I don't love the single responsibility principle

#107

Post by Arkadir »

derefr wrote: post #78
platz wrote: post #66

Earlier quoted context omitted.

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.

The only difficulty is naming the abstraction :)

Re: I don't love the single responsibility principle

#108

Post by Arkadir »

CmonDev wrote: post #88
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 rarely ever use functions anymore. My life is complicated enough, I like my code to be simpler. I used to be proud of my numerous functions and clever designs.. now simple objects and mostly classes. I don't and won't argue with anyone who prefer to use plain functions, but it really annoys me when I need to spend 5mins wrapping my mind around all those functional relationships where a simple OOP (or imperative) co…

I have a hard time thinking of a situation where proper objects-and-functions code becomes easier to understand by removing the functions. Do you have any examples ?

Re: I don't love the single responsibility principle

#109

Post by Arkadir »

derefr wrote: post #79
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 inte…

This was just as easy in the previous generation :)

OCaml has had this feature since 1996.

Re: I don't love the single responsibility principle

#110

Post by dragonwriter »

vinceguidry wrote: post #33
dragonwriter wrote: post #31

Earlier quoted context omitted.

> I think the "don't mix persistence with bizlogic" idea came largely from the Rails world I'm pretty sure I encountered that particular example of things that shouldn't be coupled in OO design before Rails existed .

I guess I wasn't clear enough. Certainly the idea predated Rails, but I think the heavy insistence you see pretty much everywhere on segregating them probably came from Rails.

I think the more frequent discussions of separating domain logic from persistence in the context of Rails is a simple result of the fact that Rails is an opinionated framework whose basic structure promotes the exact opposite of that good practice, to wit, implementing the domain model not merely tightly coupled to the persistence layer, but indistinguishable from it -- in that Rails models provide both the domain model and the persistence functionality. So you see a lot of talk about basic separation of concerns in the context of Rails, because Rails so strongly leads people away from it.

This certainly has a certain kind of pragmatic value in getting something simple functioning quickly, its not just simply bad design of the framework. OTOH, it has the potential to impose a legacy cost as the complexity of the application increases.

Post reply on HN