「オブジェクト指向設計実践ガイド 第1章」 まとめ
はじめに
「オブジェクト指向設計実践ガイド」 第1章 を
自分なりに要約してみました。
第1章 オブジェクト指向設計
世界は時の流れの中で出来事が順番に起こる「手続き的」でありながら、様々なオブジェクトに関わりがある「オブジェクト指向」でもあります。
オブジェクトの世界では「自動車」が複数の「自動車用部品」で構成されているように
それぞれのオブジェクトが振る舞いを持ち、予測可能な相互作用をする場合もあれば、
「人」と「猫」の間で起こる出来事のように
各オブジェクトの新しい組み合わせが自然に現れることもあります。
主題であるオブジェクト指向設計では発想の転換が求められます。
世界をあらかじめ決められた手続きの集まり（手続き的）ではなく、オブジェクト間で受け渡されるメッセージの連続として捉えられる視点を持つことで自然にオブジェクトの世界へ没入できるでしょう。
設計の目的
ソフトウェアはある目的があって作られるものです。そのソフトウェアを生み出すための費用対効果に優れた方法を考えることになりますが、
オブジェクト指向設計は「費用対効果の高い」ソフトウェアを生み出せるだけではなく「楽しく取り組めるコード」も実現できます。
設計で変化に強いアプリケーションにする
一度作られたアプリケーションは常に変化が求められます。
変更が容易なアプリケーションは柔軟で拡張しやいものですが、その逆は変更のたびに変更にかかるコストが上がります。
以下４つを考慮した設計にすることで「あとにでも設計できる」構成となり、変更コスト削減にもつながります。
①変更を難しくする理由
オブジェクト指向アプリケーションは複数の部品(オブジェクト)で構成されており、その部品の相互作用で動いています。
オブジェクト間の相互作用には正しい「メッセージ」を正しい「オブジェクト」へ届ける必要があります。「メッセージ」は「受け手のオブジェクト」と「送り手のオブジェクト」を知る必要があり、その依存関係が変更を難しくします。
②オブジェクト指向設計で依存関係を管理する
１つのオブジェクトを変更するとそのオブジェクトに依存するオブジェクトにも影響を及ぼします。
設計がないと依存関係により、他のオブジェクトにも変更が必要になります。
オブジェクト指向設計はその依存関係を管理することです。
③設計が難しい理由
アプリケーションはコードの集まりです。コードの構成こそが「設計」ですが、
プログラマーが２人いる場合、2人とも設計について共通の認識を持っていたとしても２人の書いたコードが同じコードになることはありません。
④実用的な設計で未来を受け入れる
コードを書く際は未来を考慮し、変更を受け入れられるコードにしなくてはなりません。
実用的な設計とは
アプリケーションに何が起こるか未来予測するのではなく、未来の変化を受け入れられるための選択肢(余地)を設計者に残すことです。
設計の道具
設計は決められたルールがあるわけではなく、
オブジェクト指向プログラマーはコード書いている間、仕事を楽にするコード編成に気づいていきます。その経験を定量化したものが以下の「設計原理」と「デザインバターン」です。
①設計原理
- 単一責任(SOLID)
- オープン・クローズド
- リスコフの置き換え
- インターフェース分離
- 依存性逆転
- DRY
②デザインバターン
設計原理に加え、Gang of Four(GoF)と呼ばれる４人の著者が1995年に書いた「Design Patterns」という本もあります。
設計はいつ行うか
顧客は自身の求めるアプリケーションを実際に見るまではっきりと分からないものです。
アジャイルの考えからすると
顧客と一緒に小さな開発の繰り返しを行っていき、徐々に顧客の理想に近づけていくのがベストですが、前もって全体の詳細設計(BUFD:Big Up Front Design)と完成時期を求める顧客に対し、アジャイル開発の提案は難しいかもしれません。
アジャイルでは「全体の詳細設計」ではなく、繰り返し開発（１スプリント）での小さな領域に関心を向け、オブジェクト指向設計していきます。
Discussion