Robert C. Martin先生のCleanCode第10章を読んだメモ。

クラス(第10章)の概要

• クラスの構成
  • 変数定義から書く
    • Robert C. Martin的には以下の順番
      • public static
      • private static
      • private
      • publicは避ける
      • public関数
      • private関数
  • このようにすると新聞のように詳細が下に来やすくなる。
• カプセル化
  • privateに固執するわけではなく、テストを優先に考えている。
    • protectedにしたり、パッケージスコープに入れることも考える。
  • カプセル化を緩めるのは最後の手段
• クラスを小さくしなければならない
  • とにかく小さくする。
  • クラスは、行数ではなく責務の数で小さくする。
  • メソッド数が少なくても責務が多すぎると良くない。
  • 名付けでメソッドやクラスの責務を明確にする。
    • Processer,Manager,Superなどの曖昧な名前は責務が不当になっているサイン
  • クラスの責務を説明説明しようとした時に、「もし」「そして」「あるいは」「しかし」などの単語以外の単語を使って25語以内で説明できるようにする。
    • 説明の中に「そして」が出てきたら、責務を持ちすぎているサイン
• 単一責任原則
  • OOPの概念で最も重要なものの1つ
  • そして、もっとも無視されがちな原則の一つ
  • 変更の原因となるものが1つでなければいけない。
  • プログラミングの活動においても重要。
    • プログラムが動作するようになった時点で、洗練するという別の関心ごとへ移ることに失敗しがち
    • 小さなクラスがいっぱいあって、全体を見失うことを恐れている場合もある。
    • 大きなクラスよりは小さなクラスの方が、可動部分が少ないため、気軽にコードをなげこめるようになる。
    • 大きなクラスの場合、理解しなくても良い部分まで調べることになってしまう。
• 凝集性
  • 限られたインスタンス変数を持つべき。
  • クラス内のメソッドは1つ以上の変数を操作する。
  • 全変数が全メソッドに使用されるクラスは凝集性が最大限に高い。
    • 最大限にせよというのは実現可能でもないし、有用でもない。
    • だが、凝集性を高める必要はある。
  • 関数を小さくし、引数リストを短くするという鉄則につながる。
  • あるメソッド群で使用されるインスタンス変数の急増に繋がった場合、クラスを分割できるサイン
• 凝集性に気を配ると、大量の小さなクラスが生まれる。
  • 大量の引数に依存している大きな関数があった場合、気軽にインスタンス変数にして引数を減らす選択だと凝集度が下がりがち。
  • 小さなクラスを大量に作って凝集度を高めると良い。
  • これにより、責務が区切られやすくなり、気軽に変更ができるようになる。
  • 表現が豊かな変数名を与えられる。currentUserName -> User.nameなどだと思われる。
  • コードの解説が、関数とクラスの宣言を利用できる。
  • ソースが見やすくなり、書式化の技法を用いることが容易。
• 変更のために最適化する。
  • 洗練されたシステムでは、クラスは変更に対するリスクが最低限になるように構成されている。
  • OCPを意識して、新規機能が既存システムの拡張のみで実現されるようにすることで、既存にシステムに変更を及ぼさないようになる。
• 変更から切り離す。
  • 詳細な具象クラスではなく、抽象に依存することで変更を切り離すことができるようになる。(DIP)
  • 具象クラスへ依存しているとテストがしづらくなる。
  • こうすることで、柔軟性が高まり再利用がより簡単にできるようになる。

感じたこと

SRPが何を指すかは体感するのに非常に苦労をした覚えがある。
確かに説明する時に「そして」が出てきたら、責務違反のサインは他人に伝えやすいなと思った。
ただ、モデリングを誤るとよくわからない責務のクラスができがちな印象を持っているので結構バランスが難しいと今でも感じている。