オブジェクト指向言語が与えた開発手法への変化(2)
さてさて、だいぶ脱線しましたが本題に戻ります。
オブジェクト指向言語によって、文を構成する上での最低条件であるSVを満たす事ができた。その結果、ソフトウェア開発というものはソフトウェア工学というよりは、むしろ文学に近づいたのではないだろうか、そんな視点からみたら新たな発見があるかもしれない。というのが一連の記事のテーマです。
開発手法が手続き型言語の時代から大きく変わった部分といえば「ウォータフォール型からスパイラル型へ」と言われるような反復型開発（スパイラル型、イテレーティブ型）開発手法の登場だと思います。
最初に提言したのはおそらくRUP(Rational Unified Procces)だといって差し支えないと思うけど、それ以降もアジャイルとかの文脈で「イテレーティブ、イテレーティブ」と言われ続けています。そろそろ定着していると思いたいけど、いろいろと人に話を聞く限りでは、自社サービス系の以外の所はまあ程遠い状況のようで orz
さて、じゃあなんで繰り返すことが有効になったのか? ということなのですが「顧客の要求に早く答える」的な通り一遍の説明は色々な所でされているので、ここではプログラム設計における繰り返すことの意義に限定して考察しようと思います。
文学的観点から見てみよう、というのがテーマですから「良い文をかくにはどうしたら良いか?」という視点から考えてみます。
このテーマに一番取り組んでいるのはおそらく出版業界の方々でしょう。なので、とりあえず「本を作る」という行為の考察を通じて、オブジェクト指向開発のプロセスの変化についての考察を深めていこうかと思います。
書く本のテーマにもよりますが、
・おおまかな起承転結を決める。
・登場人物のキャラ設定をする。
・章立てをして見出しを決める。
たぶんこんなことをするはずです。いきなり思うままに書き始めるというパターンもありそうですがw 他にもすることがあるでしょうが、オブジェクト指向開発と関連ありそうな部分を恣意的にピックアップしておりますw では、細かくみて行きましょう
おおまかな起承転結を決める
作るシステムの範囲を決めたり、モジュールの大きさを決めたりとかが該当するでしょうか(重要じゃないので適当w)
登場人物のキャラ設定をする
ここらへんはクラス設計に似ています。クラスとはデータと操作(メソッド)が一体となったものです。C言語的にいえば構造体と関数がひとつになったもの。プログラムを書く、という観点からすると「関数の書く位置が多少内側にずれた」に過ぎないのですが、その書く位置が多少変化したことがもたらす意味の変化は甚大である、というのはいままで述べた通り。
UMLとかではデータは属性(Attribute)、メソッドは振る舞い(behavior)とも呼ばれます。この「属性が振る舞いをもつ」という変化によって
クラスが個性を持ち始めた
という変化が起こったことが重要です。ここらへんがクラス設計とキャラクター設定が似通ってきたと個人的に考える理由です。
ドラえもんで説明しましょうw 次の様なシーンを思い浮かべてください。
のび太が問題を多額のお金で解決する
なんかしっくりこないですよね? 「それスネオの役割だろ」って思いません? のび太が暴力で問題を解決、でもやっぱり変です。ドラえもんにおけるジャイアンのやれることが、刺身にたんぽぽをのせる簡単な作業くらいしかなくなりますw 存亡の危機ですねw のび太がそんな振る舞いを見せたら誰もがこう思うでしょう。
のび太のくせに生意気だ!
と。何でこんな話をしたのかというと、オブジェクト指向開発の現場では主にそんなことが議論されている、ということ伝えたいからですw いや真面目にw
クラスを実装していく内にメソッドは通常増えていくんですが、ある程度開発が進みと増えたメソッドを見直したくなります。だいたい改めて見直すと、そのクラスに相応しくないように思えるメソッドが見つかるものなのです。そういう発見をすると普通の人はメソッドを適切な別のクラスに移動したり、新たな特徴(属性)を持った新たなクラスを作成したくなります。たとえばのび太とスネオがドラゴンボール的フュージョンした「スネ太」クラスを作成するとかw
こういうプログラムの書き直し作業を、オブジェクト指向開発では「リファクタリング」と呼びます(いまでは一般動詞化しているかも)。
この作業の価値が結構伝えにい
理解されにくい事この上ないのですが、ちと長くなったのでそこらへんはまた来週。
休みます
先週・今週と忙しくBLOG書く暇がなかったので、今週は休みます。来週も結構忙しいので書けるかどうかは微妙ではあるのですが頑張ります。すいません
関数にしか見えないものが「メソッド」と新たな名前で呼ばれる理由(2)
「メソッドは関数ではなくなった」
この事に気がつくと「メソッドは関数性を失った代わりに多態性を得た」ということに気が付きます。この事に気がつくともうひとつの不思議バズワードである
たかが関数の呼び出しを「オブジェクトにメッセージを送る」と言い換える
というオサレフレーズにも、新しく命名された必然性があることに気が付きます。どういうことか? ちょっと説明しましょう。「関数を呼び出す」この言葉は普通に使いますよね? では「メソッドを呼び出す」はどうでしょうか? これもよく使われますよね。しかしよく考えてみてください。
本当にメソッドって呼び出せますか?
呼び出すということは、呼び出し先を知っているということですよね? 病院の窓口とかで「誰々さーん、内科の診療室にお入りくださーい」なんて呼び出されることありません。
メソッドはオーバライドされる可能性がある以上、確実にこのメソッドが呼び出される、と言い切れるなくなります(インスタンスが固定されない限り)。少しわかりにくいのでJavaのコードで説明します。
AnyClass any = new AnyClass();
any.anyMethod();
このコードは AnyClass#anyMethod() が呼ばれるのは確実です。それはany というインスタンスの状態が any = new AnyClass(); という代入によって状態が固定(厳密に言えば型が固定)されているからです。
しかし、この AnyClassクラスを引数やクラスフィールドに設定しただけで、AnyClass#anyMethod() が呼ばれるかどうかは不確実になります。たとえば、下記の様などこかのクラスのメソッドとして書きます。
public void someMethod(AnyClass any){
any.anyMethod():
}
こうしただけで any.anyMethod() が AnyClass#anyMethod() を呼び出すかどうかはわからなくなってしまう。なぜなら
public SubAnyClass extends AnyClass {
public void anyMethod(){
}
}
の様なAnyClassを継承したサブクラスを作成して
someMethod(new SubAnyClass());
と呼べば、someMethod 内部の any.anyMethod() は SubAnyClass#anyMethod() を呼ぶようになるからです。ある程度知っている人にとっては、説明するまでもないことですが。これがオブジェクト指向言語を学ぶ上で重要になる多態性(ポリモーフィズム)と呼ばれるものですが、ここでは軽く流します。
覚えておくべき大切な事は「メソッドは呼び先がよくわからない」ということです。そしてこの「よくわからない」という特徴がプログラミングを柔軟にした、ということです。さらにいえば、この「よくわからない」という特徴がシステムの「フレームワーク化」が可能になった理由だったりします。
さて、一休さん的なトンチワールドに突入してきましたねw 「よくわからなくなった」ことがプログラムの可能性を広げた、意味分かんないですよね?
正確に言えば「どこかの誰かがクラス(メソッド)を継承(実装)した場合、オーバライドされるかもしれないメソッドが呼ばれるかもしれない」そんな、かもしれない運転的現象の事なのですが、余計にわかならなくなりましたねww
しかし、なぜよくわからないのでしょうか? それはメソッドが呼ぶものは
未来
だからですw … 電波さんスイッチON!! つまり
メソッドは未来人に向かってメッセージを送っているのです!!
ΩΩΩ「ﾅ､ﾅﾝﾀﾞｯﾃｰ!!」
…
正気をとりもどしましょうw ここで言う未来とは
どこかの誰かかがメソッドをオーバライドするかもしれない未来
の事です。メソッドは、static や final (Javaの場合) にしてオーバライド禁止にしない限り常に未来の誰かにオーバライドされる可能性があるわけです。つまり、未来のメソッドを呼ぶ可能性があるわけです。
そう考えるとメソッドを呼ぶ、とはいわば「どこかの誰かを呼ぶ」「未来を呼ぶ」ということと同義なので言葉として変ですね。
しかし、誰かが作ったクラス(メソッド)がいることは確実なので、それに対して「メッセージを送る」ならまあ意味は通るわけです。逆に言うと依頼メッセージしか送れなくなったんですね。お願いしまーす、きちんと処理してください〜〜、そんなゆるい依頼。このゆるさがプログラムの柔軟性を生んだわけですが、それについてはまた後で。
そろそろまとめます。個人的にオブジェクト指向を理解する上で重要だと思っていることは、この「メソッドが関数でなくなったことで得たものとは何か?」を理解することだと思っています。その答えを僕なりに短くまとめると
メソッドは関数性を失うことで多態性を得た。また多態性を得たことで、呼ぶことはできなくなったが、未来に向かってメッセージを送ることが可能になった。
と、やや強引な答えになりますw ここらへんはよく知る人にとってはツッコミどころが多い解釈かもしれません。「メッセージを送る、もSmalltalk由来では...」とかw
ただ、こんなことを初学者が頭に入れておくと学習をすすめる過程での気付きを早めるんじゃないか、などと考えていたりします。
まあ、ぶっちゃけ「メッセージを送る」なんてオサレな言い方は、俺も普段しないし普通にメソッドを呼ぶって言っちゃうけど、厳密には呼べないものだという認識は持っておくといいと思っています。
さて、脱線していく内に一体どこのレベルの人に向けて書いているのだかよくわからなくなってしまった感はありますが、まあBLOGなんでそんなもん、と流していただければ幸いです。
ということで、ようやく来週は本題に戻れそうです。
関数にしか見えないものが「メソッド」と新たな名前で呼ばれる理由(1)
前記事で「メソッドが持っている数学性と文学性という二重性」に気がつくきっかけが別にあった、と書きました。ここらへんはだいぶ後に書こうと思っていたことなのですが、流れ上先に書いちゃいます。
そのきっかけとは、多態性(ポリモーフィズム)の意味を理解したことで、この記事のタイトルにあるように「どうみても関数にしか見えないものが「メソッド」と新たな名前で呼ばれる理由」、呼ばなければならない理由に気がついた、というきっかけです。
「メソッドはどうみても関数にしか見えない」
この素朴な感想は、オブジェクト指向を学び始めた頃に誰もが思ったことだと思います。ぼくも、オブジェクト指向を学びはじめた時に真っ先に思いました。
「どうみても関数にしか見えないのに、なぜメソッドなどと言い換えているのか?」
という素朴な疑問。
その当時は無知だったので「オブジェクト指向信者とやらは、ただの関数を"メソッド"なぞというトレンディバズワードに言い換えてオサレピープルを気取っているイケ好かない奴らだYO」的な義憤をもって秋葉原あたりで反対デモを企画するくらいにはむかついてました。ちなみに、今でも無知なことは内緒ですw
しかし、勉強していく内にオブジェクト指向におけるメソッドはオーバーライド(上書き)されることにより多態的(ポリモーフィック)に戻り値を変える、ということを理解しました。
関数というものの数学的定義が
ある値に対して，ただ1つの値 が対応するような関係があるとき，この関係を関数といい，一般的に y = f(x) と表す。また x は y の関数であるという。
であるなら、多態的に戻り値を変える事は「関数ではない」ことになります。
※ 注意 ※
「数学的に正しい関数の定義とは何か?」を理解していない可能性があるので、ポリモーフィックに戻り値を変える事も「関数」なのかもしれないので間違った解釈かもしれませんが、とりあえずこの記事では「関数ではない」という解釈で進めます。間違っていた場合はご指摘をお願いします。
しかし完全に「関数ではない」と言い切ってしまうには語弊があります。あえてメソッドの持つ特性を上記数式に当てはめてみると
y = classInstance.f(x)
というような表記になるでしょう。だいぶ変ですし、そもそも数式でないですけどw しかし、こんなふうに表記して考えてみると、メソッドが関数である状態とは「classInstanceの値(状態)が固定されている時」であることがわかります。あたりまえですけどw
もう一つは、classInstanceの影響を受けなくなった時。つまりJavaで表記すると
public static int f(int x);
のようにstatic宣言され、インスタンスフィールドにアクセスできなくなった場合。まあこれも当たり前ですね。このコードコンパイル通らねだろ、というツッコミは無視の方向でw
あとは オーバライド不可にする final宣言された時も関数っぽくなりそうですが、classInstanceの状態に依存しているので除外しています。
逆にいえば、これら状態以外の場合は関数ではなくなっているわけです。
メソッドはインスタンスの状態に依存するようになったことで、数学的に関数とはいえなくなった
そんな風に考えると、ただの言い換えでは無かったことに気が付きます。つまり、オブジェクト指向言語におけるメソッドは数学的に関数とはいえなくなったので新たに命名する必要に迫られた。従来のプログラム言語における関数とは、機能・役割が変わったのだから新たに「メソッド」と名付ける必要があった。こう解釈すると命名する必然性に気が付きます。
まあ、こんな深刻に考えなくてもぶっちゃけ 「Smalltalk でそう命名されたからそう呼んでいるだけだろ?」と思わなくもないんですけどw しかし、こんな風にとらえ直すと
オブジェクト指向言語を表面的、文法的に理解しただけでプロジェクト管理に回された人 と
その後プログラミングを重ねてメソッドのポリモーフィズムの価値に気がついた人
の意識差の分水嶺が明確になると思うんです。つまり
「ただの関数をメソッドと言い換えて気取っている」という認識と
「関数性を失って多態性を得たからメソッドと新たに命名するしか無かったのだ」
という認識の違い。この違いに気がつくとあとはオブジェクト指向にのめり込むだけなので、気づきのポイントとしてこの「メソッドという言葉のとらえ方」は結構重要なのではないか? そんなことを思ってこんな文章を書いています。
メソッドという同じ物を見ているのにとらえ方を変えるだけで、「軽蔑」状態から、多態性の価値に気が付いた「尊敬、尊重」状態という真逆の精神状態にひっくり返る訳ですから、「考え方を変えさせるきっかけ」として「関数にしか見えない」という誤解を解くことから始めるというのは結構いい方法論なんじゃないかと思っています。
そんなことを考えているので「ただの関数をメソッドと言い換えて気取っている」という第一印象を引きずり続けていることが、オブジェクト指向以前のプログラム言語を知っているであろう管理者層の人達の「オブジェクト指向を軽視する根本的原因なのかもしれない」などと考えたりします。
この仮定が正しいとすると
「メソッドは関数とは違うのだよ、関数とは」
と、ランバ・ラル的方法論で関数ではないことに気づかせることが、管理者層の人たちの心を動かすのに結構有効に作用するんじゃないかと思うのです。だからそこを強調するために「関数性=数学的 多態性=文学的」という対比、比喩を基軸にした分析にしてみたわけですね。
もうちょっとだけ脱線は続きます。では、また来週。
オブジェクト指向言語が与えた開発手法への変化(補足)
前記事で「数学的に美しいコード」と書いたら
「数学的に美しいコードなんてみたことねー」とか
「数字表現(マシン語)から離れた時点で文学性は出てきたよね」とか
「オブジェクト指向以前の世界で、答えが常に1つだったんなら、みんなこんなに苦労してないと思うんだけど」
という至極まっとうな意見を頂きました。
「確かにw」と思ったので、この記事は補足(言い訳)を書きます。その為オブジェクト指向を結構わかっている人向けの記事になっています。まあ、前記事はノリといきおいで書いたトンデモ文章だったりするんでそこらへんは割り引いていただけると幸いです。あとで書きなおすかもw
あの文章は「オブジェクト指向には文学的と数学的という二種類の側面がある」という二方向の観点を示すことで、その後の説明に入りやすくするために書いた文章です。その後の説明とは「メソッド」というものが持つ関数的性質を数学的、多態性(ポリモーフィズム) による文脈依存性質を文学的と対比することで、メソッドというものが持っている二重性を浮き彫りにしていく、という説明。そこに持っていくために、まずは「抽象度の調整=文学的」として説明を始め、多態性→ 述語性→文学性と融合させることで「ポリモーフィズムの価値を浮き彫りにしていく」という感じの流れを想定して書き始めました。その為「美しさ」という印象的な表現を使った所があります。
そこにつなげるために強調したかったことは「プログラミングが文学性を持ち始めた」という部分。そして、そこを強調したいがために単純に反対側にあるであろう「数学性」を持ってきただけだったりするので、結構適当に扱っていますw すいません。
その二重性を強調することで「オブジェクト指向を理解する際に重要な2つの視点がある」ということをあきらかにしたかったわけです。そしてその2つの視点からオブジェクト指向言語の特性や、その特性を最大限引き出すために生まれた開発プロセスを分析してみると面白い発見があるのではないか? という思考実験が一連のオブジェクト指向に関する文章のテーマです。
これら文章を書いた目的はいくつかあります。
一つはオブジェクト指向初学者に対して「犬猫Example」以外の視点の提供という、玉砕必死の無謀な挑戦。もっともそういう人向けとしては難しい部分があるような気もしますが、心に引っ掛けておくと、勉強を進めた後の気づきを促しやすく成るぐらいの効果はあるんじゃないかなー、と淡い期待をしながら書いてます。
もう一つは、プログラミング経験がCOBOLや手続き型(構造化)言語で終わってしまって、オブジェクト指向言語でのプログラミング経験がないまま、設計、プロジェクトマネジメントしなければならない上司たちのかたくなな思い込みを砕く為の糸口の模索、です。
こういう人向けにプログラミング言語がオブジェクト指向化したという小さく見積もられやすい変化は、あなたたちが思っているよりもずっと大きな変化なので、開発手法とかを抜本的に変えないとあなた達が期待しているような費用対効果の最大化、みたいなことは達成できませんよ、そんな事を暗に伝えたいわけです。簡単にいうと「やり方変えろや、ばーかばーか」ですw
その為にはこれら人たちが拒否反応を示す「カプセル化、継承、ポリモーフィズム」等のよくわからないオブジェクト指向関連の技術用語を抜きにして伝える必要があるので、そんな文章を書いてみた、というところがホントのとこだったりします。
実はこの文章はXPが流行りかけてた2003-5年位の時に思いついた文章なのです。その時僕はCOBOLerが設計したとおぼしき、クラス名が連番だったりするJavaのプロジェクトに入っちゃって、すごくむかついていたんです。だから、そういう人達の考え方を変えさせるには「何に気づかせたら良いのだろうか?」を考える必要があり、その時に思いついた説明方法なんです。発想した時期を考えれば古くなってしかるべき内容なのですが、未だに必要とされているんじゃないかと思える感じがいろいろと残念な感じです orz
まあ、思いついた時にBLOGに書いとけよ! って話なんですが、その頃BLOGを書くってこと自体が「おしゃれピープルのもの(当社比)」と思っていたので、原宿駅にはいけても竹下通りには入れない程度のオシャレさんな僕としては、BLOGは高い壁でしたw
あとは、オブジェクト指向をよく知る人に対してビーンボールまがいの変化球を投げたら、新たに面白い発見があるかもしれないし、面白がってくれるかもしれない、なんていう目的も多少ありますw
そろそろ話を戻しましょうw
かたくなな思い込みとは
「プログラミングは価値の低い作業」とか
「プログラミングなしに設計はできる」とか
「ウォータフォールが叩かれているけど、まだいけるはず。つーか、これからっしょ」
などの事です。
しかし、従来型の開発手法と比較すると、オブジェクト指向言語での実装を前提にしたプログラム設計において「プログラミングと言う作業が決定的に重要になってきている」という大きな変化があります。開発においてテストやリファクタリング等のプラクティス(テクニック)が重要になってきているということ考えれば明らかです。
が、この変化はオブジェクト指向言語でのプログラミング経験なしにおそらく気が付かない、あるいは痛感しない。特にプログラミングをしている時にこそ「よりよい設計に気づく、思いつく」という事実に気が付かない。この事に気が付かない人は設計と実装(プログラミング)は分離できると考えるか、そんなに問題を起こさないだろうと甘く見積もる、そんな気がしています。
この「甘く見積もる」ことの原因はどこにあるのだろう、と考えていた時に気がついたことが上記の「メソッドが持っている数学性と文学性という二重性」
この事に気が付いたきっかけはまた別にあるのですが、長くなったので、そこらへんはまた来週。だいぶ予定とずれた感じですが、重要なことなのでまだ脱線は続きます。
オブジェクト指向言語が与えた開発手法への変化
前記事で「しかしオブジェクト指向言語の流行によって、なんでこんな上流から下流に至るまで全部に影響が出てきたのだろう?」というわざとらしい問いをしました。
この問いに対する答えは、いつも通りの僕のトンデモ理論で恐縮ですが
プログラム言語で文が書けるようになったことで、本来数学的完全世界だったプログラミング世界に文学という答えが一つとは限らない不完全要素が混じるようになったから
だと思っています。「はぁ? なにが文学なの?」と思うかもしれません。たしかに subject.verb() という表記方法になっただけでは「文学になった」とはいえないと思います。しかし大抵のオブジェクト指向言語の場合、この表記法と同時に「抽象化」という概念を扱います。
この抽象化という概念がやっかいで「どう抽象化するのか?」「どの位抽象化するのか?」という答えのない問いを常に発し続けます。この問いには、本質的に答えがないのですが、プログラミングを進めるには答えらしきものを見つける必要があります。数学的に一つの答えに導けないような問いに対する答えにたどり着くための方法論が必要になってきたわけです。その方法論が、文学であり、哲学であり、宗教w、という訳です。
「抽象化」を難しい物にしているのは「どの位抽象化するのか?」という度合い、バランスのとり方の難しさ、だと思います。たとえば文学的に「私はあなたを愛しています」という文を、抽象度最大にしてみることを考えてみましょう。
この問いに対する夏目漱石的答えは
「月が綺麗ですね」
だそうです。
… … …
意味分かんないw 全く意味分かんないw これはまあかなりのこじつけですが、大体の場合抽象化を極大化すると意味わからなくなります。ピカソの絵とか典型的ですよね。しかし文学的という観点から見るとこの訳わからなさは逆に「美しい」わけです。
このように抽象化すると美しくなるが、一方で理解しずらくなるというデメリットを生むので、それなりに美しくかつ理解できる範囲に収めるために適度にバランスを取る必要が出てきます。
そこで出てくるのが粒度、とか抽象度とかのバランスパラメータ。つまり抽象度50％ とか 抽象度33％ とかの感覚値。しかし感覚値であるが故に、これらに明確な正解はありません。
ここらへんは古くからの難題である
「ジオングの完成度は80％だが、完全体といえるのかどうか?」
という命題に似ていますw 「似てねーよ」というツッコミはいつも通り無視の方向で行きますw
この命題に対する整備兵の答えは「足なんて飾りです。偉い人にはそれがわからんのですよ」となり、あれで100％完全体である、という答えになります。
しかしエライ人目線からいえば「未完成のまま投入するから負けるんじゃないか、ばーかばーか」という答えになります。
この問いに正解はありません。どちらも正解であり、間違いです。しかし現実問題として取捨選択をしなければなりませんから、何かしらの基準で正解を決めなければなりません。そこで出てくるのが「美しい」という基準。その基準から上記命題に答えを出すと
足つき100％ジオングはスカート履いているようにみえるので、おかまっぽい。だから美しくないので、80％ジオングが完全体ということでFA(ファイナルアンサー)
と、なりますw このトンデモな答えはいろいろ議論を巻き起こすでしょう。しかし、美しさを議論しているわけですから、答えなんて出ないんです。それでもプログラムを完成させなければならない、という制約からなにかしらの結論を出さなければなりません。では、どうすれば良いか?
結論を出す方法は色々あるでしょうが、一番重要なことはきっと「関係者全員とよく話し合うこと」だと思います。
そう考えると最近のアジャイル開発プロセス等の各種開発プロセスで重要視されているのが「コミニュケーション」になっている理由がわかってきます。たぶん「文学的に美しい物」という答えのない答えを選び出すには「よく話し合って妥協点を見出すしかない」からなのでしょう。
こんな風に考えていくとオブジェクト指向言語で書かれたプログラムにおける「コードの美しさ」には二種類あることに気が付きます。すなわち
抽象度が適切に設定されていて"文学的"に美しいコード
分岐や数式、アルゴリズム等が"数学的"に美しいコード
という二種類の美しさ。この二種類の美しさの混在っぷりがオブジェクト指向言語でのプログラミングを楽しい物にする一方で難しくしている要因だと思っています。
そして、この二種類の美しさの整理の難しさが各種開発手法を変化させたのではないか? と思っています。これについてはまた来週。
オブジェクト指向言語が流行した必然性について考える(3)
前記事で「構造化言語では主語が記述できなかったが、オブジェクト指向言語ではできるようになった」と説明しました。
しかし、これまでの記事を読んで「なぜ自然言語に対比してオブジェクト指向の説明を試みる」という迂遠な方法をとっているのか? と疑問に思っている人も多いと思います。
その理由は、プログラム言語の発展の歴史を「可読性との戦い」という観点から紐解いていくと、「オブジェクト指向言語が流行した必然性」が見えてくるのではないか? と考えているからです。
可読性が一番高い文章とは、おそらく口語(自然言語)で書いた文章です。口語の文章をコンピュータに読ませて、その文の意志を正確に読み取って実行してくれればプログラム言語の出番は必要ないのですが、そんなことはこの先当分ありえないでしょう。
となると、プログラム言語を進化させ口語に近づけることが「可読性を上げる」現実解となるでしょう。では、可読性という観点から簡単にプログラム言語の発展の歴史を見てみましょう(かなり適当です。ツッコミよろしくです)。
プログラム言語はまずマシン語(機械語)という2進数の数字の羅列から始まりました。さすがに数字の羅列は人間が読むには厳しかったので、命令語というものを追加したアセンブラという言語が生まれました。この命令語に口語的役割をあてはめるとすれば「動詞」があてはまるでしょう。ただこの命令語は予め用意されたもの使えませんでした。
これを関数(動詞的役割)という形で自由定義出来るようになったのが構造化言語(C言語)
同時に構造体という名詞的なものも定義出来るようになった。これで口語の文を構成する上で必要で重要なパーツ、名詞、動詞は揃ったので、可読性はかなりよくなった。
しかしもう一段可読性を上げようとして、それら品詞で「文を書く」ことをしようとすると「主語の記述能力」が足らないことに気がつく。
この能力を"偶然"埋めることになったのが「オブジェクト指向」という考え方、またはこの考え方によって生み出されたプログラム言語(Smalltalk等)。なぜ"偶然"なのかといえば「オブジェクト指向」という考え方は可読性を上げるという課題に取り組んだ結果生まれたわけではなく(Smalltalkを例にとると)「GUIのOSを作る過程」で生み出されたものだからです。
もっとも、このBLOGのコメントにてid:sumimさんに教えていただいたアラン・ケイの「ソフトウェア工学」は矛盾語法か？を読む限りでは、口語的に自然な形を意識しているようなので"偶然"ではないんでしょうが。
また、id:sumimさんのBLOGの オブジェクト指向の概念の発明者は誰ですか？ で説明されているように「オブジェクト指向」という考え方自体も、命名直後(Smalltalk 1972年直後位?)から、C++（1979年）登場による再定義により意味が結構変わっています。僕の記事もC++以降のいわゆるクラスベースのオブジェクト指向の考え方の文脈で書かれています。
が、まあ難しく考えるときりがないし、結構みんなざっくり理解だったりします。そんな程度の理解で問題なかったりするので、細かい事は Wikipedia や他の人に任せますw。色物BLOGは色物らしく変化球アプローチで頑張りたいと思っていますw
さて、話を戻しましょう。
「可読性」を起点に考えを進めていくと、プログラム言語が口語文の形式に近づくためのかなり大きめの一歩を「オブジェクト指向言語」が埋めた、ということに気が付きます。
この一歩は可読性を上げるうえで避けては通れない道なので、あらゆる言語がオブジェクト指向化するという現象が「必然的」に起こった、個人的にそんな風に考えています。ここらへんが、僕が考える「オブジェクト指向言語が流行した必然性」の理由です。
かなり長ったらしく書きましたが、とにかくオブジェクト指向言語によって、口語の文に近づく為の最低限の条件「SV」の記述能力を得ることができた、という事実が重要で、この変化は マシン語→アセンブラ アセンブラ→C言語 という変化とは本質的に違う
「プログラム言語で文が書けなかった」→「書けるようになった」
という抜本的な変化である、という認識が重要です。
この変化は個人的にパラダイムシフトと呼んでも良い位の大きな出来事だと思っています。大きな変化だからこそ、オブジェクト指向言語が開発の主流に成るにつれ、要件定義、設計手法、開発手法、テスト手法等ソフトウェア開発手法全般に多大な変化をもたらすことになったのだと思っています。
しかし、よくよく考えてみるとなんでこんな上流から下流に至るまで全部に影響が出てきたのだろう? とも思います。ここらへんについてはまた来週。
