本投稿は書籍『オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方』を読んだ際にまとめた備忘録です。
###オブジェクト指向設計とは「オブジェクト同士の依存関係を管理する」こと
【オブジェクト】
=>「それぞれが自身の振る舞いを持ち、そして互いに作用し合うもの」
【アプリケーションの設計が解決する問題】
=> アプリケーションの変更を容易にする
【アプリケーションの変更が困難な理由】
=> オブジェクト間の依存が変更の邪魔をする
【オブジェクト間の依存】
=> 部品Aが部品Bを「知っている」という状態のこと
=> 相手にメッセージを送るためにはこの「相手を知っている」状態である必要がある
【設計の実用的な定義】
=>「未来を受け入れるための選択肢を保護する」もの
=>「あとにでも」設計をできるようにすること、第一の目標は変更コストの削減
###オブジェクト指向の設計者の道具 = 原則とパターン
【設計原則】
=> SOLID
1.単一責任(Single Responsibility)
2.オープン・クローズド(Open-Closed)
3.リスコフの置換(Liskov Substitution)
4.インターフェース分離(Interface Segregation)
5.依存性逆転(Dependency Inversion)
【設計（デザイン）パターン】
「オブジェクト指向ソフトフェア設計において遭遇する様々な問題に対して、簡単でかつ明瞭な解を与える」ものであり「設計プロダクトの柔軟性、モジュール性、再利用性、および理解のしやすさをより高める」ために使えるもの
【設計が失敗する原因】
1.設計が十分でない <= 設計が失敗する最初の原因
2.「良かれと思って設計しすぎる」 <= 多少の経験を積んだプログラマの失敗
3.設計の行為と実装の行為が乖離した時 <= 設計とは漸進的な発見のプロセスであり、繰り返しのフィードバックを頼りに進んでいくもの
【設計を行うタイミング】
=>詳細設計はしない。小さな追加の繰り返しで作っていくべきで、開発を繰り返すことで本当に必要なものに近づけていく（アジャイル開発？）
*詳細設計
=>提案されたアプリケーションのすべての機能、想定される未来の内部動作をすべて特定し、完全に文書化したもの
【詳細設計における問題点】
=>本当に必要な機能は作っていく中で新たに見つかるもので、詳細設計のような事前に考えたものでは本当に顧客に必要なものを満たせない
【「設計を判断する」】
=>設計の損益分岐点に従ってその程度を判断すること
例)
初学者の場合 => 設計努力をする意味はほとんどない
熟練者の場合 => 設計努力の意味は濃い
=>設計者の目標は、機能あたりのコストが最も低い方法でソフトウェアを書くことであり、この決断は「プログラマのスキル」と「結果が出るまでの時間」による
###オブジェクト指向/オブジェクト指向設計の理解しやすい方法を考える
様々な書籍でオブジェクト指向について触れられていますが、よく見かけるのが「オブジェクト指向は手順ではなく操作するように扱えるもの」「ものとして扱う」みたいな記述が多くて「ん？」となることもあったので、自分なりの例をあげて今回のオブジェクト指向/オブジェクト指向設計の理解を確認してみます。
オブジェクト指向はサッカーゲームを例に考えてみると、理解しやすい気がします。
オブジェクトA = 操作する選手
オブジェクトB = 自チームの操作している以外の選手
オブジェクトC = 敵チームの選手
オブジェクトD = 観客
オブジェクトA~Cの振る舞い = パス、シュート、ドリブル、ダッシュ、クリア、スライディングタックル..etc
オブジェクトDの振る舞い = オブジェクトAが所属するチームを応援する
オブジェクトAは味方であるオブジェクトBにはメッセージは送れる（Bにパスする、等)
オブジェクトCは敵であるオブジェクトAにメッセージを送れる（Aにスライディングタックルする、等）
オブジェクトAは観客であるオブジェクトDにはメッセージを送れない（Dにパスする、等）
⇨選手であるオブジェクトAは観客であるオブジェクトDについての知識は持たせる必要はない