藤沢のあたりにほんの申し訳程度に立っている他は道路灯がない。カーブが多い(非常に妙な道路で、国道1号から入った瞬間はえんえんと直線なのだが、茅ヶ崎中央あたりから左へ左へカーブしていき、茅ヶ崎西でこんだ、右へ右へカーブしていく)。走行している車は非常に少ない。リアランプを頼ってトレースすることもできないし、当然のように速度も上がる。対向車はみんなハイビームで通り過ぎていき、目を射抜く。街の明かりもほとんどないし、途中マンションを1個通り過ぎるほかは、道路を越えているのは煙突と妙な鉄骨群だけだ。クレーンでもなければ煙突でもなく、意味のある建築物とは思えない。なんなんだろう?街明かりは遥か下に時々煌く程度で、空は黒い。して独りごちる――恒星間飛行と。「光のように速く弾くんだ、出来る限り速く、軽く弾けば、太陽にまで飛んで行ける」。ListBoxあたりから始まって、今ではProgressBarとかまである。この調子で、UsecaseDiagramBoxとActorIcon、UsecaseIconとか、ClassDiagramPaneとClassBox,ClassDialog,AssociationLineとかそういったものも用意しておいて欲しいと思わないでもない。割り算と引き算25×32=800を与えておいて2.5×32=?と出すと80と答える。いうような問題を子供がやっていた。80÷32=?とかだと0にだまされて間違えていたりして。それなりにできるようになったので(というか、機械的に小数点以下の桁数を右辺に入れればすむだけの話だし)、80÷3.2=?を出してみた。同じように2.5とか答えるので、実はわかってないのかと不安になって(というか実際にわかってないわけだが)教えてみたり。思ったが、加減乗除と1口に言っても減算と除算のほうが加算と乗算に比べて遥かに高等な概念を使っているな、ということだったり。(指では数えられないかも知れないが、貸し借りの概念があれば理解できるはずだし)でも除算については、そのためには分数が必要になるよな、とか。分数そのものは一応教わったらしい(が、分母が同じ2つの数の加算のみとか)。PPC用のソースを反映(つまり、AWT問題は取り敢えずあきらめたということです)。ついての説得力がある見解とかがあって、現実的だったのだが。O-Rマッピングによるインピーダンスミスマッチの解消ということよりも、抽象化による下位レイヤーの隠蔽というほうが僕も意味があるように思う。後、懐かしかったのはリモート転送の歴史という感じで、Variantの安全配列、UDT、MBV、ADO、XMLとかの変遷の条り。いやUDTとかあったなぁ。UDTもMBVも使ったものだし。ちなみに、スクリプティングのセッションは、ビジネスオブジェクトをビューに埋め込むのはダメダメだけど、楽だからついやっちゃうんだよね、いかんいかんという話(+ユーザビリティを考えたら、なんでもHTML、なんでもファットクライアントという、なんでも主義はだめですなとか)。ASP.NETはコードビハインドで一見ビューとモデルの分離に見えるけど、それは間違いだから気をつけろっていうように繋がる。確かに、コードビハインドのソースのほうはCだし、WebフォームのほうはVで、Mは別に外に置くのが正しい。いうわけで、内容的には良いセッションだったのかも。コンポーネントの10年については、導入部については我田引水(自分に都合が良いように引っ張る)が目立ち過ぎてたきらいがあった。思うのは、抽象化の歴史とか言ってMDA,AOP......DSL,RUP,XPとか全然関係ないものをずらずら並べているところとか。どちらも「呼ばれる」ものだ。継承ベースで利用するクラスライブラリはテンプレートメソッドに対するはめ込みだからね。利用の仕方は「呼ばれる」となる。それをIoCに繋げるために「呼ぶもの」にしてしまうのは、いささか乱暴すぎる。いうように考えてみると(セッション関係なく)なぜ、ファウラーがIoCではなくDIと言い出したかわからないでもない。IoCというと古き良きクラスライブラリと変わらないとも言えるからだ。新たな概念にふさわしい名前が必要であろうということでDIと付けたんだろうな。言え、おもしろかったのは事実である。HttpModuleという言葉からFilterを想像するのは難しそうだなぁとか思ったけど。温故知新うが、「おんちこしん」といくら入れても変換しないと思ったら「おんこちしん」だった。共立出版」の、井田昌之さんの概説から適宜抜き出してみる。冒頭からオブジェクトの概念の形成は、1960年代後半のSIMULAにさかのぼることができる。Smalltalkを経て現在のオブジェクト指向言語へと流れている。このことを疑う余地はないが、それらすべてが必ずしも同一のオブジェクト指向概念に基づいているものではないことには留意する必要がある。いうことで、1980年代後半には、すでにいろんな考えがあることがうかがわれる。1989年ですら過去のものとなっているのか、井田氏は丁寧に説明してくれている。書棚の中のほこりをかぶったSIMULAのマニュアルを久しぶりに取り出してみた。SIMULAにはclass宣言があり、そこでは、ブロック構造の手続きを定義する。その手続きに属する局所データの宣言機構が付属する。SIMULAでのオブジェクト生成とは手続きの呼び出しそのものである。オブジェクトというのは関数定義であり、それを生成するというのはその定義を実行させることだというイメージのほうが近い。Lispでたとえれば、クロージャの定義機構+単一継承がSIMULAのオブジェクト指向昨日の中心概念といえよう。LISPのオブジェクト指向機能はクロージャを元にするのかと思ったらdefstructの延長みたいで驚いたというような記述があったのを思い出した(ちなみに、同書では、defclassをdefstructの延長と単純に考えるのは危険だと強調している)。一般にはSmalltalkをもってオブジェクト指向の元祖としている。Smalltalkではすべてがオブジェクトであるという大きな特徴が評価されている。1989年、井田氏の概論ではオブジェクトとはどのようなものとして定義されているのだろうか?従来、オブジェクトとは、(1)それ自身のプライベートデータをもつ。(2)そのデータの上で行われる操作の組みがある。いう認識をもとに、これら(1)、および(2)を包括するものとして考えられてきた。interfaceが提供され、それを用いて、ソフトウェア開発者はモジュラーにプログラムを作成できる」と、特徴付けるが、続けて、それだけならADAのパッケージやCLUクラスターもオブジェクト指向になってしまうがそうは呼ばない。オブジェクト指向を特徴付けるもう1つの重要な概念は、「継承」である。それがどんなものであっても、継承(もしくはその発展概念)がなければ意味が無い。上記の4つは「継承」の裏付けをもっているのである。継承とは何か?「データおよびそれらに対する操作の組みを再定義する手間を省き、それらを部分共有しながら新しいオブジェクトを定義する」概念である。いうように、共有と拡張のための機構と位置付けられている。いやはや、1989年に読んだときはさーぱりわからなかったが、今読み返すと、なんてわかりやすいことか。#多態が出て来ないことに注目。多態というのは以前ある方から「人それぞれの多態」のようなusenet上の抜書きみたいなニュース記事を紹介されたことがあるが(残念なことにどこだか忘れた。comp.なんとかだとは思うが)、多分、一意となる定義はなかったように覚えている。