※週一ランチタイムの読書会 ikejirirb/POODR

やったこと

4.1 インターフェースを理解する 〜 4.3 パブリックインターフェースを見つける

memo

  • p89

    • 問題の根源はクラスが「何をするか」ではなく、「何を明らかにするか」にある
  • p 91

    • パブリックインターフェース
      • クラスの主要な責任を明らかにする
      • 外部から実行される
      • 気まぐれに変更されない
      • 他社がそこに依存しても安全
      • テストで完全に文書化されている
    • プライベートインターフェース
      • 実装の詳細に関わる
      • 他のオブジェクトから送られてくることは想定されていない
      • どんな理由でも変更されうる
      • 他者がそこに依存するのは危険
      • テストでは言及されないことすらある
    • 「変更の可能性が低いところに依存する」という考えはクラス「内」のメソッドにも当てはまる
  • p 93
    • アプリケーションに置いて「データ」「振る舞い」の両方を兼ね備えた「名詞」をあらわすものを「ドメインオブジェクト」
    • 「ドメインオブジェクト」は大きくて目に見える現実世界のものを表し、かつ 最終的にデーターベースに表されるもの
  • p93

    • オブジェクトではなく、オブジェクト間でかわされるメッセージに注意を向ける
  • p96

    • ユースケースでの名詞はシーケンス図でオブジェクトになる
    • シーケンス図はオブジェクト間でかわされるメッセージを明記する
  • p 97

    • オブジェクトが存在するからメッセージを送るのではなく、メッセージを送るためにオブジェクトは存在する
  • p98

    • 「どのように」を伝えるのではなく、「何を」を頼む
  • p100

    • 図4.5と図4.6のちがい
      • Mechanicのパブリックインターフェースのサイズが小さくなった
      • パブリックインターフェースが小さいということは、ほかのところから依存されるメソッドが少ないということ
    • コンテキストは、Tripがどこへでも来て回るコートのこと
    • オブジェクトが要求するコンテキストはオブジェクトの再利用性の難しさに関わってくる
    • 複雑なコンテクストをもつオブジェクトは使うのもテストするのも難しい
    • 100 オブジェクトがコンテキストから完全に独立していること
    • 100 相手が誰かも、何をするかも知らずに他のオブジェクトと共同作業できるオブジェクト
      • dependency injection
  • p103

    • 他のオブジェクトを信頼する
  • p 104

    • 私は自分が何を望んでいるか知っていて、あなたが何をするかもしっているよ → 私は自分が何を望んでいるかを知っているし、あなたはあなたの担当部分をやってくれると信じてるよ
    • 手放しの信頼

感想

  • 4章、まだまだ終わらない