日々の破片

_ 誤解のJava

Javaのどうしよもないゲッタ／セッタだが、あんなものはJavaの最初の時点からの特徴でもなんでもない。と考える。

なぜならば、String#lengthだ。最も最初のうちに決定するAPIだろう。これがString#getLengthでないことが、その証左である。他にも1.0からあるHashtableのkeys、values、sizeなどもそうだ。

あのアグリー（とここでは設定する）なゲッタ、セッタは、JavaBeans仕様で導入されたものだ。アグリー？（と書きたかっただけなのだが）

JavaBeansは、ActiveXコントロールと同様なGUI部品を記述するための仕様として出発した。これは、Java言語仕様とは独立して上位に構築されたフレームワークなので、当然、その時点のJava言語仕様に従う必要がある。

そこにおいて、既存のAPIと衝突せずに、プロパティ名に対してgetとsetを接頭辞として置くというのは、良いアイディアと思えただろう。そして、より重要なことは、それがJavaBenasというコンポーネントである以上、ツールのドラッグアンドドロップによってフォームへ貼り付けられることと、プロパティ値のパーシステンスに対して外部から読み書きができる必要があったということだ。プロパティへの読み書きは、フォームエディターのプロパティウィンドウに対する設定によって行う。早い話が、コードでgetFooとかsetFooとか書くことは考えていない。少なくとも、それは主たる方法ではない。

その時点で、Java言語仕様にアノテーションが入っていたら、それを利用したことだろう。だが、そんな仕様は含まれていない。使えるのはリフレクションだけだ。

かつ、ActiveXコントロールのマネである以上、コンポーネント開発時にもIDEを利用することは前提している。同様に、プロパティエディタに対して、プロパティ名と型、既定値を埋め込めば、getFoo、setFooは自動生成されることになる。

という程度のプロパティが、大規模開発に役立つはずなんてあるわけがない。というか、大規模というか業務の中核となるアプリケーションクラスにゲッタ／セッタなんて実装しないだろう（セッタインジェクションを前提とすると実装するけど）。

重要な点は、むしろ、JavaBenasというフレームワークが、比較的素直に上位に被せられている点にある。つまり、素のJ2SE APIは、下位APIとして良く考えられていて、その上に、ドメインに特化したフレームワークを構築しやすくなっているのだ（彼らはSwingで試して実証したわけだが、デザインパターンのインスタンス化がしやすい言語/API仕様となっている）。したがって、提供される個々のクラスが妙に何もしないのは、それが理由だ。必要なら上位層で提供すれば良い。

とは言え、いろいろなユースケースが見えてきたので、そこそこ中位くらいのAPIも持つようになってきた、というところだろう。

で、そこで誤解した人たちがいて、妙な癖のあるJavaの書式がなにやら広まったと。（とは言えJavaBeans仕様は標準だからプロパティという概念をインスタンス化する時には従ったほうが良いとは思う）

で、さらに時間が流れて、ActiveXコントロール→JavaBeans→DNA→EJB→.NetFX→　ここにいたってEoDと言ってC#の成果を取り入れて拡張for文とかが来た、というのが3年くらい前。JCPはともかく、Sunはそれほどぶれていないと思うよ。

_ ああ、わかった。

木村さんのとこ経由で西尾さんのとこ経由でオリジナルの質問みてわかった。まさに腑に落ちた。

求道的な人は別として、初心者を名乗るような人たちは、理解する気はないんだ。

つまり、理解しなくても使えるものを望んでいるのだな。（ここに好きなだけ罵倒を入れよう）

ところが、理解していない人たちは、人には何も教えることはできない。小手先の方法は教えられるけど。まさにマニュアル小僧たちだ。マックに行くと見ることができる。「ドリンクはいかがですか？（今は違うような気がするけど、典型例として）」「喉は乾いていないんだ」「？？？？？ドリンクはいかがですか？」「飲み物はいらない」「？？？？？？ドリンクはいかがですか？ って言ってるだろうが！」「！！！！！ いりません」「にっこり」

したがって、抽象的な質問――例：初心者向けのプログラミング言語はなんですか？ ――には回答できない。かりにできても、自分はPHPで簡単でした、とかだけだ。

一方、仮にもCで何かやれているのなら、何かしらの理解をしている（と、信じたい）。理解しているから、抽象的な質問に対しても、自分なりの解釈を垂れることができる。

それが、つまり、C/C++を勧める回答が多い理由だ。

関連するのは「身近な具体例の利用は数学学習の助けにならない」だな。

#でも、そうやって考えを進めると、最初はLispか、Haskellとかが良いということになるのかも知れないな、と一瞬考えたが（追記：多分、おれがこの部分を書いた瞬間に考えたことをきっちり言語化してくれたのが『 実際にはどのプログラミング言語でもプログラムの勉強は出来るよな』だと思う。おれはアルゴリズムと言い切ることになんとなくためらいを感じたのだが、理由はわからない）、コンピュータの物理イメージ（ヒープ、スタック、レジスタ）という意味ではCが良いのか。

#結局、人を見て法を説くしかないのであった。で、妥当なところがマルチパラダイムになっている言語で、RubyとかPythonとかなんだろうな、と思う。

それにしても、元の質問は含蓄がある。初心者と入門者を実は分けているようだ。「入門サイトなどが多数みられる」といった表現がある。入門者は、もちろん、門をくぐるんだから、理解する気があるわけだろうよ。

_ 例の本

ものすごく偉い。みねこあさんが読んで書いてくれている。

たぶん、今読んで書いたのだろうから、正しいとは思う。

というわけで、それを前提に、なぜ、その本がそんなに悪くないどころか、むしろ良かったのかを説明する――というのは、正直なところ細部は覚えてない（10年前だし、実際にはDDJJで連載中に読んだわけで、本も買ったのだがすでに手元にはない）から、読んで感じた印象しか残っていないからだ。

最初に時代背景。

・想定している対象読者は、C++プログラマ（1998年だからJavaはあるだろうとか思ったらそれは間違い。20世紀では、情報は3年遅れでやってくるから、そのころ（1996年から1997年あたり。出版年から少しマイナスする必要がある）のJavaは、遅くて使い物にならないクライアントサイドのHTMLに視覚効果を足すだけの存在という見方がほぼすべて）。で、継承＝実装継承以外の考え方は間抜け扱い（COMのインターフェイス継承とかは、「所詮マイクロソフト」という見られ方をしていたくらい）。

・DDJJという雑誌から、対象読者はWindowsプログラマが主（VBの連載も多かったな、思いだしたけど。酒井法子みたいなペンネームの人とか）。広告もそうだった。したがって、使える言語というのは、VC++、VB、Symantech C++、Visual Cafeとかそのあたり。処理系をそこらから拾ってきて野良ビルドというような環境はあまり考えられていない

・Cはガチ。

・速度命（当時のPCの能力は、今の携帯未満ということは重要）。プロ用の雑誌なので、実用性は重要。「vtblアクセスすると間接参照の分だけjmpが余分に必要になるので、コード量も増えるし速度も低下するので、基本はvirtual付けないこと」というようなノウハウが重視されている。

・ラショナル統一前なので分析分野も戦国時代。

で、より重要なテーゼが支配していたのだ。どこから湧いてきたのかは知らないけれど、「多態＝（C++の）virtual関数」。つまり「多態＝実装継承」。

だから、その本の価値は、みねこあさんがまさにダメ出しの筆頭に持ってきている「多態はどうでも良い」にある。

そこを読者（少なくともおれ）は、「実装継承は重要ではない」と読んだ。(追記：まさにデザインパターンを読むための露払いの役を担ったと言えるな)

あと、Simula系に話が偏るのは、前提としているOOPLがC++だから当然だと思う。それこそ、sumimさんのOOPLの系統分析にしたがえば、むしろ（ある特定の1系統しか取り上げていないことを除けば）一貫しているし、正しい認識ではないかな。

今となってはどうでもよいもののために弁護みたいなものを書くのもあほらしいので、そろそろ嫌になってきたので結論を付けると、

・OOA、OODの結果をそのままC++（STL前の時代だよ）にマッピングするのはやめとけ

・よくわからずにC++で実装継承を使いまくるのはやめろ。そんなものはあれば便利な機能に過ぎない。

・C++を使うには、まずベターCとして型をきちんと扱え（ここはみねこあさんの読み方と一致しないが、おそらくクラスという言葉で代表させているのだと思う）。

・ユーザー定義型重要。カプセル化をおさえろ。

というメッセージを読みとったのであった。

これによって、コード再利用のためのOOPLという考え方から、解放されたわけで、その本には良い印象があるのだ。（has-aのあたりは覚えていないので誤読していただけかも知れないが、内包――コンポジションの意味ではないと思った。has-aも実装継承でインスタンス化するという方法論の否定をしているのだと思うが（そんなバカな、とか言わないこと。その本が良いというのは、相対的に他のがダメだったのだ）。だからis-a以外を継承（＝実装継承）するな、つまり実装の多重継承するな、という意味だと思う）

古いものからでも得るものはあると思ったけど、どうやらコンテキスト抜きに読んでも役に立たないのだなぁ。

というわけで、今読む必要は無いどころか、素直な気持ちで今読むのはダメ、というのが正解なのでしょう。なるほど。

#あと、1997年あたりってのは、テレホーダイで56Kbpsなインターネットがどうにかありますかありませんか、というような時代というのも押さえておきたい。普通の会社だとインターネットには出られないんじゃないかな。ISDN引いた人たちはいただろうけど。参考：1997年で時間が止まった資料が見つかった。Yahoo偉い。歴史を残している。288かぁ……っていうか1997年後半に56Kbpsモデムが出たのか）

いやー、それにしても、今は良い時代だ。

_ 時代は変わる

そういえば、そろそろデザインパターンに即した実装方法もいらなくなるんだろうなぁ、というか逆にダメ出しされるようになるのだろうな、という風向きを感じる。

言語としては成功（シェアという意味で）しなかったSmalltalkの蓄積を、成功した（しかし相当に偏っている）C++のような言語を有効に利用するためにデザインのレベルで（実装のレベルじゃそりゃ無理だろう）示したものがデザインパターンだ、と規定すると、当時主流言語になりつつあったJavaが見事なまでにデザインパターンのインスタンス化に向いていた（実装継承は1系統のみだが、インターフェイス継承の機構を持つ）ので、一気に広まりコンセンサスとなった（のが、21世紀の幕開け）。

（突然思い出したが、ATLのソースを見たとき、多分1996年から1997年の間、このFooBarSingletonとかTataTitiFactoryImplとかいう命名規則（規約かどうかはわからないわけだが）なんだろうとか思ったのが、最初に意識したデザインパターンのインスタンスだな。あとSwingか。本や情報より先にインスタンスを見て覚えたんだよな）

それから10年たてば、デザインではなく実装にそれを持っていてもそう不思議ではない。

そうなると、余計なもの、ということになるから、voidされることになるだろう。

ようやく、これを読み始めた。

On Lisp(グレアム,ポール)

Lispなだけに古さを感じさせないのがおもしろいところだが、1993年の本が2007年に翻訳されたところが、さらにおもしろい。しかも、それが上で書いた、今の風に合っているところがさらにさらにおもしろい。

だからアカデミックな連中で、しかも学んだことを信じて行動するやつは強いんだな。

人海戦術でプログラムする方向、フレームワーク（AもDもひっくるめて）で行く方向だぞう、の2つの方向があって、それに加えてメタプログラミングの方向、の3方向が今の風向きに感じる（クラウドとかはちょっと別にして）。

最初の方向は中間発展段階国の人件費の安さに着目した方向で、20世紀に農業ー工業ときて、ついにサービス業にもやってきたという歴史的には筋が通った発展の方向。

2番目の方向は技術のイノベーションを追求した結果で、これも歴史的に筋が通っている。

3番目はどこまでやれるのか、本当にできるのか、（それこそごくごく一握りのグルだけの世界なのではないか、それを汎化できるのか）良くわからない。しかも危ういのは適用主体が、最初の方向に転んでもおかしくないところだ。そのほうがコストがかからなければいつでもそっちに逃げられるからだ。この方向がメインストリームに浮かび上がったきっかけはRailsなわけだが、それがどういうふうに汎化されるんだろう？

（いろいろ思案中なのでここまで）

身の振り方はともかく、On LispをC++でやるのが

Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート活用術 (C++ In‐Depth Series)(アンドレイ アレキサンドレスク)

これだと考える。

へへ。どちらも「初心者」から進んだ人には手が出ないのはわかる。まともに正直にまっとうに「入門者」から出発しなきゃな。

そこにLLというものが嵌り込むのだ。理解しなくとも使えれば、確かに産業用にはOKだ（と、なれなければ産業用ではない）。

おもしろいなぁ。うーむ。