------ art_150_14891283.1321818162972
Content-Type: multipart/alternative;
boundary --- art_151_28847257.1321818162972"
------ art_151_28847257.1321818162972
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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 ame
end
attr :name
end
Then should Song be:
class Song
def new(singer)
@singer inger
end
end
or
class Song
def new(singer_name)
@singer_name inger_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 inger, 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.
------ art_151_28847257.1321818162972
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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,<div><br></div><div> class Singer</div><div> def initialize(name)</div><div> @name = name</div><div> end</div><div> attr :name</div><div> end</div><div><br></div><div>Then should Song be:</div><div><br></div><div><div style="border-style: initial; border-color: initial; "> class Song</div><div style="border-style: initial; border-color: initial; "> def new(singer)</div><div style="border-style: initial; border-color:nitial; "> @singer = singer</div><div style="border-style: initial; border-color: initial; "> end</div><div style="border-style: initial; border-color: initial; "> end</div></div><div><br></div><div>or</div><div><br></div><div><div style="border-style: initial; border-color: initial; "><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> lass Song</div><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> def new(singer_name)</div><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> @singer_name = singer_name</div><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> end</div><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> end</div><div><br></div><div>The later has less coupling, so according to principles I should use it.ut if I later discover something in Song needs to know more about the singer, I'm in a bad way. e.g.</div><div><br></div><div><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> class Song</div><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> ...</div><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> def play<br></div><div style="border-style: initial; border-color: initial; border-style: initial;order-color: initial; border-style: initial; border-color: initial; "> puts "Belting it out by #{@singer.name}, winner of #{@singer.grammy_count} grammies!"</div><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> end<br></div><div style="border-style: initial; border-color: initial; border-style: initial; border-color: initial; border-style: initial; border-color: initial; "> nd</div></div><div><br></div><div>I'd be in a fix if I had used the laterong class instead of the former. But then I suspect someone would remind me of SRP, single responsibility principle, and suggest instead:</div><div><br></div><div> class SongPlayer</div><div> def initialize(singer, song)</div><div> @singer, @song = singer, song</div><div> end</div><div> def play</div><div> puts "Belting it out by #{@singer.name}, winner of #{@singer.grammy_count} grammies!"<br></div><div> end<br></div><div> end</div><div><br></div><div>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 neverhe same "song" so I never have that kind of scenario. So is the SRP worthhe extra classes it brings to the code then?</div><div><br></div><div>I sometimes think many OOP principles, SOLID or otherwise, arose outimitations of Java, and don't apply so well to Ruby.</div><div><br></div></div></div>
------ art_151_28847257.1321818162972--
------ art_150_14891283.1321818162972--