[#31] オブジェクト指向「的」な話

初出: MacPower 2003年 2月号

俺がまだプログラミングの仕事で飯を食う前のことだが、プログラマー35歳定年説[*1]という話を聞いたことがある。プログラマーは頭の回転が悪くなるとやっていけないので、仕事ができるのは35歳が限界という説らしい。もちろん、いまはそんなことを言う人はいない。俺の定年を延ばしてくれたものはいくつかあるが、その1つはオブジェクト指向だ。今月はこれをテーマにしよう。ただし、あくまでオブジェクト指向「的」な話。

そもそもオブジェクトって何だろうか？訳すと「モノ」だ。モノに指向している、つまりモノを中心とした考え方というのがオブジェクト指向。これじゃまだわからない。モノって何だ？

われわれはモノに囲まれて生活している例えばテレビ。その中身がどうなっているかを知らなくても、チャンネルを変えられるし番組も映る。テレビに対する操作と、それによって得られる結果さえわかっていれば、細かいことは何も考えずに済む。そういうものを「テレビ」と名付けて使っている。
何かがあって、その内側の仕組みは詳しくわからないけど、何をしたらどうなるかは知っている。そういうモノはそういうモノとして使えばいいじゃないか、名前さえ知っていれば細かいことはわからないままでいい。これが、オブジェクト指向的な考え方だ。

ちなみに、このオブジェクト指向的な考え方をコンピューターに取り入れた偉大な例が、MacのFinderに表示されるアイコンだ。毎日、何げなくアイコンをダブルクリックしているが、それが書類でもアプリでもフォルダーでも、それなりの動作をする。アプリなら当然起動するし、フォルダーならその内容が現れる。書類なら、その書類を作ったアプリでちゃんと中身が表示される。だからユーザーは、深く考えることなしに直感的な操作ができる。ファイルをアイコンで表すという手法は、とてもオブジェクト指向的なソリューションなわけだ。

モノを境にして、使う側=ユーザーと作る側・整備する側=裏方に分けられるというのも、オブジェクト指向的な発想が生み出す便利さだ。自然界のモノは別にして、人によって作られたモノならば、使う人とは別の誰かが作り出してメンテナンスしてくれるはず。テレビを使うのは俺だが、テレビが故障したときに直してくれるのは街の電気屋さんなのだ。モノを境界として、責任の範囲が明確になる。それは、モノとしてできることを定義することで可能になるわけだ。

また、モノを単なるモノとして割り切ってしまうと、それを使っている人には何の影響もなく裏方が中身を変えられる。テレビといえば、これまでブラウン管が組み込まれたモノだったが、最近では液晶やプラズマも当たり前になってきた。それに伴って中身も変わっているのだろうが、使う側にとっては単なるテレビでしかない。モノに名前を付けるということは、こうした便利さも生むわけだ。

さて、オブジェクト指向プログラミング言語に話を移そう。この考え方が手法として確立したのは '80年代、実用的になったのは '90年代半ばだ。それまでプログラマーは、あまりオブジェクト指向的な考え方をしてこなかった。プログラム全体の責任を負っていて すべての整合性を保ちながらプログラミングしないといけない、と思われていたのだ[*2] 。テレビの例でいえば、電源からブラウン管の中身、基板や配線、電波の状態など全部を理解しないと野球中継すら見られない、ビール飲みながらゆったりなんてとんでもない、そんな状態だったわけだ。だから、プログラムの規模が大きくなると全体の把握が難しくなり、破綻していくことになる。

で、オブジェクト指向的な考え方をどんどん取り入れることによって、こうした状況は改善されていくことになる。自分が書いているプログラムの機能を定義し、｢こんなことができます」「そのためにはこうしてください」｢そんなことは知りません」･････といったことを明確にする。これにより、大きなプログラムを細切れにして、それぞれを独立性の高い部品と見なそうということになったのだ。部品となると、それには何かしらの名前を付けることができる。実現可能なことが明確になり、モノとして名前が付けられるぐらい抽象度が増せば、プログラムをアイコンとして絵的に表示することができる。プログラムが部品として、見た目にも独立するわけだ。こうしてオブジェクト指向的な考え方は発展してゆき、「Interface Builder」のような優れた環境が生まれたのだ。

考えてみれば、プログラマーという職業自体が裏方だ。誰かのためにモノを作るという意識がある。だから、自らが使う側になって楽をするということをあまり真剣に考えなかったのかもしれない。しかし 同じ裏方の電気屋さんだって、ブラウン管やチップの中身までは知らないだろう。俺はテレビを1つのモノとして、電気屋さんはその中のブラウン管やチップをモノとして、ブラウン管を作っている人は･･････、と続いていくわけだ。1つのモノも裏を返すとたくさんのモノからできている。複数のモノを組み合わせて、大がかりなモノが作られているのだ。

部品に分けると分業もしやすい。数人のプログラマーが同時に1つのモノを作る場合と、部品に分けてそれぞれの作業を別々に担当する場合を比べると、当然ながら後者のほうがモノの質はよくなる。また責任も明確になる。オブジェクト指向は共同作業にも向いているのである。何しろプログラマーとはいえ、普通に物忘れをする。1週間前に書いたプログラムを見直してみると、まるでわからなかったりすることもある。1人でやるプログラミングでさえ、昨日の俺と今日の俺の共同作業とも言えるのだ。オブジェクト指向的に考えると、「明日の俺のために、この部分は部品化しておこう」というふうに思うようになる。これが、35歳で定年を迎えないための工夫の結果なのだ。それだけじゃないんだけどね（笑）。

バスケ
屋久島なんか行っちゃうと、リフレッシュしすぎて仕事がはかどりませんねぇ（笑）。いや、密度は濃くなっているんだけど、そんな頑張らなくてもいいじゃん、なんて思うようになっちゃって。いかんいかん。でもおかげで、落ち着いた年末を過ごしてます。

[*1] プログラマー35歳定年説 - ちなみに俺は今年35歳。定年は迎えていません。
[*2] 思われていたのだ - 別に、社会全体がプログラマーに興味を示していたわけではないので（笑）、自分たちがそう思いこんでいたわけだ。

編集･三村晋一