Principle of Best Principles

Question

I seem to run into a couple of design issue a lot and I never know what is really proper. On one hand I often hear that I should limit coupling and stick to single responsibility, but when I do I often find it difficult to get the information to part of the program when it is needed. For example,

class Singer
  def initialize(name)
    @name = name
  end
  attr :name
end

Then should Song be:

class Song
  def new(singer)
    @singer = singer
  end
end

or

class Song
  def new(singer_name)
    @singer_name = singer_name
  end
end

The later has less coupling, so according to principles I should use it. But if I later discover something in Song needs to know more about the singer, I'm in a bad way. e.g.

 class Song
   ...
   def play
     puts "Belting it out by #{@singer.name}, winner of
     #{@singer.grammy_count} grammies!"
   end
 end

I'd be in a fix if I had used the later Song class instead of the former. But then I suspect someone would remind me of SRP, single responsibility principle, and suggest instead:

  class SongPlayer
    def initialize(singer, song)
      @singer, @song = singer, song
    end
    def play
      puts "Belting it out by #{@singer.name}, winner of
      #{@singer.grammy_count} grammies!"
    end
  end

And yea, I guess that makes sense, since another singer might do a cover of some one else's song, right? But then, would it really be the exact same song? In most of my cases it's never the same "song" so I never have that kind of scenario. So is the SRP worth the extra classes it brings to the code then?

I sometimes think many OOP principles, SOLID or otherwise, arose out limitations of Java, and don't apply so well to Ruby.

Answer 1

Coupling should be held up against another concept, cohesion. You want to strike a balance between the two, rather than just take one of them to the extreme. In your example, singer_name seems to belong to Singer, so to preserve cohesion, you should pass the Singer object to Song, rather than the name.

More generally, you need to keep in mind that such principles are merely guide lines. You always have to apply common sense and your unique understanding of the problem domain. There is rarely a clear cut case - It might even change as your application grows or as you understand the domain better.

Answer 2

Object-oriented programs should model real-life objects. In life a song belongs to a singer, not to the singer's name and in your programs you should model it in this manner.

As @troelskn already mentioned there is the concept of coupling, but there is also the concept of cohesion... Principles are great, but common sense should take precedence.