第2章 単一責任のクラスを設計する
第2章 単一責任のクラスを設計する
クラスに属するものをどのように決めるか
「いますぐに」求められる動作を行い、かつ「あとにも」簡単に変更できるようにモデル化する
変更が簡単なにコードを書く
TRUEなコード
見通しがいい：コードの変更の影響が明白
合理的：変更のコストが変更の利益にふさわしい
利用性が高い：新しい環境や予期していなかった環境でも再利用できる
模範的：コードに変更を加える人が、自然と品質を保つようなコードになっている
単一の責任を持つクラスを作る
なぜ重要なのか
責任が互いに結合しすぎていると、クラスに変更が加わるたびに依存するクラスが破壊する（使えなくなる）可能性がある
クラスが単一責任かどうか見極める
クラスに知覚があるかのように仮定して問いただす（？）
＝ クラスの持つメソッドを質問に言い換えた時に、意味をなす質問になっているか？
１文でクラスを説明してみる
「それと」が含まれている場合、2つ以上の責任を負っている
「または」が含まれている場合、2つ以上の責任を負っているうえに互いに関連しない責任を負っている
yana-gi.iconこれ実際にやってみよう
「凝集度」
クラス内の全てがそのクラスの中心的な目的に関連していれば、そのクラスは凝集度が高い（単一責任）
yana-gi.icon変数やデータ構造の隠蔽の話よく分からなかった
クラスだけではなくメソッドも単一責任になるようにする
メソッドの変更や再利用が簡単になるため
役割が何か質問をして、一文で責任を説明できるようにする
メソッドが繰り返し処理をし、繰り返しの中で処理をしている場合も責任を2つ持っていると言える
yana-gi.icon処理分けたほうがいいのか迷っていたところ
メソッドを分離することで、クラスの役割ではない処理も見えてくることがある
クラスの責任の調査がしやすくなる
単一責任のメソッドのメリット
隠されていた性質を明らかにする
コメントする必要がない
再利用しやすい
ほかのクラスへの移動が簡単
yana-gi.iconメソッドを単一責任にすることが、クラスがより単一責任になることにもつながるのか
yana-gi.icon感想
リファクタリングするうちにクラスを分けたほうがいい、と分かることもある
最初から完璧にクラスをわけて考えないといけないと思ってた
メソッドを単一責任にすることが、クラスがより単一責任になることにもつながる
単一責任かどうか考える時は役割を質問する・一文で説明できるかを考えてみよう