オブジェクト指向をわかりたいなら今すぐ『オブジェクト指向でなぜつくるのか』を読め

オブジェクト指向の入門書と言えば『オブジェクト指向でなぜつくるのか』に決まってるよね、と話していたら、「ええ、そうなんですか?」と、この本に推薦のことばを寄せていた平鍋さんの会社の人に言われてショックでした。ちょっと駄目すぎです。角谷さんなんとかしてください(<無茶振り)。

オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識―

オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識―

私もご他聞に漏れず、オブジェクト指向の本はいろいろ読んでみたのですが、『オブジェクト指向でなぜつくるのか』に勝る本は内外合わせてまだお目にかかれていません。率直に言ってプログラマ必読書だと思います。

その素晴らしさは随所にあるのですが、章立てに追って説明しましょう。

1.オブジェクト指向はソフトウェア開発を楽にする技術

まず、WhatではなくWhyが導入されます。なぜオブジェクト指向が重要なのか? それは、ソフトウェア開発を楽にしてくれるから。
さらに重要な視点として、「プログラミング技術としてのオブジェクト指向(プログラミング)」と、「ソフトウェア開発の総合技術としてのオブジェクト指向」、という二つの視点が導入されます。歴史的には前者が先行したものの、現在では後者も発達してきている。この分割は章立てにも反映されていて、6章までが前者の話、7章以降が後者の話です。後者のOOは認めない、というプログラマの方もいらっしゃいますが、そういう人は前半だけ読まれれば、お気に召すんじゃないかと思います。

とはいえ、楽にするはずの技術が、難しいと言われてしまっている現状があります。その理由として、筆者は3つの理由を挙げます。

  • 用語の洪水(耳慣れないカタカナ単語も含めて謎単語が多数導入されてびっくり)
  • 比喩の乱用(動物とかは虫類とかほ乳類とか。プログラミング技術の理解としては有害になりかねない)
  • なんでもオブジェクト症候群(「世の中なんでもオブジェクト」的な極端な抽象化。「オブジェクト指向を使えば現実世界をそのままプログラムに表現できる」との誤解を助長)

これらをさけるために、筆者は用語や比喩は最小限にし、さらにプログラミング技術(OOP)と分析/設計技術(OOA/OOD/開発プロセス)を分ける、という方針を宣言します。

なんかもうこの辺りで類書と一線を画すというか、安心感が違いますね。これならバカ行くのひとにも安心して勧められます。

2.オブジェクト指向と現実世界は大違い

ここもまだ導入ですが、重要な章です。最近では批判の多い、犬猫が鳴く例で継承やポリモーフィズムを説明するやつですが、あれを6ページくらいかけて実践した上で、そういった比喩が比喩以上のものではないことを指摘し、現実世界とオブジェクト指向の同一視を「やはり無理があります」と一刀両断します。そこまでやるか。

まあ何も知らない人は読まなくてもよい章かもしれませんが、犬猫で混乱されてしまった人にはよい解毒剤になるでしょう。ここまでていねいかつきっぱりと批判したものは少ないんじゃないかと思います。教育的な姿勢がうかがえます。

3章 OOPを理解する近道はプログラミング言語の歴史にあり

いよいよ本論に入ってきました。

この章では、プログラミング言語は「素朴な言語」→「構造化言語」→「オブジェクト指向言語(OOP)」という流れで進化してきたことに触れ(いやまあこれ以外の流れもありますが手続き型言語の発達史ということで)、構造化はそれ以前の、そしてOOPは構造化の課題を解決するために生まれた、とします。それを受けて、この章では、構造化言語が解決した課題と、残された課題を説明します。

機械語からアセンブラ、そして高級言語という流れは、プログラミングを容易にしてきましたが、保守性や品質確保、再利用性という面ではあまり高くないものでした。これらを阻害する要因として、構造化プログラミングの立場は二つの存在を批判します。

どちらも大域的に働く機構のため、プログラムの理解のために全体を見なければいけなくなってしまいます。このため、構造化では、逐次/分岐/繰り返しの三要素による表現とGOTOの廃止を行い、さらにサブルーチンとローカル変数+変数の引き渡し(=関数)、という技術を導入し、モジュール化を進めました。

しかし、それでもまだ解決できない問題がありました。関数(サブルーチン)内部でしか使わない変数はローカル変数にできますが、関数をまたいだ変数の共有にはやはりグローバル変数を使わざるを得ない(引数で渡せばいいけどそうすると引数だらけになる)、そしてサブルーチンは便利だけど粒度の大きい再利用可能なモジュールは作りにくい(単なる関数の集合では辛い)、といった点です。

このグローバル変数と再利用性の2つを解決するものがOOPである、という予告が出て、次章に続きます。

4.OOPは無駄を省いて整理整頓するプログラミング技術

いよいよOOPの説明です。前章からどんな展開になるかは予想がつくと思いますが、順を追って説明します。

本章ではOOPのうち、クラスの特徴を3つにまとめます。

  1. サブルーチンと変数を「まとめる」
  2. クラスの内部だけで使う変数やサブルーチンを「隠す」
  3. 1つのクラスからインスタンスを「たくさん作る」

1.はいわずとしれたカプセル化なわけですが、そのご利益として「メソッドが探しやすい」「名前をつけやすい」を挙げています。名前重要。わかってる感がします。

2.は情報隠蔽なわけですが、単に隠すというだけではなく、隠したいところと共有したいところの切り分けが提示されます。単に隠すだけなら前章で導入されたローカル変数でよいわけで、そこまで隠しすぎない、というところがポイントでしょう。

3.はインスタンス化の話なのですが、ここでは変数の空間をインスタンスごとに作れることに力点が置かれます。ここのサンプルはファイルの読み書きクラスなのですが、インスタンスを使うと、ファイルポインタを指す変数をファイル処理オブジェクトごとに確保できるので、複数オブエクトを作ってそれぞれファイルを開いても、変数に配列を導入したりする必要もなく干渉しなくてすむ、という利点が具体的に示されます。

この3つ(主に後者2つ)から、インスタンス変数の利点が語られます。前章ではグローバル変数とローカル変数について説明されましたが、インスタンスはその中間に位置します。この説明として、インスタンスは「長持ちするローカル変数」あるいは「仲間内だけのローカル変数」である、と看破します。

さらに、ポリモーフィズムが説明されます。このポリモーフィズムの説明も秀逸で、いろいろなところから呼ばれるサブルーチン、いわば共通サブルーチンは呼び出される側を共通化するものであるのに対し、ポリモーフィズムは呼び出す側を共通化するもの、すなわち「共通メインルーチン」である、とします。

また、継承については、「重複を省く」ためのプログラミング技法としてあっさり説明されます。

そして、静的な型チェックの有用性の話や、OOPをさらに発展させた機能として、パッケージ、例外、GCの話がされます。まあこれはこれで。

というわけで、本書のOOP編の、というよりも本書全体の山場と言ってもいいでしょう。前章までの整理と合わせて、実に分かりやすくオブジェクト指向プログラミングについて説明されます。特にインスタンス変数が、ローカル変数とグローバル変数の中間の存在であること、すなわちOOPの解決したかった課題とはスコープの問題であり、柔軟なスコープを導入するためのプログラミング技術であったことがあきらかになるあたりは、今まで構造化とOOPの連続性が見えなかった人もすっきりすると思います。

この後には、各OOP言語に合わせてさらなる展開を行うことも可能ですが、その土台としては必要十分な説明を尽くしていると言えます。

5.メモリの仕組みの理解はプログラムのたしなみ

古いプログラマ感涙の章です。

OOPの理解にはメモリ管理の基礎が必要、ということで、静的領域、ヒープ領域、スタック領域がどうしたとか、インスタンスがヒープにできたり、静的領域にはクラスがいてその中にメソッドテーブルがあったりとか、その辺りの説明が大まかになされます(スタック領域の説明はあんまりしてない)。そして最後にGCの話でしめます。

いやまあ正直この説明で、予備知識のない読者がどこまでついてこれるのかよく分かりませんが、心意気は重要です。

6.OOPがもたらしたソフトウエアとアイデアの再利用

ここでは再利用性が話題の中心で、クラスライブラリやフレームワークコンポーネント、そしてその実装技術としてのデザインパターンが語れます。OOPでプログラミングする上で必要となる、比較的粒度の大きい話が語られます。まあここは知識の整理として。

7.汎用の整理術に化けたオブジェクト指向

……以降、OOA/OODとかな話が続くのですが、あんまり愛がないので章立てのみ紹介。いやまあ悪くはないと思いますよ(<このあたりが愛のない感じ)。

8.UMLは形のないソフトウエアを見る道具

9.現実世界とソフトウェアのギャップを埋めるモデリング

10.擬人化して役割分担させるオブジェクト指向設計

11.オブジェクト指向から生まれた柔軟な開発プロセス

12.オブジェクト指向を使いこなそう

あ、でも、11章のコラムはいいかも。「昔は許されなかったXP」という題で、XPなどの開発プロセスはハード・ソフトが安価になったためにできる手法であって、開発プロセスは環境の制約を受けることがよく分かります。

12章はまとめ的な章で、時代がオブジェクト指向に追いついてきた、そしてブームには終わらない、知的なプログラミングを楽しもう、という前向きに幕を閉じます。

以上、気づいたら大量に書いていましたが、もちろんこれだけでは本書の魅力は尽きません。実際に手に取って読んでみないと。

そんなわけで、ある程度プログラミングの経験があるひとで、オブジェクト指向っていまいちよくわかんないんだよね、というひとは、ぜひ本書をおすすめします。ていうかプログラマなら読め。