「オブジェクト指向でなぜ作るのか」の書評になります。
一言でまとめるとプログラミングが好きになる本です。
オブジェクト指向で作る理由がわかる本ではないの？
...甘い！
もちろんオブジェクト指向で作る理由もわかります。プログラミングを楽にしてくれるんです。
でもそれ以上にオブジェクト指向がいかに洗練された技術か、感動させられます。
全体まとめ
オブジェクト指向(以降OOP)が生まれた背景とOOPが新たにもたらした技術がまとめてあります。
下流〜上流まで広い知識を体系的に学ぶことができます。
たびたびJavaのコードが出てきますが十分に説明があります。
必要な前提知識は少なく、章ごとの内容も浅く留めてあるので初学者向けの親切な本だと感じました。
前半では実際のプログラミングをOOPで書く理由がわかります。
具体的に継承、クラス・インスタンス、ポリモーフィズムがなぜ優れているのかを説明できるようになります。
個人的にはOOPのメモリの使い方が詳しく書いてありことが良かったです。普段意識したことがなかった分得るものが大きかったです。
後半ではOOPから生まれた技術や思想の紹介になります。
設計、要件定義、チームビルディングまで書いてあるのでかなり幅広いです。すでに知識がある部分は読み飛ばして問題ないかと思います。
最後に関数型言語の紹介があります。
現在の主流はOOPと関数型のハイブリッドだから関数型も勉強しとけよって書いてあります。
勉強すること増えるのか泣、、と思いきやそんなことはありません。
なぜを理解し、歴史的背景まで教えてくれるこの本は、プログラミング技術の面白さまで教えてくれるからです。
駆け出しの自分には良書でした。
目次
1.オブジェクト指向はソフトウェア開発を楽にする技術
2.オブジェクト指向と現実世界は似て非なるもの
3.OOPを理解する近道はプログラミング言語の歴史にあり
4.OOPは無駄を除いて整理整頓するプログラミング技術
5.メモリの仕組みの理解はプログラマのたしなみ
6.OOPがもたらしたソフトウェアとアイデアの再利用
7.汎用の整理術に化けたオブジェクト指向
8.UMLは形のないソフトウェアを見る道具
9.現実世界とソフトウェアのギャップを埋めるモデリング
10.擬人化して役割分担させるオブジェクト指向設計
11.オブジェクト指向から生まれたアジャイル開発
12.オブジェクト指向使いこなそう
1~6が前半、プログラミング技術
7~12が後半、応用技術の説明になります。
また、補章として「関数型言語でなぜ作るのか」がありますがOOPの話と逸れるので取り上げません。
1-オブジェクト指向はソフトウェア開発を楽にする技術
PHP,Ruby,Python,etc...など現在の主要なプログラミング言語の多くはOOPで書かれています。それはなぜでしょう？
答えは単純、開発が楽になるからです。
ではなぜ開発が楽になるのか説明はできますか？
答えは著書で何度か出てくる
- クラス（まとめる）
- 継承（重複を省く）
- ポリモーフィズム（呼び出しの共通化）
この3ポイントが肝です。
2-オブジェクト指向と現実世界は似て非なるもの
まずOOPの理解を阻むものはなんでしょうか。
多くの人はOOPが現実の世界をプログラムの世界に投影したものと考えているからだと著者は述べています。
初心者向けの説明で現実世界の具体例を用いることが多いため、勘違いしがちですが、OOPでは現実の世界を表現できません。あくまでも現実世界のほんの一部をそれっぽくプログラムの世界に表現しているのです。
まずこのギャップを認識しましょう。
3-OOPを理解する近道はプログラミング言語の歴史にあり
OOP誕生を歴史の観点から説明しています。
黎明期の機械語に始まり、アセンブリ言語、高級言語と人間の理解できる言語の普及に伴いある問題が起きました。
一言で言うと複雑すぎたのです。もっと簡単にプログラムを書きたい。
そうして構造化言語が生まれました。
構造化言語の特徴は主に三つです
- GOTO文の廃止（可読性の向上）
- ロジックの単純化(順次実行、条件分岐、繰り返し)
- 関数の独立性（グローバル変数をローカル変数へ）
しかし、構造化言語でも解決仕切れない問題がありました。
- グローバル変数の問題
関数の独立では限界があった。 - 再利用性に乏しい
大規模アプリでは再利用できるものが少なすぎる
これらを解決したものがOOPです。
4-OOPは無駄を除いて整理整頓するプログラミング技術
さあ、OOPの3ポイントはなんだったでしょう。
1.クラス
共通の処理をクラスとしてまとめることが可能になりました。
これによりグローバル変数をインスタンス変数としてスコープに切り出すことに成功します。
また、再利用可能なパーツとなります
＊再利用パーツとして認識するために名付けは最重要です
2.継承
重複を共通化することができるようになりました。
ここで重要なのがis-aの関係です。共通化しすぎるとなんでもできる神クラスになってしまいます。
さらに、インターフェースを統一化することができるようになったので次に示すポリモーフィズムが可能になります。
3.ポリモーフィズム
呼び出し方を統一することが可能になりました。
呼び出す側は呼び出し方さえ知っていれば具体的に何を呼び出すかを知らなくていいです。
つまり抽象クラスに対してのみの知識を与えてあげればいいです。逆に具象クラスはあまり呼び出さないようにしましょう。
5-メモリの仕組みの理解はプログラマのたしなみ
メモリ領域は3つに分かれています。それぞれOOPでの割り当てが説明されています。
1.静的領域（プログラムの終了まで固定）
グローバル変数や実行コードを格納。
2.ヒープ領域（動的に割り当てられ、ガベージコレクションにより削除）
インスタンスを格納。
メモリリークの原因は主にここ。
3.スタック領域（スレッドごとに割り当てられる）
スタックに実行単位ごとのメソッドが格納される。
6-OOPがもたらしたソフトウェアとアイデアの再利用
ここまで読むとOOPがいかにプログラミングを楽にするかがわかったと思います。
OOPの仕組みはひとつのアプリケーションにとどまらずライブラリとして再利用されたり、
アイデアとして上流工程に再利用されるようになります。
7-汎用の整理術に化けたオブジェクト指向
後半では実際にOOPが上流工程に生かされている例を見ていきます。
なぜOOPがプログラミング言語に止まらなかったのか、それはOOPが「汎用の整理術」としての側面を持っているからです。
8-UMLは形のないソフトウェアを見る道具
UMLはUnified Modeling Languageの略で日本語では統一モデリング言語と言います。
簡単に言うと「図」の書き方です。*設計でよく使われるやつです
例）
・クラス図
・シーケンス図
・ユースケース図
など13の表現が規定されています。
これらはコンピュータ言語で書かれた処理を直感的にわかりやすくするために用いられます。
あくまでも補助手段でありUMLでうまく表現できないことも多くあります。
9-現実世界とソフトウェアのギャップを埋めるモデリング
一度述べましたがOOPは現実の世界を表現できません。
つまり、全ての仕事をコンピュータが肩代わりすることはできないのです。
モデリングの流れは業務分析を通してコンピュータに任せられそうな仕事を切り出す（要件定義）。
そして設計していきます。
10-擬人化して役割分担させるオブジェクト指向設計
設計のコツがまとめられています。
中でも重要なことは、「依存を循環させない」ことです。
依存の循環とは以下のようなものです。
悪い例）
部品a->部品b
部品b->部品c
部品c->部品a
これでは全てが依存関係にあるので再利用したい時に3つともまとめて利用しなければなりません。
良い例）
部品a->部品b
部品b->部品c
部品a->部品c
矢印を一つ変えただけですが、部品cからの依存を断ち切れたのでcの再利用が楽になります。
11-オブジェクト指向から生まれたアジャイル開発
OOPを覚えただけではソフトウェア開発は成功しません。
ここではアジャイル開発の代表的なプラクティスを三つ紹介します。
- テスト駆動開発（TDD）
- リファクタリング
- 継続的インテグレーション
12-オブジェクト指向を使いこなそう
OOPの登場は実は1967年、かなり昔からある技術なのです。
そんな歴史のあるOOPがこの先廃れることがあるでしょうか、いやありません。
この先新たに生まれるいかなるプログラミング言語もOOPの延長線上に存在するものなのです。
つまりOOPを学んで損はないと言うこと。
これからも良いOOPライフを送りましょう！