オブジェクト指向再燃（中編）
オブジェクト指向は、アラン・ケイがsmalltalkの言語設計する際に提唱したソフト
ウェアとプログラミングのパラダイム（ものの見方やとらえ方）で、シミュレーショ
ン用途のプログラミング言語であるsimulaの考え方に感化された学生時代のアラン
がプログラミング・アーキテクチャの思索の際に思いついた言葉だとされています。
オブジェクト指向のパラダイムは、データとプロセスを個別に取扱わずに、オブジェ
クトとして一体化し、それぞれのオブジェクトがメッセージを介して相互作用を起こ
すことで、ソフトウェア全体を構築しようとする考え方です。
例えば自動車は、アクセスを踏み込む、ハンドルを切る、ブレーキを踏む、という運
転者からのメッセージを受取って加速したり、右に曲がったり、止まったりします。
アクセルを踏むとエンジンに流れ込むガソリン量が増えてエンジンの回転が上がりそ
れがタイヤに伝わって加速します（プロセス）が、実際の加速結果はエンジンの性能
や車体の重さ（データ）によって変わってきます。しかし運転者はプロセスやデータ
を意識することなく、アクセルを踏むという与えたメッセージの結果、自動車がどれ
だけ加速したかという作用を判断して、さらに加速させるべくアクセルを踏むのか、
加速しすぎたのでブレーキを踏むのか等、次のメッセージを自動車に送ります。自動
車というオブジェクトはプロセスとデータが一体化しており、メッセージを介して運
転者（これもオブジェクト）と相互作用を起こすのです。
この様にオブジェ指向のパラダイムは現実世界と近いものになっています。これはも
とになったsimulaがシミュレーション用途であり、シミュレーションは現実世界の事
象をモデル化して計算機で将来を予測することを目的としているからに他なりません。
それゆえ、オブジェクト指向のパラダイム自体はとても認知しやすくソフトウェア技
術者でない人でもオブジェクト指向のパラダイムをイメージすることは、そんなに難
しくはないでしょう。
しかし一方で、この現実世界をモデルにした認知しやすいパラダイムが逆に技術者を
混乱させるとも感じています。シミュレーション系のソフトウェアは良いのですが、
ソフトウェアはそれ以外に業務系もあれば制御系もあります。この業務系や制御系の
ソフトウェア開発においてオブジェクトをどう定義すればよいか、モデル化するか、
ということがオブジェクト指向において最も難しく誤解されている点ではないかと思
います。
例えば業務系の在庫管理システムを開発しようとした際に、オブジェクトはどの様に
定義されるのでしょうか。
在庫管理業務における実在物としては、倉庫の中に棚があり、その上に管理対象のと
なるモノ（製品や商品）がずらり並べられています。そのためモノの種類毎にクラス
を定義しインスタンス化すれば、倉庫の中の個体が表現され実在物を表すモデルが出
来上がります。在庫数を知りたければインスタンス数をカウントすればよい。
一見このモデルは正しい様に思えますが、実のところ間違っている可能性が大です。
何故でしょうか。このモデルでは倉庫の中の実在物はモデル化されていますが、本来
在庫管理業務で使おうとしている在庫管理システムとしての役割が果たしているとは
いえないからです。在庫管理業務とは、「いつ」「誰が」「何（モノ）を」「何個」
「入庫した／出庫した」という記録から、今、倉庫の中にはモノが何個ある、という
ことを保証するものです。言い換えると倉庫の中にあるモノがどのような性質である
か、ということについてはあまり問題にしません。「何が何個」さえわかればよいの
で、名称や番号だけで充分です。
ではどうすればよいか。
まず、「入庫」や「出庫」というインターフェースを持ちます。これは、在庫管理シ
ステムの利用者からメッセージを受け取るものです。利用者は、倉庫の管理者（ヒト）
が画面から入力する場合もありますし、受発注システムや生産管理システムなど、
別のシステムが利用する場合もありますが、いずれもオブジェクトです。在庫として
現在倉庫の中に何が何個あるかはデータです。インターフェースを介して何を何個、
倉庫に入れた、倉庫から出した、というメッセージをもとに在庫数データを増やした
り減らしたりします。これがプロセス。必要に応じて単価の洗替も行います。
利用者にとっては、入庫したモノ、出庫したモノをメッセージとして渡して、必要に
応じて在庫数や単価の問合せができればよく、在庫の増減や単価の洗替をどのように
計算しているかは知る必要ありません。
この様に、実在物を見れば倉庫があり、棚があり、在庫があり、働いている人がいま
す。しかしいくらオブジェクト指向だからといって、実在物を見たままオブジェクト
化しても何かができるわけではありません。必ず何を作りたいか、作ったもので何を
実現したいかという観点をもとに、現実世界を電脳世界へと焼き直さないといけない
のです。この焼き直し作業は「理解」「分解」「再構築」という手順で行われ、「理
解」から「分解」。「分解」から「再構築」という過程をモデルを使って考察します。
この一連の思考と作業を「設計」と言います。いわゆるオブジェクト指向分析や、
オブジェクト指向設計などといわれる領域です。
そしてこの先、「再構築」したモデルをプログラミングしてソフトウェアにしなけれ
ば実際に使うことはできません。この、モデルからプログラミングしてソフトウェア
を生成する作業を効率よく進めることができる道具がオブジェクト指向対応の言語、
ということになります。そして、設計からプログラミングまで、オブジェクト指向と
言いうパラダイムで統一しているからこそ、アジャイル開発のような設計とプログラ
ミングと検証がまとめてすすめられる開発方法が実現できるのです。
よくオブジェクト指向の肝は「クラス」「継承」「カプセル化」「ポリモーフィズ
ム」と書かれた教科書を目にします。それはそれで間違いはないのでしょうが、一
方でパラダイムをきちんと説明している教科書は少ないように感じます。「クラス」
「継承」「カプセル化」「ポリモーフィズム」はパラダイムを実現するために必要な
方法にすぎません。それとモデル化については説明が足りていないどころか、間違っ
た例題をだしている教科書も散見されます。
例えば「人」「犬」「梯子」「机」の絵があって、これをクラス化しなさい的な例題
で「動物クラス」と「道具クラス」ができます的な回答。分類としてはそうかもしれ
ませんが、実は何をしたいから、何のために、という目的の設定がありません。先に
も書きましたが、目的が設定されないとモデル化はできないのです。例えば、ドロー
イングツールを作りたいしたら、動物や道具より、形状のにている二本足や四本足で
クラス化した方がマシ、ということもあり得ます。
このようにオブジェクト指向という言葉はパラダイムからモデル化、設計、言語、開
発方法論などテーマが多岐にわたります。なので話をしていても、微妙にそれぞれの
テーマがずれており、話がかみ合わない、炎上する、などという状況が起こっていた
のではないかと思います。ただそれは未成熟だった時代の話で、最近ではオブジェク
ト指向ネイティブの技術者も出てきているはず。そういった意味では、一般化され、
議論になる機会が少なくなってきたのでしょう。
ただ、ネットでオブジェクト指向を検索してもStaticおじさんが引っ掛かることは少
なくなりましたが、Staticおじさんで検索すると今でも、このネタで記事が書かれて
いるいることに驚きます。しかしだからと言って盛り上がっているわけではないので、
おそらくオブジェクト指向そのものは落ち着いていることは確かだと思います。
そんな状況踏まえ、今回はオブジェクト指向ネタを書いてみることにしました。
後編へ続く