オブジェクト指向

オブジェクト指向黎明期の思い出 BOFそしてJPlop

昭和の話を聞くたびに、ITには黎明期があり、その熱気がうらやましくなることがある。なんとも自由で楽しそうだったのだ。僕にもそういう時代があった。昭和黎明期のITとは違ってその後の礎にはならなかったとは思うが。

あれは就職を目前にしたころだったかな。趣味でプログラムをやっており雑誌を買いあさっていて、DDJみたいな雑誌を買ってオブジェクト指向というにものを面白いと思った。金融か不動産に就職したいとおもっていたが、2000年付近は就職最氷河期でITしか就職先が無かった。そこでオブジェクト指向のBOFに出あった。世話人をしていた人は人格者だった。当時同じ最寄り駅に住んでいて、私は彼を尊敬したものだ。そして、彼の勤めていた有限会社社長はFさん、僕は彼にも魅了されたのだ。

あのころのオブジェクト指向には熱気があった。世界を変えてやると思っていた人たちも居たはずだ。本を出している人もたくさん居た。若い僕が彼らを尊敬するのは当然だったろう。だが、今さらながらデザインパターンを語るに書いたGOFと同じで有名な彼らは年齢の割りに開発の経験が非常に少なかった。そんな彼らがJPlopというものを主導した。システム開発における成功・失敗のパターンを整理して役立てようというものだ。ただ、何度も言うが彼らにはしゃべるのと書くことは上手いかもしれないが、肝心のシステム開発の経験が無いのでそのパターンの選択もそれほど価値があるものではなく、後進に役立てるようなものが出来なかった。UMLでなにかしら書いて適当にのたくっただけのオモチャみたいなものだったのだ。現実の開発はそんなもので何とかなるものではない。Jplop自体には経験豊富なSEも多く居たのだが、主導した彼らに経験が無かったということだ。

当時のオブジェクト指向界の問題点は、本を書いている「作家さん」の地位が高くて、実際に経験豊富なエンジニアよりえらいと思われていたことだろう。到底まともなものが出来る場所ではなかったのだ。そして、strutsのような実務として使えるものがどんどん生まれてきて、理屈で語るオブジェクト指向は意味を失っていった。今思うとなぜ当時あのお粗末さに気がつかなかったのだろうと思うが、やはりあれはあれで熱気のある時代だったからなのだろう。僕の青春だった。

Fさんの思い出

オブジェクト指向界というものが存在したとしたら、Fさんはその中では有名な人だった。一部の人からはドンとさえ言われていた。翻訳等を精力的にしている人ではなかったので、一般的な露出は少ない方だ。僕も学生~ベンチャー企業あたりの時に事務所に遊びに行ったりした。当時の僕にとって彼はすごい人だった。多分今でもすごい人なんだろうと思う。ただ、すごさの意味合いが違ってきている。昔はああなりたいと言うすごさだった。今は、ああいった風にやって一定の名前を売るなり生活をするなりというのはかなりの才能なのかもしれない、そういうすごさだ。ああいった風という言い方になったのは、やっぱりエンジニア側からするとどうかと思うからだろう。要は彼はエンジニアに近い人ではなく、コンサルタント、もっというとOO何とかのエヴァンジェリストだったわけだ。

当時のオブジェクト指向のビジネスモデルとして、高い金を取ろうと思ったらそれは多分唯一可能なものだったに違いない。そして、彼に連なるかどうかわからないが、彼に近しい人たちもやっぱりエヴァンジェリストだった。そのエヴァンジェリストが実際の開発も出来ると考えて会社を作り、そして結局は出来なかった。Fさん自身がその会社に連ならなかった理由は知らないが、もしかしたら開発なんて出来ないことがわかっていたのかもしれない。逆に言うと会社を立ち上げたエヴァンジェリスト達は、オブジェクト指向というジャンルに純粋だったのだろう。

実際の開発現場で役に立つオブジェクト指向はクラスライブラリ等の、実装に即した渋い技術であることが多い。そうではないOOAとかOODとかいうのはなかなか難しい。ROSEが吐き出した大量のgetter setterのみを含んだクラスをObjectStoreに入れるという幼稚な手法で開発となるのだが、これを他社にやらせるのはOKだが自分がやるのは明らかに失敗だ。そんなもので開発なぞ出来るわけがないが、開発だけ他社に振っていればその他社が無能だったと言うことで済むからだ。そのエバンジェリストたちは最後には社内の人間を無能呼ばわりするような結果になった。もともと出来もしないことを自社でやったわけだから目に見える結果だったのだ。今思うと、言い訳ではなくて、当時本当にそう思ったのでないだろうか?別に誰かを貶めようと思っていたのではないのかもしれない。

僕もそろそろ40だ。歳をとった。Fさんも生きていればかなりの年齢だ。Fさんは本当のところどう思ってやっていたのだろうか。彼は口には出さなかっただけで他のエヴァンジェリストたちと違う思いがあったように思えてならない。ベンチャーをやめるときにFさんに会いたくなったのでメールを送ったのだが、スルーされてしまった。顔を合わせたときに「君のメールが埋もれていて気づかなかった。ごめんね」と言われてしまって結局話を聞けなかった。当時どういう考えを持っていたのか聞いてみたいものだ。生きているか死んでいるかもわからないが。

getter setterしかないクラスを作るのはオブジェクト指向的ではない

ある日いきなりアクセスが増え始めた。まぁ、どうせ一時的なものだろうから、今のうちに何かと書いておこう。

オブジェクト指向入門書で一番の問題は、動物クラスから派生したキリンクラスとかいう説明をすることだ。もしくは、だった。こういった例は実に説明しやすい。多重継承だって完璧だぜ。ポリーモルフだって、dog->bark()でOKだ。じゃあ何が問題なのか?どっかのだれかが一般システム思考というのはよろしくないといっていたが、それと同じことだ。

こういった本を読みオブジェクト指向に入っていった人は勘違いする傾向が多い。何でもかんでも一般化してしまいたがる。だから、役にも立たないクラスをたくさん作ることになる。フレームワークで規定されているなら仕方がない。フレームワークとはそういうものだからだ。そうでもないのに、getter setterしかないクラスをたくさん作ってどうなるというのだ。直接アクセスをさせないから安全?それは明らかに間違っている。

class Human{
private:
String  name;
String address;
public
        String getname()
String getAddress()
        String setname()
String setAddress()

}

human.name と書くことが、human.setnameと書くよりどれだけ安全だというのだ。
そしてこれはカプセル化では決してない。何一つ隠蔽していないでしょ。データ構造を見せずに処理を行ってこそカプセル化なわけだ。だから単純なgetter setterしかないのならばカプセル化とは完全に無関係だ。犬や猫に限らず、現実世界から想定したものをデザインに加えると、ほとんどのクラスがスカスカのgetter setterのみになる。だから僕らは現実世界から想定したクラスを作成するべきではないのだ。

もう一度クラス作成のメリットを思い出そう。データとその操作を一緒くたにできることだ。だから、クラスを作成するのに一番役に立つのは、個別メンバにいちいちアクセスさせるのは面倒であるような構造をもったデータ型がある場合だ。XXTreeとかXXMatrixなんてものだと最適だろう。

だから間違ってもDBから表を作って画面に出すだけなのに、DBの内容をわざわざ人間クラスやらに再構築して、画面で再構成などしてはいけない。そのDBに人間が直感的に理解できる現実世界の意味などないかもしれないが、表という構造にはそれ以上の確実な価値があるからだ。インピーダンスミスマッチなどというものは実際存在せず、仕事もしないおたく連中が作り出した妄想に過ぎない。

オブジェクト嗜好に愛をこめて

「実はオブジェクト指向ってしっくりこないんです」から4年

 相互リンクも張らずにひっそりやっているページなのに、何か人が多いと思ったらここから来てたのか。ふふふ、上記リンクが僕の別名HPだとはしらずに・・・・・・ウソだよ。

一言だけ言っておくと、僕のこの話は4年どころではなく10年以上前の話だ。もしも10年前といわれたら、彼とはどこかで一緒に仕事したという疑いを持ったに違いない。デザインパターンをそこまで批判的に語る人間というのは結構限られているからだ。

デザインパターンが一般教養的に語られる状況でそれが役に立たないことに気づく、そういう場合に謙虚にもこう思ってしまう人が結構いる。「有名な人たちが言っていることだし、それが役に立たないのは自分たちが悪いんじゃないか」と。そして、そう考えない人間もいるが少数派だろう。その社会不適合者は、もともと斜に構えているかその有名な人たちが出来ないということを知っているかだ。僕は後者だ。そして、有名人に近づくきっかけとなったのは「有名な人たちが言っていることだし、それが役に立たないのは自分たちが悪いんじゃないか」 という思考だった。若かったなぁ。 

まぁ、そんな取るに足らない話より明日の名人戦が気がかりだ。羽生奪還なるか。 

今さらながらデザインパターンを語る

デザインパターンはもはや最前線の話ではない。でも僕がこの業界に入った頃は一世を風靡していたものだ。MVC構造を広めたという意味では一役買ったが、その過程でさまざまな弊害をもたらした。こどもはかなづちを持つと何でも叩きたがる、ということわざがあるがまさにあの頃そんな連中が多かった。大学を出たばかりでものの分かっていない僕もそうだった。そして、この道何十年の人でもそういう人は結構いた。目的のために手段を選ばないのは立派なことだが、手段のために目的を選ばないのは単なるオタクなのだ。そしてそれを誇らしげに語るから始末が悪い。オブジェクト指向コンサルと言われる連中がエンドユーザーにまで「なんとかパターンを使って設計します」がと話すような世界になっていて客からしたらそんなこといわれても知らんのだが、彼らは得意満面だった。

こんなこと
を以前書いたが、これはパターンラングエッジというデザインパターンの先祖となったものが目指した考えに似ている。文脈混みで短い言葉で表現できるのならばより高度なことが表現できるはずだ、そういう考えだ。じゃあデザインパターンは何が悪かったのだろう。デザインパターンを考えた4人と彼らを支持した連中(当時新人の僕も含む)は、まともに仕事をしたことが無い連中だったということだ。そして業界数十年という人たちにさえそういう人たちがいたのだ。なぜ彼らが仕事したことがないと断言できるのか、それは示されたパターンが現場において語られることがすくないからだ。ほとんどのパターンはプログラマの会話の中に出てくるものではない。プログラマの方は考えて欲しいのだが出てくるパターンはなんだろうか?コンポジットなんて使わないし、イテレーターなんてそもそもパターンとして語る価値も無いものだと思うのだが。つまり、現場の要望から生まれたものではなく、妄想からこれらは必要であるに違いないと決められたものなわけだ。現場を知らないのは明白だ。

文脈混みで高次元のことを語りたいのなら、それがまず妥当に使用されるもので無ければならない。そして、その妥当性を判断できるのは現場の人間だけだ。だから、研究肌な人間や仕事ができない暇人でそれを決めてはならないのに、よくわからないオタクの決めた23のパターンがどうこう言っている時点で現場では使えないわけだ。一応自分たちでパターンを作ろうという試みはあったのだが、集まる人間がそもそも現場の人間でないのが災いしてものにならなかったのではないだろうか。
最新コメント
QRコード
QRコード
  • ライブドアブログ