title: Principle of Best Principles
body: <p>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,</p>
  
  <pre><code>class Singer
    def initialize(name)
      @name = name
    end
    attr :name
  end
  </code></pre>
  
  <p>Then should Song be:</p>
  
  <pre><code>class Song
    def new(singer)
      @singer = singer
    end
  end
  </code></pre>
  
  <p>or</p>
  
  <pre><code>class Song
    def new(singer_name)
      @singer_name = singer_name
    end
  end
  </code></pre>
  
  <p>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.</p>
  
  <pre><code> class Song
     ...
     def play
       puts "Belting it out by #{@singer.name}, winner of
       #{@singer.grammy_count} grammies!"
     end
   end
  </code></pre>
  
  <p>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:</p>
  
  <pre><code>  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
  </code></pre>
  
  <p>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?</p>
  
  <p>I sometimes think many OOP principles, SOLID or otherwise, arose out
  limitations of Java, and don't apply so well to Ruby.</p>