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.