[雑記]いい加減「車輪の再発明」の暗喩を使うのはどうかと思うが。
そもそもプログラマを含めたクリエイターという輩は、既存の車輪に我慢ならないから自分で車輪を作ってしまうような連中ではないのか？
車輪は何度も発明するな。Perlの開発者で有名なラリー・ウォールが好んで使った言葉だ。科学技術のいいところは，一度発明されたもの開発されたものはだれでも簡単に使うことができ，その恩恵に授かることができることだ。同じ苦労をしないでその結果が得られるということは，過去に積み上げたものはブラックボックスとして細部を知らずとも同じように利用できるということだ。
第7回 オブジェクト指向は「正しい」のか？──科学技術としての考察：疾走するネット・ダイナミズム｜gihyo.jp … 技術評論社
記事自体の揚げ足取りというわけじゃなくて、もういい加減、オブジェクト指向で車輪の再発明の話はうんざりだ、という個人的な感傷です。OOPをよく言う時にも、悪く言う時にも。
自分が同僚にOOPについて語る時、絶対にこの「車輪の再発明」のメタファーは使わないように心がけている。自己流のOOPフレームワークを何度か作っている自分がこのメタファーを用いても説得力が皆無だからだ。また、ある程度熟練した方達は「車輪の再発明」というのが現場でどれほど通用しないか身を以て知っている。
車輪の再発明だけど、車輪というアーキテクチャの再発明は確かに不要だと思う。知識だからだ。コピーできてしまう。しかし車輪というアーキテクチャを実装する為の実際の「モノ」、構成要素は実際に千差万別に設計、製造しなければならない。砂漠を走る戦車の車輪を設計・製造した人達に、市街地を走る軽自動車を見せて「車輪の再発明」と指摘してもナンセンスだ。
そういう意味では「車輪の再発明」という暗喩にふさわしいのはむしろプロトコルなどの「仕様」や、コンピュータアーキテクチャの「設計思想/技法」ではないのか、とも思う。今更HTTPに変わる新しいプロトコルを開発したところで、HTTPを扱うブラウザがこれほどまでに普及した現在、それを塗り替えるほどのプロトコルを考案することは大変難しいだろう。
だが、時にはそのレベルの「再発明」を実際にやってのけてしまう連中が居ることも確かだ。別にプログラマだけの専売特許とは思えない。というよりも、個人的にはそういう連中は「ハッカー」という称号がふさわしいと思う。
またアーキテクチャや仕様、設計が特許で保護されている場合にも、泣く泣く「再発明」せざるを得ない場合があるかもしれない。
OOPがプログラマの生産性を云々、プログラマのレベルを云々、という話もいい加減聞き飽きた感がする。ようするに、包丁も握ったことのない料理の初心者を、最新のキッチンシステム付の台所(IDE)に放り込むようなものだ。そもそもの基礎訓練量が足りないのだから、折角のキッチンシステムの機能もお荷物か、使いこなせず泣きを見るか。かつて自分もそうだった。Cすらまともにやったことが無いのにC++BuilderでGUIプログラミングを始めてしまい、入門書の内容が何を言っているのかわからず只サンプルを打ち込んでいただけだった。コンパイルエラーが発生しても何が悪いのか皆目見当が付かなかった。
大体、OOPで書かれたコードだってC++なら結局はアセンブラに、JavaならJavaVMのバイトコードでやっぱり機械語チックに、PHPやPerl、Rubyなどのスクリプト言語だって言語パーサが構文木を解析して、とどのつまりは頭から順繰りに動かしていくだけ。CPUのアーキテクチャレベルで「OOP対応のCPU！！」とかいうのが出ないでもしない限りは、最後に低水準をがっつり押さえられる技術者は、Cやアセンブラ、機械語など低水準をきちんとやった人達だろう。
再発明の話に戻るけど、ブラックボックスとしてのOOPの部品化の話であればブルックスの「人月の神話」やロバート・L・グラスの「ソフトウェア開発55の真実と10のウソ」で既に議論は終わっていると思ったのだけれど。
- 「人月の神話 新装版」フレデリック・P・ブルックス, Jr. - ピアソン・エデュケーション, p211, 「第１７章 「銀の弾丸などない」再発射」 - "再利用はいかが？"
ケン・ブルックスは、一般性のため必要なものが何であるかを事前に予期するのは難しい、と次のように語っている。
「ユーザーインターフェースに関する自分自身のライブラリを使用するのが五度目にもなったというのに、修正が必要な状況が続くのだ」。
- 「ソフトウェア開発55の真実と10のウソ」ロバート・L・グラス, 日経BP社, 目次より
再利用
真実15 : 小規模な再利用（例えば、ライブラリやサブルーチン）は、50年前に始まり、既に解決済みの問題である。
真実16 : 大規模な再利用（コンポーネント単位）は、誰もがその重要性を認識し、なくてはならないと感じているが、今なお未解決である。
真実17 : 大規模な再利用は、類似システム間でうまくいく可能性が高い。応用分野の類似性に依存する為、大規模流用の適用範囲は狭くなる。
真実18 : 再利用には、二つの「３の法則」がある。(a) 再利用可能なコンポーネントを作るのは、単一のプログラムで使うモジュールを開発する場合に比べ、３倍難しい。(b) 再利用可能なコンポーネントは、ライブラリに取り込む前に、３つの異なるプログラムでテストする必要がある。
真実19 : プログラムを再利用する場合、流用母体の変更は、バグの原因になる。20 - 25%も変更する必要があるなら、最初から作った方が、効率が上がるし、品質もよい。
真実20 : デザインパターン方式の再利用は、ソースコードの再利用における問題を解決する一手段である。
真実15 - 20だけでお腹一杯。ちなみに真実20の「デザインパターン方式の再利用」は、これこそが「車輪の再利用」だと睨んでいる。誰か他の人が考えた優れた設計技法（＝「車輪というアーキテクチャ」）をお知恵拝借、と物まねさせてもらうわけだから。MVCパターンというアーキテクチャは誰もが真似るが、その実装であるフレームワークライブラリは十人十色になって当然。大体、人間を含めた生物自体がDNAというアーキテクチャを真似た上での、実装の再発明、再生産の繰り返しではないか。
さらに言えば、何かを「作る」作業というのは最初は物まねでこそあれ、結果としてその人のオリジナルというのがゴールではないだろうか。その辺りはポール・グラハム「ハッカーと画家」（オーム社）の第二章「ハッカーと画家」に書かれている。
自分がXhwlayやYakiBikiを作るに至り痛切に感じたことは、「思いついたこと・作りたいことの8割は既にどこかの誰かが実装済である」という事と、「残りの2割を譲歩したくなければ、自分で作るしかない」という事だ。但し8割の内、出来る限り再利用できれば楽で良いよね、と。
話を戻すと、元記事の著者の結論部分については特に異論が有るわけではない。ただし「OOPはプログラミングを楽にしてくれる銀の弾丸だと思ってたし、再利用で楽できるはずだったのに、現実は違う」というような思考過程が見えたので噛み付いてしまいました。
じゃぁあなたはOOPを人に説明する時、メリットをどう喋るの？と言われれば、「設計・実装テクニックの一つ」として喋ることにしている。お客様にしてみれば、注文したとおりの動きをするソフトウェアが入手できれば良いわけだ。裏側でOOPを使おうと構造化プログラミングを使おうとIFとGOTO文だけの言語を使おうとLISPなどの関数型言語を使おうと、お客様にはあまり関係ない。
但し、既にデザインパターンやJava, .NetなどOOPをサポートした言語があって、ライブラリもある状態であれば、ちゃんと勉強して使いこなせるようになれば仕事の幅も広がるし多少楽もできるよね、と。哲学とか、再利用がどうたらなど考えずに、一つの技法として覚えましょうよ、と。
いわば中華料理一本できた料理人に、「フランス料理も美味しいものがあるから、少し勉強してみては？」と奨めるようなモノですな。
最後に。そもそも「何でOOPを勉強しなければならないの？」とか「OOPで作らなきゃ駄目？」とか訊かれても、質問者を納得させるだけの答えを自分は持ち合わせておりません。なぜ自分はOOPを勉強しようとしたか？答えは簡単でかつ他に人が知ってもどうにもならない話で、「OOPとその言語を学ぶことで、より格好良いプログラムや面白いプログラム、作りたいプログラムを作れるようになりたかったから。」です。ホント、他人に答えたところでどうしようもない答えです。
エディタを作りたかったからC++Builderを勉強しようとして、その途中でDelphiにも手を出しました。C++BuilderやDelphiを勉強する為にはOOPの知識が必要だったので、C++を勉強しました。その結果Cetaというエディタを作り、WindowsAPIも勉強できました。
Webサイトを作りたかったのでPHPを勉強しました。PHPで格好良いプログラムを作るにはOOPを勉強した方が良いようです。なので、PHPでのOOPを勉強しました。その結果PHPでXhwlayやYakiBikiを作れるようになりました。
お仕事でJavaの仕事が始まったのでJavaを勉強しました。格好良いプログラムを作って楽したかったのでJavaを勉強している内に、JavaでのOOPの勉強もしました。その結果何とかJavaのお仕事を受けられるようになりました。
OOPを勉強すること自体が目的じゃなくて、それは単なる過程。ゴールにたどり着こうとする内に、あれよあれよといつのまにかC++だのJavaだのPHPだのでOOPに慣れ親しんでいました・・・というのを他人に話したって、どうしようもない。
なので、OOPを使うことに疑問符を感じる人達は、自分なりに作りたいプログラムを見つけるか、初心に戻って最新のプログラミング言語を勉強したりしてワクワク感を取り戻すと良いでしょう。そうして「こういうプログラムが作りたい」とか、「技術書のサンプルコードを打ち込んで動かすのが楽しい」という感覚を取り戻した頃には「もっと勉強するには、もっと自分の作りたいプログラムを作るには」と考え始めるでしょう。その実現へ前進している内に、必ずOOPの話も出てくるので、その時ちゃんと勉強してみる、というのが個人的にはお奨めです。
