やったこと

• 良いコード/悪いコードで学ぶ設計入門 ~5章まで読了

学んだこと

学び

• 「技術駆動命名」という言葉と、その意味を学んだ
• 「クラス単体で動作するよう設計する」という設計指針
• 言語機能を駆使して、不正利用できないようクラスを設計することが大事
• （凝集性の観点から）むやみに共通化しない（common や util を作成しない）
  • common や util クラスに実装するのは、低凝集な処理（横断的関心事）に限ること
• Tell, Don't Ask.

気付き

• 言語機能を駆使して、不正利用できないようクラスを設計することが大事
  • 言い換えると、利用者側で変なことが出来ないよう、利用者側で出来ることを制限するよう設計する
  • ようやく、言葉に出来た感
• 「インスタンス生成」も、一つのドメインロジック
  • 「インスタンス生成」というドメインロジックが複数個所に散らばりかねない場合、factory メソッドパターンを使用して、インスタンス生成ロジックをカプセル化すると良い
• メソッドの引数が多い（特にprimitive型の引数が多い）箇所は、凝集度の高いクラスを設計できる可能性を示唆している

メモ

• 技術ベースで行う命名を、「技術駆動命名」と呼ぶ
  • 例) intValue01 のような変数名
• 「クラス単体で動作するよう設計する」という設計指針
  • 電子レンジやキーボードなど、特に初期設定せずに使えるようなイメージ
  • 不正利用できないような設計
• クラス設計とは、インスタンス変数を不正状態に陥らせないための仕組みづくりと言っても過言ではない
• 「インスタンスを複数作って、インスタンス変数を使いまわさないようにする」のではなく、「インスタンス変数を使いまわされても、大丈夫なように設計する」ように
• インスタンス生成ロジックが増えてきたら、factory メソッドパターンを使用してインスタンス生成をカプセル化する
• （凝集性の観点から）むやみに共通化しない（common や util を作成しない）
  • common や util クラスに実装するのは、低凝集な処理（横断的関心事）に限ること
• メソッドチェインは、凝集性・結合度の両観点から、不適切
  • 複数のクラスが、一連のメソッドチェインに依存する（密結合）
  • 「一連のメソッドチェインで実現する処理」が、いたる所に記述されかねない（低凝集）
  • Tell, Don't Ask.
  • メソッドチェインを分解せよ
  • 分解した一連の処理をカプセル化し、一連の処理を提供できるメソッドのみ公開せよ