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.