読者です 読者をやめる 読者になる 読者になる

ravelll の日記

よしなに

"オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方" を読み始めた

2度目のパーフェクト PHP の読了を果たした一昨日から、オブジェクト指向設計実践ガイドを読み始めた。

RubyKaigi の頃あたりに 訳しました:「オブジェクト指向設計実践ガイド」 - Misoca開発ブログ のエントリを読んで気になりつつ終ぞ今日まで読むには至っていなかったのだけど、同僚の @kymmt90 が読んでいていい感じとのことだったので読み始めた。まだ2章までしか読めてないけれど、既に面白い。

もうしばらくすると仕事でガッツリ Ruby を書くことになりそうなので、そのためのリハビリも兼ねている。

今年はオブジェクト指向設計デザインパターンといった、将来つらくならない開発するための体系的な知識を付けたい気持ちがある。

理解を深めるためにも、メモを付けつつ読んでいこうと思う。

第1章 オブジェクト指向設計

1.1 設計の賞賛

  • オブジェクト指向とは依存関係を管理すること
  • 知識を持ちすぎたオブジェクトは制約が増えテスタビリティが下がるだけでなく、複製もされやすくなる
  • 実用的な設計は未来を予測・選択するのではなく、あとにでも設計ができるよう変更コストを下げる

1.2 設計の道具

  • 設計における道具は「原則」と「パターン」

1.3 設計の行為

  • 設計の行為と実装の行為が乖離した時オブジェクト指向ソフトウェアは失敗する
  • 設計はインクリメンタルに行われるべきで、アジャイル開発がはまる

1.4 オブジェクト指向プログラミングのかんたんな導入

1.5 まとめ

  • 実践は常に理論より物事を知っている
  • 実践とは配られたカードの中でベストを尽くすことの積み重ね

第2章 単一責任のクラスを設計する

2.1 クラスに属するものを決める

  • 設計はアプリケーションの可変性を保つために技巧を凝らすことであり完璧を目指す行為ではない
  • 変更しやすいコード ... "TRUE" なコード
    • Transparent: 見通しが良い
    • Reasonable: 合理的
    • Usable: 利用性が高い
    • Examplary: 模範的

2.2 単一の責任を持つクラスをつくる

  • 短絡的な再利用はクラスの目的を曖昧にし責任を増やす
  • 単一責任の原則は「クラスがすることは全てそのクラスの目的に強く関連すること」を求める
  • 何もしないことによる将来的なコストが今と変わらなければ設計の決定を延期する
    • 決定は必要なときにのみ、その時点で持っている情報を使って行う

2.3 変更を歓迎するコードを書く

  • インスタンス変数は大抵の場合アクセサメソッド等によってオブジェクトとして扱えるようにするのがよい
  • メソッドもクラス同様に単一の責任をもつべき
  • メソッドを単一責任にするためのリファクタリングは最終的な設計が見えない状況でもするべき
    • 隠蔽されていたクラスの目的が明らかになる
    • メソッドにコメントする必要がなくなる
    • アプリケーションにとって健康的なコードの書き方(再利用)を促進する
    • メソッドの移植性が高まる

2.4 ついに、実際のWheelの完成

2.5 まとめ