なぜ読もうと思ったか
私は情報系大学の3年生で、趣味でUnityを使ってゲーム開発してます。オブジェクト指向の存在と、「カプセル化」「継承」「ポリモーフィズム」の3要素についてはなんとなーくしかわからないような人です。
以前は、とにかく沢山アウトプットすることを重視してポチポチ作っていました。しかしコードレビューや共同開発を経験するうちに、私は良いコードを書くための思考回数と練習回数がちょっと足りとらんなぁ…(´·ω·`)と思い、ひとまず勉強してしっかりインプットすることを決意しました。アウトプットはしっかりインプットした後にすることにします。
オススメされた２冊の技術書を借り、読むことにしました。わりと前から読みたかった本ですが、やはり本というのはいつまでに読むか決めて一気に読まないとダメですね。
技術書のタイトルは「オブジェクト指向でなぜ作るのか 第2版」、「リーダブルコード」です。
アドベントカレンダーの順番も回ってきたので、今回は「オブジェクト指向でなぜ作るのか 第2版（以下、本書）」の読書感想文を書きました。
各章の感想
本記事はネタバレを含みます。ミスリードしていたらこっそり教えていただけると幸いです。
読み終わって、読み終わる前よりずっとオブジェクト指向のかんじが掴めましたし、好きになりました。バラバラだった知識が整頓されていく感覚がありました。この本は時間をかけて読んで良かったです。
第１章 オブジェクト指向はソフトウエア開発を楽にする技術
最初に、紹介する用語や概念は最小限にすること、比喩の使用も最小限にすること、プログラミングの仕組みと、「モノ中心」で汎用的に物事を捉える考え方は別物として分けることを方針とする説明をしてくれる章です。とても読みやすかったです。ちゃんと最後まで読み切ろうと思えました。
第２章 オブジェクト指向と現実世界は似て非なるもの
オブジェクト指向は現実世界の全てを再現するわけではない、という話をする章です。
現実世界とソフトウエアの仕組みは大きく違うということを、再三言われます。
第３章 OOPを理解する近道はプログラミング言語の歴史にあり
OOPというのはオブジェクト指向プログラミングのことです。歴史の話です。
第４章 OOPは無駄を省いて整理整頓するプログラミング技術
この辺までは授業で習って覚えてるとこです。
しかし継承は最近ほとんど使ってませんでした。
と思ったら、Unityの場合はMonoBehaviorがデフォルトの継承元なんですね。
そう言われてよく考えてみると、Photonを使った時に使ってました。
継承は、ゲームだと色んなプレイヤーや色んな敵、色んなアイテムが出てくる時に使えるようです。
第５章 メモリの仕組みの理解はプログラマのたしなみ
でたこれ、メモリ。おまえさんはよくわからんやつでした。
読んだおかげで、メモリの仕組みを全体的に理解できた気がします。
ポインタは、情報の住所という意味らしいです。
第６章 OOPがもたらしたソフトウエアとアイデアの再利用
デザインパターンが何奴なのか知ることができました。23のGoFのデザインパターン、パターン名がかっこよいです。これ使ってプログラム組んで、クールになりたいですね。
フレームワークとクラスライブラリは、どちらも再利用可能なソフトウエア部品群を指しますが、
クラスライブラリはOOPの仕組みを利用して作った再利用品、
フレームワークはたんにOOPの仕組みを利用して作ったライブラリというだけでなく、特定の木底を果たすためのアプリケーションの半完成品を指すそうです。
ちなみにゲームエンジンはWikiによると、コンストラクションキットやオーサリングツールに近いレベルまで、開発作業が汎用化されたものを指し、フレームワークとは区別されるそう。
今必要としているのは、OOPが本当に使えているかどうかを自分で見定められるようになる力なのですが、
具体的にどうコード組むかは、経験積んでくしかなさそうです。
Unityの設計に関しては、大変参考になりそうなスライドがありました。
具体的なコードも交えてのお話なので、すごく良いです。ありがたや〜。
Unity開発で使える設計の話＋Zenjectの紹介 torisoup様
第７章 汎用の整理術に化けたオブジェクト指向
ちょっと技術のお話から脱線して、歴史のお話でした。
オブジェクト指向において、
下流工程：**OOPの拡張(プログラミング技術)**の面では、現実世界とソフトウエアの仕組みは大きく違うと言えますが、
上流工程：**整理術(汎用の整理術)**の面では、OOPの都合のいいところだけ利用します。
クラスライブラリ、フレームワーク、コンポーネント、デザインパターン、UML(これは整理術も)、オブジェクト指向設計は、いずれもOOPの拡張に属するようです。
整理術のコンセプトは、集合論と役割分担です。ここでは抽象的な話ができます。集合論は、人間クラスの男クラスと女クラス、男クラスの太郎さん、次郎さん、三郎さん、というような話。役割分担は、お客さん→ウエイターさん→コックさんの順でメッセージが送信される、というようなお話です。
オブジェクト指向の全てを現実世界に例えると、わけわからんになってくるので、工程によって変えていくと良いというお話でした。
第８章 UMLは形のないソフトウエアを見る道具
UMLは、自然言語（文書、会話）とコンピュータ用言語(プログラミング言語、マークアップ言語)の欠点を補うための言語(モデリング言語)だということが書いてありました。
UMLにすると、デザインパターンが使われているのがよくわかります。
第９章 現実世界とソフトウエアのギャップを埋めるモデリング
ここでのモデリングは、UMLを使ってソフトウエアの機能や内部構造を2次元の図で表すことを指します。
業務分析：現実世界の様子をそのままとらえる
要求定義：コンピュータの性質を考慮して、肩代わりさせる仕事の範囲を決める
設計：ハードウエアの性質を考慮して、肩代わりさせる仕事の範囲を決める。
基本情報の授業でちょっと見たことがある図が沢山出てきました。ユースケース図とか、概念モデルとか。
オブジェクト指向の応用編です。
第１０章 擬人化して役割分担させるオブジェクト指向設計
時代は、実行効率より、保守性と再利用性だ！そうです。
１）重複を排除する
２）部品の独立性を高める
３）依存関係を循環させない
前にこの2,3がダメで〆切前夜のバグに苦しめられた過去があります。
こうしたソフトウエアの設計には、具体的なテクニックとある種感覚が必要らしく、
タイトルの擬人化とは、この感覚をもつために、ソフトウエア部品を擬人化してイメージしてあげると、独立性を高めることができるという話からきているようです。
第１１章 オブジェクト指向から生まれたアジャイル開発とTDD
TDDはテスト駆動開発のことです。アジャイル開発やTDDは、オブジェクト指向から生まれています。万能の開発プロセスはないので、プロジェクトに状況に合わせて先人たちの知恵を参考に実践していこうというお話でした。
第１２章 オブジェクト指向を使いこなそう
これまでのまとめの章です。
「オブジェクト指向はソフトウエアを開発するための便利な道具であり、先人の知恵が詰まったノウハウ集」です。
第１３章 関数型言語でなぜつくるのか
オブジェクト指向言語と異なるアプローチをする関数型言語のお話です。
みんな違ってみんないい。用途に合わせて使い分けましょう。