みねこあさんのところで挙がっていた、 静的オブジェクト指向と動的オブジェクト指向の軽さについての話題から。

Javaは経済的事情をうまく捉えて普及した

プログラミングの効率と経済で書いているとおり、大量生産フェーズにおいては 「一部のプロフェッショナルと多数の凡庸なプログラマという取り合わせ」で開発することで その費用を抑えるということが行われます。

こうすることで、一定の品質のものを低価格で提供できるわけですが、現行のJavaEEでのWebシステムと いうものは正にこのような体制で製造されているということも、多くの人が認めるところでしょう。 これはバベッジ的な分業効果 *1 というもので、とりたてて目新しい話題ではないですが、 JavaによるWebシステムが流行ったのは、こうした経済的側面からして都合がよかったという点が大きいと思います。

要するにJavaというのは登場した1996年当時の肥大化しつつあるシステムを いかに経済的に製造するかという点で答えを与えた言語であり、 こうした経済的視点がJavaの普及の原動力のひとつであったと言えましょう。 事実、MicroSoftはJavaの改造版を作りWindows開発に利用しようとしましたし(J++ 1997年)、 ライセンス上のトラブルがなければC#(2002年)を作る必要はなく、J++がその役割を担っていたことでしょう *2。

Java以前からオブジェクト指向が存在したことは周知の通りだし *3、 Javaによってオブジェクト指向が広く使われることになったのもまた周知の通りです。 しかし、なぜ、Javaがオブジェクト指向を普及できたのか。 私が思うに、javaのオブジェクト指向がクラスの設計者と利用者の間のスキルの差を バベッジ的分業効果で肯定したからではないでしょうか。

というのは、Javaの静的オブジェクト指向というのは、クラスを設計する側の立場に立つと 非常に苦労するものなのですが、クラスを使う側には非常に楽なものなのです。 Java界隈で仕事をする会社の新人教育は、この「クラスを使うことができる」レベルまで 到達出ていればよいとされていると言って過言ではないでしょう。

この、苦労をクラスの設計者に一身に背負わせたという点で、Javaの静的オブジェクト指向は 多数の凡庸な技術者を用いて開発を仕切らなければならないアーキテクト（先に言った設計者）の支持を得、 スペシャリストが作り上げたクラス群を使うだけという凡庸なプログラマ（先に言った利用者）にも また支持されたのです。

JavaやC#といった静的型付けのオブジェクト指向言語はまさにこのような環境下で多く活用されていますね。

初級者と中級者の間の壁

しかし、これはスペシャリストである設計者と凡庸な実装者の間に厚い厚い壁を作ることとなりました。 Javaはコーディングができるという初級者と、プログラミングができるという中級者の間に大きな壁があります *4。 たどたどしいながらも、条件分岐とループを操り業務ロジックを実装するというレベルへは容易に到達できるが そこから思った通りにプログラムを作れるまでの間が遠く、人がどんどん供給されてなお「人材」は 不足していると言われ続けるのは、この壁を越えて中級者となれる技術者の少なさを物語っているとも言えましょう。

多分、その初心者と中級者とのあいだの落差が、LLと呼ばれる言語、つまるところ動的オブジェクト指向言語では なだらかな斜面となっているのではないでしょうか。 それが、動的オブジェクト指向の「軽さ」のひとつではないでしょうか。 教育的な意味で、なだらかなステップアップが望めるのがLLではないでしょうか。

さて、Javaで言ったクラスを利用できる初級者とクラスを作れる中級者・上級者との間の壁ですが、 これは、クラスの使い手が楽をできる分の揺り戻しというか、反作用と言うか、そうした類のものです *5。 より使い手に優しいクラス設計にしようとすればするほど、クラスを作る段で苦労が増えるのです。 この初級者の苦労を中級者以上が代わりに背負うというシステムが、初級者と中級者の隔たりを大きくしている。

しかし、クラスというのは作るよりも使う方が回数が多いのが通常ですから、作る側に労力を持ってくるというのは 非常に合理的で、うまく設計されたクラスと言うのはその使用に際して間違えることができない *6。 ヒューマンエラーを機械的に排除した作りにすることができるのです。 これが、静的オブジェクト指向言語の何よりもの魅力なのです。

逆に動的オブジェクト指向言語によるプログラミングは、初級者の苦労分まで中級者以上が背負うという責務が軽い。 これが、動的オブジェクト指向のもうひとつの「軽さ」ではないでしょうか。 他人の荷物を背負って山に登る必要がない。持つのは自分の手荷物だけでいいのです。

反面、動的オブジェクト指向言語のクラスライブラリの利用は静的オブジェクト指向言語でのそれに比べ 重いように私は感じるのです *7。 自分で作ったクラスを自分で使う分には、両方とも自分ですからその重さはあまり気にならないかもしれない。 しかし、初級者を多数率いて行うような規模感の開発ではその重さが強く出てくるように思います。

それぞれの適所とは

つまり、LLというのは上級者であるスペシャリストが、多数の初心者を率いて巨大なシステムを作る ということを行うには向かないが、中級者以上が集まったチームでは非常に手軽にサービスインまで こぎつけることができるのではないでしょうか。 ネットで話題に上がるような面白いサービスというのは正にこうしたチームによって作られていると思います。 手早くプロトタイピングし、その使い心地を評価するのに非常に向いている。

逆にJavaのような静的オブジェクト指向といのは初心者の軍を率いて戦うには向いていると思います。 業務用システムのような、大量の仕様を人海戦術で捌かなければならない状況によくマッチする。 ただし、これは軍を率いる将軍の采配が非常に重要であることをも意味しています。 上が荷物を持ってくれるからこそ一兵卒は軽い荷物で行軍できる。 上が荷物の持ち方を知らないなら、兵は生きて帰れぬ戦線で戦わされることになる。

この責任の重さがJavaのオブジェクト設計の重さです。 しかし逆に、そこでさえうまくやれば、全軍を勝利に導けるという意味でもある。 Javaの静的オブジェクト指向というのは将軍の力でもって、初心者の大隊を常勝させるための技術なのだと思うのです。 私が隊長となって、動的オブジェクト指向言語で中級者による小隊を率いるならば、 まだ戦果をあげることもできるかもしれませんが、 初心者の大隊を率いて戦えと言われたら、常勝する自信がない。

だからこそ、一般には動的なオブジェクト指向言語での開発は小規模で生産性が高く、 静的なオブジェクト指向言語は大規模で生産性が高いのだと評価されるのでしょう。 この結論は個々の開発者が置かれた環境によって生産性が高くも低くもなることを意味していて、 どちらも一長一短あって、静動どちらかが絶対的に生産性が高いというわけではない。

制約の多さは管理する側には大きなメリット

静的言語の制約の多さは、制約される側の立場、つまるところ淡々と実装作業をする側としては わずらわしいものであると思うかもしれません。 それらを統括して管理しなければならない側に回ると、これほど統治に便利なものはない。 Java開発者では設計の自由を手にできている開発者は少ないと思います。 日々、降りてくる仕様書を淡々とコードにし、テストするような人員が大量動員されている。 彼らには多くの能力は求められません。つまり、簡単な重労働なのです *8。

Javaでの開発を生業として、設計の自由を手に入れて楽しい開発をしたいのであれば、 どうにかして初級者の荷物を持つ力を手にしないといけない *9。

静的オブジェクト指向言語の軽さ

静的オブジェクト指向での設計に慣れた者は、たとえ一人でプログラミングするとしても、 クラスを使う側というのは初心者であろうと失敗することができないという設計にしてしまう。 これは、神経質すぎるように思うかもしれません。 しかし、この神経質とも思えるクラス設計が、クラスを使う側に自身が回った時に幸せへと変わるのです。 つまり、自分自身さえも、クラスを使う側に回ったならば初心者のレベルまで脳みそを手抜きすることが できるというわけです。これが静的オブジェクト指向でのプログラミングの軽さなのです *10。

静的オブジェクト指向の理想は、コンパイルが通った時点でバグがなくなっていることです *11。 その強い型付けを最大限に生かし、間違えることができない型設計をすることが、後の生産性を高めます。 だから、クラスの設計が終わってしまえば、そのクラスについて忘れることが許される。 強い型システムがクラスの使い方を導出してくれます。導かれるままに使うだけでいい。 私がJavaで大量にロジックを書くことができる理由は、効率よく忘れることが許されているからに他なりません。 俯瞰視点で設計するときは細部を見ることはないし、細部を作るときには全体を見ることはない。

一度に大量にプログラミングすると自分でプログラムしたことさえ忘れてしまうことがあるぐらいに *12、 型を境目とする「契約に基づくプログラミング」は思考を分断することができるのです。 型が契約を分かりやすくし、保証をしてくれる。 契約は確かに面倒臭い。ダックタイピングは慣行に基づき契約書なしでの契約締結で楽なのですが、 逆にそれゆえに契約そのものが曖昧であやふやな感じが私は嫌なのです。

注釈

*1 チャールズ・バベッジ(Charles Babbage、1791 - 1871)

*2 J++で作られたMFCのアプリケーションはMS製のJavaVMでしか動作しない。 これはJavaの世界を二つに分断することになるとJavaのコミュニティは考え反発しました。 Javaのライセンスを持つSunとの訴訟となったが、別にSunだけが反発したわけではありません。

*3 JavaはSmalltalkやC++のオブジェクト指向の機構を参考にしています。

*4 目的を適える為の方法論を考えられる/られないという区切りでプログラミング/コーディングと

用語を使い分けています。自分のやりたいことを自分で考えてコードにできるようになって 初めてプログラミングと言えると思います。

*5 誰かの楽のためには誰かが苦労をすることになる…

*6 ただし、中級者の頃には、そのクラスの使用頻度・重要性に比べて凝りすぎたオーバースペックな 設計にしてしまいがち。でも、そうやって工夫を自分の手でやってみて設計を覚えていくのだから 教育的な視点では暖かく見守りつつ、バランス感覚を身につけるように諭さなければなりません。

*7 デバッグが困難なバグのひとつに、異常データがどこからともなく紛れ込むというのがあります。 ソースの流れを追うのに比べ、データの流れを追うのは難しい。 ( Objectよ、汝の出自を示せを参照) 動的オブジェクト指向言語で私が一番不安になるのは、オブジェクトの動的さゆえに、この手のバグに 遭遇するのではないかという不安です。

*8 ニコニコ動画で知られる、ドワンゴが2ちゃんねるで求人をした際のフレーズ。 ITmediaの記事を参照のこと

*9 設計をする自由を手に入れるとIT業界は俄然楽しくなります。技術職の本懐でしょう。

*10 情けは人の為ならず。使いやすいクラス設計を呼吸をするように無意識に出来るところまで プログラミング能力を鍛えると静的オブジェクト指向の方が楽になると私は思います。

*11 実際、業務ロジックなどの単純なものであれば1000行程度なら、2～3時間ぐらいでがーっと書いて コンパイルを通した後に2割ぐらいは1発動作します。 動作させて若干の修正というのがほとんどで、1、2回の確認でプログラミングが完了。 ただし複雑なロジックは流石にそうもいかず、JUnitのテストなどを使いつつ動かしながら完成させます。

*12 小人さんとの出会い方を参照