Designing Classes with a Single Responsibility

抜粋

クラスは一つの責任しか持つべきではない。そのクラスを一文で簡潔に説明できるかどうかが一つのバロメーター。 andやorが入る場合は、２つ以上の責任を持ってしまっている可能性が高い。

designの決定はしかるべき情報が揃った時にするのが一番いい。現状のクラスがイマイチすっきりしないように感じても、情報が揃うまで手をつけづにおくのは、コストを抑える一つの考え方。

data[0],data[1]のような曖昧なデータ表現は避けたほうがいい。こういった曖昧なデータを明示的にどういったデータを表すかをはっきりさせるのも一つの責任で、コードの中に散りばめてしまったら変更が大変になるので、曖昧なデータを明示的にするコードは一つの場所にまとめるべき（DRY）.

rubyではStructを使うことが一つの手段。

こういった場合、別のクラスに分けてしまってもいいが、Rubyの場合は、クラス内のStruct等にコードを分離しておくのも一つの手段。

こうしておくと、後から来た要望で、やっぱり別クラスにしたほうがいいなとなった時に、スムーズにコードを移植することができる。

また、そのままの状態が続いても、コードの意図が解りやすくなる。

感想

DRY(Don't Repeat Yourself)やSRP(Single Responsible Principle)について実際のコードの用いて説明されていてわかりやすかった。

曖昧なデータを使うべきではないところや、別クラスに分けるほどでもないな〜というケースは、よく遭遇するケースで、ぼんやりとケースごとに対処していたけど、解りやすく言語化されているので参考になる。

決定の保留に関してかなり頻繁に言及されていたりと、単純に原則を説明しているのではなく、実際のコストなどを考慮されていて、だいぶ実践的なのでいい感じ。

Every decision seems both permanent and fraught with peril. perilは危険

These questions can be overwhelming.

OO designer use the word cohesion to describe this concept.