「先輩。オブジェクト指向って，結局広まったわけですよね」
「そうだね」
「なかなか普及しなかったものが広まるってことは，やっぱり何か理由がありますよね」
「もちろん。GUIが出てきたことと，なんちゃってオブジェクト指向かな」
「なんちゃって，なんですか？」
「誰もがオブジェクト指向の真髄を分かっていなければならない，ってわけじゃないってことだよ」
オブジェクト指向プログラミングは，さかのぼれば1967年に公開された「Simula-67」に端を発している。そこから考えると，オブジェクト指向の普及にはかなりの時間を要したと言える。長く低迷していたオブジェクト指向を，一気にスターダムに乗せたのは誰か。GUI（グラフィカル・ユーザー・インタフェース）の普及である。
GUIのコンセプトはオブジェクト指向
 |
| 図1●GUIはオブジェクト指向 GUIの操作方法は，オブジェクト指向の考え方に沿っている。対象を決め（オブジェクトを決め），それに対して何らかの操作を指示する（メッセージを送る）。GUIアプリケーションの記述にオブジェクト指向言語が使われるのも，必然と言えるだろう。 |
GUIにオブジェクト指向プログラミングが向いている理由は，大きく三つある。まず，GUIの操作がオブジェクト指向であること。次に，ユーザー・インタフェースの構成がオブジェクトで表現しやすいこと。最後が，フレームワークを利用することにより細々としたGUIの約束事を隠蔽できることである。
GUIの操作がオブジェクト指向とマッチしていることは，GUI登場のころから言われていた。GUIではマウスカーソルを移動し，アイコンなど目的のものの上で止める。そして，クリックしたりダブルクリックしたり，ドラッグしたりすることになる（図1[拡大表示]）。これをオブジェクト指向のコンテキストで解釈すれば，マウスカーソルを移動して止めること（ポイント）がオブジェクトの選択に相当する。そこで実行するクリックなどの操作が，オブジェクトに送信するメッセージということになる。
だからGUIアプリケーションを作るときに，ユーザー・インタフェースの個々の要素をオブジェクトとして作っておけば，プログラムと1対1に対応してわかりやすくなる。あとは，操作環境（OS）が通知する「クリックした」などのイベントを，メッセージ送信と関連づけるような仕組みになっていればいいわけだ。これに関しては実行時ライブラリがその役割を担う。
さらに個々のGUI部品を見ると，それぞれ状態を持っている。例えばユーザーが入力した文字列を保持するテキスト・ボックスは，たいてい独自のイベント・ハンドラは定義しない。すなわち“素”のまま使うことが多い。マウスを使って文字列を選択したり，キーボードから入力したりするのは，すべて共通の手続きで実行できる。だがウインドウに配置された複数のテキスト・ボックスは，それぞれ違う値を持って，保持しなければならない（図2[拡大表示]）。こういった「状態」は，変数に入れて保持することになる。この状態を保持し，それがどのテキスト・ボックスであるかを管理するのは，結構手間がかかる。オブジェクトで表現すれば一発だ。
そしてオブジェクト指向プログラミングでは，複雑なデータを表現しやすい。このこともGUIに向いている。GUIにおける一つひとつのウインドウは，非常に複雑な要素から成り立っている。このようなデータをひとまとめにして取り扱うのに，オブジェクト指向の考え方は有効である（図3[拡大表示]）。オブジェクト指向プログラミング言語では，オブジェクトのネストが可能だからだ。一つのウインドウとなるオブジェクト（Formオブジェクトのことが多い）は可変な数のGUI要素を載せられるようになっている。こういった仕組みを実現するには，オブジェクト指向言語が適している注1）。
|
|
クラス・ライブラリが約束事を隠す
そして最後がクラス・ライブラリの存在である。標準で提供されるクラス・ライブラリの有効利用がオブジェクト指向プログラミング活用のポイントだが，中でもGUIプログラム用のフレームワークは最も頻繁に使われるものだ。
オブジェクト指向言語処理系を見ると，初期のMacintosh用拡張PascalであるClasscalとMacAppを初めとして，現在のVisual C++とMFCまで，どれもフレームワークが付属している注2）。フレームワークは無意味にプログラムを複雑にしてしまうさまざまな約束事から，プログラマを解放する。後述するDelphiなどの言語処理系が手軽に利用できるのも，フレームワークのおかげである。逆に言えば，それがあるからこそオブジェクト指向言語を使うのだ。
