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

オブジェクトとデータ構造(第6章)の概要

• データ抽象化
  • 単に変数の層に関数を入れる(所謂getterとsetterを定義しただけの構造)は実装の隠蔽ではない。
  • 抽象化しろ。
  • オブジェクトが保持するデータを最善の方法で表現するには、真剣に熟考する必要がある。
  • 軽い気持ちでゲッタとセッタを用意するのは最悪
• データ/オブジェクトの非対称性
  • データ構造
    • データを公開し、意味を持った機能は何も提供しない。
  • オブジェクト
    • 裏にあるデータを隠して抽象化し、データを操作する機能を提供する。
  • 手続き型(データ構造を使用するコード)
    • 新たな関数を既存のデータ構造に影響を与えず追加することができる。
    • 新たなデータ構造を追加するには既存のすべての関数を変えなければいけない。
  • OOP
    • 既存の関数に変更を加えることなく、新たなクラスを追加できる。
    • すべてのクラスを変える必要があるので新たな関数を追加することは難しくなる。
  • 複雑なシステムでは、新たなデータ型が増えることの方が多いのでOOPがうまく適合する。
  • 逆にデータ型を追加するよりも、関数を追加することの方が多い場合は手続き型の方がよく適合する。
  • OOPが常に優れているわけではない。
• デメテルの法則
  • 呼び出しのチェインはやめようね。
  • クライアントコードがオブジェクトの構造を知っている状態になってしまうよ。
  • なんの振る舞いも持たなければ、デメテルの法則は適用されないよ。(データ構造)
• 混血児
  • データ構造とオブジェクトの混血児が生成されることがある。
  • 新たな関数を追加することを困難にするだけでなく、データ構造の追加も困難になるからやめた方が良い。
  • 腐った設計に陥っているサイン
• 構造隠蔽
  • 必要なメソッドを定義して、その仕事をさせるようにして構造を隠蔽する。
• データ転送オブジェクト(DTO)
  • データベース、ソケットから取得したメッセージのパッシングなどに便利
  • DBから読み込んだ生データを変換していく過程の最初の段階として使われる。
  • private変数がゲッターとセッターで操作して、なんとなくカプセル化しているように見える場合もあるが、その使用方法にはなんの利点もない。
• アクティブレコード
  • DTOの特殊形態
  • ビジネスルールを持ったメソッドを追加しない方が良い。
    • オブジェクトとデータ構造の混血児を作ることになるから
  • アクティブレコードはデータ構造として扱い、ビジネスルールを持ったオブジェクトは別に用意する。

感じたこと

混血児はたまに作ってしまうので気をつけようと思った。
あと、手続き型のメリットに触れられていてなるほどなと思った。