“responsibility” is very subjective and too open to the overly analytical left-brain developers that want to over-engineer everything. “I’m building a car? Ok, it needs an engine. So I need pistons, crank shaft, oil pan / pump, spark plugs, block, ….” vs “I’m building a car that accelerates and breaks? Ok. Here’s the car w/ an accelerate method, and a break method.”

“one reason to change” forces us to ask questions about the reasons for change… what are the valid reasons in this case. what are the possible vectors of change that we know of in this application? Am I building a vehicle repair system that needs to track every single part? Or am I building a child’s entry-level video game with two buttons: accelerate and break?

… fwiw: i keep waiting for someone to come along and show me where my opinions and ideas have gone off the deep end. these are my opinions and ideas after having dealt with this stuff for a bunch of years… but i still don’t think i’m an “expert” with this stuff by any means. i keep going back to the examples used in the “Agile principles, patterns and practices” book, and scratching my head at how they came up with some of those examples and great solutions. :P

I guess I still don’t see the distinction between roles and responsibilities as you are seeing it. Can you elaborate on situations where an object would keep to a single responsibility but take on multiple roles?

I’m also sensing you making a separation between the name of the principle and its definition? Are you saying that taking the name of the principle (“single responsibility”) too literally is an unnecessary restriction, and that following the definition of the principle (“one reason to change”) is sufficient? Isn’t having more than one role having more than one reason to change?

Interested to hear your thoughts. Thanks!

SRP says a class (or object in non-classy languages) should have one reason to change. We change a class/object by changing it’s code. If I define 5 or 10 fields for my Foo class in the above example, and use it in a simple forms over data app, there’s likely no violation of SRP happening because the responsibility of the class is moving data between the form/user input and the database.

That doesn’t mean it’s never an SRP violation, though. SRP is very contextually sensitive. An SRP violation in one code base may be a perfectly fine chunk of code with no SRP violation in another context.

If I’m building a highly complex business application with tendencies toward domain modeling and other domain-driven-design concepts, then including Mongoid::Document in a domain model is likely an SRP violation… not because there are too many methods on the runtime object, though. But because I have chosen to mix the responsibility of data persistence with the responsibility of the domain model.

For more of my opinion on SRP, see my SOLID article here: http://www.code-magazine.com/article.aspx?quickid=1001061&page=4

The problem with heavy use of mixins, from the perspective of what functions are for what responsibility, is generally at runtime. doing a list of methods like i did is a runtime call, for example. but the actual code for Mongoid, and the documentation for it, are not a giant blob like that. 

If you look at Ruby’s Array class documentation (which is admittedly a poor example because of the number of methods on it) you can see that it includes the Enumerable module. 

http://ruby-doc.org/core-1.9.3/Array.html

Assuming I know what an Enumerable is, in Ruby, and have a fair idea of what responsibilities that module encompasses, I now know one of the responsibilities that is mixed in to an Array. 

Knowing that an Enumerable exists allows me to write code to that API/Protocol/whatever you want to call it. When I’m writing my own code or reading documentation for other people’s code and I see someone say that a parameter should be an Enumerable, I have knowledge of what that is because the documentation has lead me to it.

 ”If we look at a message-based method dispatch in the same light and perspective as we do a interface-based dispatch, things look bad. If we look at the message-based, first-class-mixin system as a series of responsibilities, though, with each responsibility having it’s own protocol definition and each responsibility and protocol captured into an object that can be composed into a larger piece (again, mixins), things look much better.”

How do you look at and understand highly mixed code, protocol definition at the ruby method / message level – etc.

Definitely, I maybe wasn’t clear. Lets say I’m coming to a new method and its taking in an argument. I just want a quick summary of what I can do with that argument. You’ve answered how to work it out, and I do the same, look at code or documentation (or tests).

But just compare static to dynamic here. Static if I’ve used ISP I know exactly what I can do with the argument, the protocol is explicit. Dynamic I obviously can’t be 100% sure (metaprogramming) but even ignoring that its a bit more implicit. Thats good if I get to a type somehow (say Foo) but less good if Foo has lots of mixins, suddenly I have a lot of choices (lots of responsibilities in one place). I’ve got a bit of work to find out which of them applies in this context.

This is not an argument against dynamic languages at all, but I do worry that if you have such a wide interface combined with a dynamic language then you could be making it hard for the maintainers of your code.

Caveat is this hasn’t been a big problem for me, but then I haven’t actually worked on large Ruby codebases and I have found it to be a little bit of an issue when working with some open source Ruby code.

the only time i ever list the methods on an object are when i think there should be a method with a specific name… then i’ll `.methods.grep(/name/)` to find it. other than that, i read documentation for each of the separate responsibilities, and I look at the code to find the responsibilities and the protocols (API) that they implement.

as for ISP… i’m not sure ISP as it was originally defined applies to ruby very well. Jim Weirich discussed SOLID ruby back in 2009: http://confreaks.net/videos/185-rubyconf2009-solid-ruby note in the ISP section (at 40:10), he all but says that ISP doesn’t apply because a language like ruby requires a far deeper implementation of DIP – dependency inversion – via responsibilities and protocols (APIs). he specifically says “depend upon narrow protocols”, but in his description of that he talks about dependency inversion. 

with such a deep need for dependency inversion, the ability to easy mix a dependency’s protocol into an object, and the nature of ruby being message-based dispatch instead of interface-based, I have a hard time seeing classic ISP techniques as a concern. ISP itself still applies… but i don’t think it’s a first-class concern in Ruby. i think it’s a side effect of other principles, like DIP, SRP, etc. 

when looking at the code and documentation for my Foo object, I should see the API that directly relates to Foo and it should be simple and ISP conforming. When I list the methods for a Foo instance at runtime, though, that’s a different story. the ability to compose objects at run time means we can’t assume the same perspective on what these principles look like at runtime.

I get what your saying but when faced with an object with 354 methods don’t you end up being a bit lost?

To me thats where the interface segregation principle has value, it makes it much easier (as a developer) to reason about a particular object. Mixins help with that to some extent, its not like you look at your type and see 354 methods, but the roles you mention are pretty implicit when your looking at a particular object (or argument).

I am looking forward to giving Dart a proper run for its money because to me its optional typing could have real possibilities, for example in the case of your Foo maybe carving off some of that behavior into an interface so that when viewing the code one of the responsibilities is made more concrete.