5
私は多くのデザイン問題に遭遇しているようですが、私は決して が であることはわかりません。一方で私は頻繁にカップリングを制限しなければならないと聞きましたが、 は1つの責任に固執していますが、私はしばしばそれが難しいと感じます。 to 必要なときにプログラムの一部に情報を取得します。 例えば、原則の原則
class Singer
def initialize(name)
@name = name
end
attr :name
end
そして歌であるべきである。
class Song
def new(singer)
@singer = singer
end
end
又は
class Song
def new(singer_name)
@singer_name = singer_name
end
end
後は、より少ない結合を有しているので、原理に従って私はそれを使用すべきです。 しかし、Songの何かが後で 歌手についてもっと知る必要があることを発見した場合、私は悪い方法です。例えば
class Song
...
def play
puts "Belting it out by #{@singer.name}, winner of
#{@singer.grammy_count} grammies!"
end
end
私は後でソングクラスの代わり 元を使用していた場合、私は修正になるだろう。 しかし、その後、私は誰かがSRP、単一責任 原則を思い出させるし、代わりに示唆している疑いがある：別の歌手が のカバー にいくつかのいずれか他の人のを行う可能性がありますので、
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
そしていや、私は、それが理にかなっていると思います歌、そう？しかし、それは本当に同じ の曲ですか？私の場合のほとんどでは決して同じ "歌"ではないので、 その 種類のシナリオはありません。それでSRPは、それが コードにもたらす余分なクラスの価値がありますか？
多くの場合、OOPの原則（SOLIDなど）はJavaの制限である が発生し、Rubyにはあまり適用されません。