oop-practice

オブジェクト指向プログラミングの練習用

参考: オブジェクト指向設計実践ガイド

メモ

単一責任

• クラスを一文で説明できるか？

  • できなければ、責務を持ちすぎている可能性が高い
  • 「それと」「または」は危険信号

• インスタンス変数は直接参照しない

• 単一責任のリファクタリングは最終的な設計がわかってない段階でもやるべき

  • むしろ、わかってないからこそやるべき

• コードにコメントが必要なら、そのコードを別のメソッドに抽出する合図

依存関係

• 依存関係のサイン: オブジェクトが以下のものを知っている

  • 他クラスの名前
    • 他クラスへの依存は隠さない。いつでも取り出せるようにわかりやすくしておく
  • self以外へのメッセージ
  • メッセージが要求する引数
    • その順番

• テストはコードに依存する

  • テストコードがコードに過度に依存しすぎていると、リファクタの度にテストが壊れる

• 依存性注入

  • ダックタイピングで依存性注入サンプル

• 依存の方向

  • より変更の少ない方へ依存させる
  • 具体→抽象

インターフェース

• ドメインオブジェクト

  • データと振る舞いを兼ね備えた名詞
  • オブジェクトではなく、オブジェクト間で交わされるメッセージに目を向ける

• シーケンス図

  • ドメインオブジェクトの関係を示すのに役立つ
  • オブジェクト間のメッセージが適切かどうか判断するのに役立つ
  • 検証するためのもので、破棄するもの。破棄されるという性質もシーケンス図の機能の一部

• クラスではなく、メッセージに基づく設計にする

  • メッセージを送るためにオブジェクトは存在する

• コンテキストは単純にしておく

  • 複雑なコンテキストを持つオブジェクトは再利用性が低く、テストもしづらい

デザインパターン

プログラムを完成品として見ない

書いて終わりではなく、今後

• 機能を拡張していく
• 変更を加える

ものとして考える

Adapterパターン

Template Methodパターン

• 抽象クラスに振る舞いを記述することで、サブクラスの振る舞いを固定できる

Factory Methodパターン

• Tempalte Methodパターンをインスタンス生成の場面に適用したデザインパターン
  • 抽象クラスをフレームワークとして使う