Are some of Ruby's classes violating single responsibility principle?

Ruby
1

One example I can find is Integer class, it is primarily used to represent a number, but it can do some math operations on itself. This may not seem to be a lot yet, but then it can actually act like iterators(the downto, upto and times methods) for simple statement. It feels cool, but on the other hand I wonder if such implementation of Integer class is actually violating the single responsibility principle for good OO design. After all, the integer class seems to be doing value representation/conversion, math operation and iteration/loop at the same time, thats a total of three different responsibilities. Any Rubyists mind explaining this? Are there good reasons for this possible violation of single responsibility principle?

2

Welcome, @Hall_of_Famer; to these forums.

You bring up a good point. I think there is a little room for “interpretation” on such rules.

Remember, design principles are GUIDELINES and not hard, fast rules to be followed strictly

As an integral part of the set of BASE CLASSES in Ruby I think there needs to be even more latitude offered for FIXNUM as in your example.

This is a terrific topic for some discussion. I am anxious to see what other opinions may be offered here.

3

Thanks for your comment, looks like people dont have much to comment about this. After all, Ruby is not very popular on SitePoint, at least compared to PHP. Still, its nicer to be able to hear from some ruby experts talking about this language.

4

That does appear to be true. Let’s work to change that.
@markbrown; has been quite active here and you are an active member and obviously interested in Ruby. That makes THREE of us so far :smiley:
Perhaps we can “push the envelope” a bit.

5

Ruby is the Greatest Programming Language Of All Time! :slight_smile:

I don’t see a compelling reason why numbers should be especially dumb, every programming language allows a ton of functionality on Strings. They are a lot more complicated than numbers but it seems like a natural evolution to me that if everything is an object, we should start giving the humble integer more power.


"abc, def".split ","
"abc, def"[0..2]
"asdf, asdf".chars.each { |c| puts c }
3.times { |i| puts i }
3.odd?
1.round(2)

These types of methods are what make Ruby programs more natural.
Which of these snippets is more readable?


3.times do |i|
  print i.even?
end



for (var i=0; i<3; i++) {
  console.log(i % 2 == 0);
}
6

I agree with that - design principles are intended to help you write testable, readable, maintainable code and I think it’s important to take them with a pinch of pragmatism. In the case of the SRP, the idea is obviously that you’re aiming for your classes to only have a single reason to change, but with Ruby base classes you’re not responsible for maintaining them and you won’t be modifying them, so it seems acceptable to compromise the principle in trade-off for a more useable syntax.

I’m not familiar with how Ruby works under the hood, but it could be that some of the functionality (iteration, for example) is handled by a separate class, and
calling 3.times is just some kind of syntactic sugar.

Also, I think that when trying to apply the SRP, it can sometimes be tricky to identify what constitutes a single responsibility. There’s usually always the option to break things down to an even more granular level.