憂鬱本を買ってみました

javablack さんが最近とりあげ、 ちょっとだけ話題再燃したの憂鬱本 こと「憂鬱なプログラマのためのオブジェクト指向開発講座」。以前借りて読んだことがあるのですが、「酷いわ」と思ったこと以外具体的なことは何も覚えていません(^^;

で、具体的になにが酷かったのかのかな？とザザッとWebを流してみたのですが、見つからない。というか「これはいい本だー」という感想ばっかりで、予想以上に「酷い」というレビューがないのに改めてビックリです。

むー、これはネチっこいレビューの需要があるかな？とスケベ心をだして買ってしまいましたョ。

憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection)

で、改めて読み直してみますと、やっぱりこれは酷いと言っていいと思います。

Smalltalk ファンとしては、

オブジェクト指向といったらSmalltalkでプログラミングすることである,という定義が成り立っていた時代がありました.その当時はSmalltalkで大規模なビジネスシステムが書かれることはほとんど無く,小さな実験プログラミングが主でした.当然のことながら,緻密な設計が必要とされる機会は少なく,クラスライブラリをうまく使って手短にプログラムを組み上げることが重要視されました.

の記述だけで、もうこんな本燃やしてしまえ！という憤りを隠せません。

Smalltalkを使ったことが無くたって、GoF本にはSmalltalkのクラスライブラリについてしょっちゅう言及がでてきます。それを目にしていればこのような不埒な発言はとても出来ないと思います。なので、「この著者さんは GoFのデザインパターンすら読まずにOOP を語る迂闊さんですか...orz」 と思ったのですが、この本は 1998年、デザインパターンの訳本は 1999 年発行なのですね。

あー、なるほどー。

この本はどうも伝聞・又聞きの情報を元に、著者の方が試行錯誤して身につけた「オブジェクト指向開発」を解説した本のようです。と、言うと、本を書くのに情報収集や裏取りを怠った言語道断(int *n; *n = 5 みたいな)な本のように感じますが、そうではなく、当時手に入りやすかった情報はおしなべてこんなモンなのかもしれない、仕方がないことなのかもしれません*1。

が、それはそれ。だからといって、この本の内容が良いモノになるわけではないです。容赦せずネチっこく指摘しちゃいましょう。

* * *

この本のまずいところはいっぱいあるのだけれど、大きなのを二つだけ。一つはポリモーフィズムの意味や使いどころを著者自身が理解していない所です。

序盤であれだけ「クラスは型」と、ユーザ定義型であることを強調しつつも、継承の話は実装継承の事ばかりで、型が微塵もでてこないです。「型を継承する」という言葉が出てこないだけでなく、概念としても認知されていないようにさえ感じます。当然Java のインターフェイス のようなものも無し。ポリモーフィズムは殆ど無かったことにされているようなものです。（本編ではない「C++入門」と銘打ったコラムの1本として記載されていますが、実装段階における便利な機能にすぎず OO 全体からみれば パセリ、OOAD では存在しないも同然 と言い切っています）

OOPLを使うもっとも大きな福音は「呼び出し元の共通化」が出来るようになったことだと私は考えます。それは本書で言うような「実装上のテクニック」などではなく、設計の前提条件を覆す、非常に大きな要素です。OOPはもちろん、ポリモーフィズムを軽視したままOOAD を語るのだって、片輪の欠けた車で論を進めるようなものですので、この本を読了し終える先に連れて行かれるのは、すくなくとも OO ではない何かです。

もう一つの大きな問題は OOAD に偏重し OOP をないがしろにした内容です。筆者は、「OOPLの祖は Simula 」→ 「Simula は現実をシミュレーションするための言語」 → 「OO は現実をシミュレートするもの」 として、OO とは現実の概念をそのままプログラムに落としこむこと　としています。これはご存じのとおり間違いです。プログラムの抽象化テクニックとは考えないのね...orz

だから、分析結果をコードに落とせなくっても、全然平気。わかりやすい例で言えば、たとえは 9章、10章は状態遷移のお話なのですが、遷移図の作成に2章も費やしておきながら、それをコードに落とせないのを

さてそれでは,今まで見てきた状態の応用概念を,プログラムコード上でどのように実装するかを見てみましょう,といいたいところなのですが,残念ながらここまでくると,さすがのOOPLでもそれをストレートに実装する方法はありません.

とOOPLのせいにする。クラスと違って状態遷移図をそのまま落とし込む言語構造が無いからと言う。状態をオブジェクトにするという発想も出さずに、C のような1関数1状態なコードしか出てこないで、こんなことを言えてしまうのは、現実をUML*2で書き起こすことこそがが、この筆者にとってのOOだからです。

著者の方は不勉強ではなく、むしろ OO に情熱的に取り組んできたのが窺い知れます。なのにこうも変なことを書いてしまうのは、OOとは何かの最初の一歩で道をそれてしまったからとしか思えません。本書全体を通じて感じる「『コードに落とせない分析・設計』はコードよりも価値がある」という雰囲気に、ついつい日頃目にする不勉強な SE(笑) の姿を重ねてしまいます。それはあんまりです。

全体としてはこんな感じです。

* * *

細かい枝葉については、猫の性格の悪さを上手く活用してねちっこく責め上げようと、嫌らしくもトンデモ発言をピックアップしつつ読み進めたのですが、キリが無いので断念しました。以下、めぼしいのを何点か引用しますので、あとは推して知ってくださいまし。

型はクラス（の一種）だ

オブジェクト指向において「オブジェクト」という言葉はあまりに多くのシチュエーションでいろいろな意味で使用される

一般的にはクラスの属性にクラスを持たせるという分析はしません(中にはそういう分析方法を推奨する方法論もありますが,少数派です).

(中略)

クラスが属性になるのは,基本的に数値的などの基本的データです.クラスが属性になる場合もないことはないですが,それも文字列クラスなどのきわめて原始的なクラスに限られます。

「オブジェクト指向の元祖はシミュレーション記述言語だった」「多くのプログラムはシミュレーション的側面を持っている」.この図をみると,これらの言葉に非常に説得力を感じるかと思います.

プログラムコードレベルで「持っている」ことを「has-a関連」というのは,余計な混乱を招くことにもなりかねません.実際に has-a関連という言葉も最近はあまり使われません.
「クラスの関連にはis-a関連とhas-a関連がある」,これはコーディングレベルでのみ使われる言葉と考えた方がいいでしょう.

多態性にいたっては分析設計段階では明確に意識されない概念ということもあり,最近のオブジェクト指向技術のコンセンサスとしては,どちらかというと実装上のテクニックに近いものだと認識されつつあります.（中略）オブジェクト指向開発で特に重要なのは分析／設計工程である,という認識が定着してきている現在では,多態性に特に注目が集まるということはほとんどありません.

オブジェクト指向的視点から考えると,「コピー」という行為自体が不自然である,というのが理由の一つだといえるでしょう.
オブジェクト指向は現実をそのままプログラム化するものである,ということは今まで何度も書いた通りです.現実で何かがコピーされる,というシチュエーションは殆どありません.

• 14ç«  P377 の比較用Cコード(LIST14-1)は 間違いなく Cプログラミング診断室 送り(こんなコード)

オブジェクト指向伝説 と銘打ったコラムは特に酷く、弁解の余地無しな感じです。

* * *

Web は高速道路だなぁ、と思います。わたしの場合は sumim さんの敷設した OOP自動車道に乗って楽ちんOOP学習でした(かわりに Smalltalkジャンクションに連れて行かれてしまったけれどw)。私ごときがすまし顔でこんなん書いていられるのは一重に高速道路のおかけだよなぁ、と思います。

この本が書かれた時代はまだ高速道路が十分じゃなくって、情報を得るコストが高かったから、情報が限られてしまってたり二次情報だったりしたと思います。何より道をそれてしまったとき、教えてくれる誰かもいないのが痛いです。それら環境の不足分を努力とイマジネーションで補って、実践して、ある程度成果を上げれば、OOエバンジェリストを旗揚げしちゃう。大きく間違ってしまうことが怠慢や傲慢の結果では無かった時代なのかな？って思います。（あくまで想像です）

このエントリを書こうと思ったのは、実は javablack さんのエントリ

おれおれオブジェクト指向は何が違うのか． - カレーなる辛口Javaな転職日記

が、あまりにあっさりしすぎていたから。

憂鬱本購入した鬱グラマです。私自身は結構役にたったと思ってる派なのでどの辺が屑なのかリストアップして下さるとありがたいです

http://d.hatena.ne.jp/JavaBlack/20070730/p1#c1186372421

答：全部違う．

いや、そうなんでしょうけど、そうなんでしょうけど(^^;

一応 補足として シーチキンおにぎりのたとえ話をされてますが、「具体的に何処がまずいの？」という疑問に対して「全部ダメ」「たとえ話をすれば...」では、答えになっていません。もっと具体的に書いてよーっ、と思いました。

で、自分でトライしてみたのですが、うーん、これは「全部ダメ」と言うのが一番適切ですね。（←ぉ）

言葉尻レベルでも、章や項で語っている内容レベルでも、本全体としても問題だらけで、キリがありません。なのに部分部分では正しいことが書いてあったりもするので、余計説明しづらいです。じゃあ、憂鬱本の酷いところを総括するとどうなるの？については、なんのかんので シーチキンおにぎりのたとえ話 がとても良くできています。

彼の感想は，

『たしかに腕は悪くないね．

なかなか美味しいシーチキンおにぎりだったよ．

でも、それと私と、一体なんの関係があるんだね？』

この腕が悪くないところがガンで、口から出鱈目を吐いていてくれたほうがまだ良かった。嘘は真実を混ぜ込んだ方がより嘘として効果的になります。なまじキチンとしてるだけに、かえってダメージがでかいという本です。

著者の方はとても勤勉な方っぽいので、今もプログラマとしてご健在なら、かつての自分の解説が今では「間違い」になってしまったことは十分ご承知のことだと思います。この本は「こんな風にみんなで誤解してた時代もあったなぁ」と読むのが相応しい本なのでしょう、きっと。

今日では、Java はもちろん、C++ であったって この本の内容は論外です。分析／設計論だけ切り離したとしても問題が多いと言わざるを得ません。

*1:私は当時プログラマではなかったので単なる想像です。カモノハシ本もメイヤーセンセのオブジェクト指向入門も、既に訳本があったハズですし、Javaだって世に出ていたのだから、もしかしたら仕方が無くないのかもしれません。ホントのところはどうなんでしょう？>詳しい人

*2:本当はOMT法ですが、記法についてはそれこそ枝葉なので