トップ «前の日記(2004-09-07) 最新 次の日記(2004-09-09)» 編集

日々の破片

Subscribe with livedoor Reader
著作一覧

2004-09-08

_ 妙だな

コンポーネントの10年と、Windowsスクリプティングの歴史があって、なぜ、UDAが無いんだ?

むしろ、UDAのセッションのほうが、なぜ、わざわざDAO(というのはJ2EE風の言い方)を作るのか(J2EEで通せばRowSetを生で使わずに)? についての説得力がある見解とかがあって、現実的だったのだが。O-Rマッピングによるインピーダンスミスマッチの解消ということよりも、抽象化による下位レイヤーの隠蔽というほうが僕も意味があるように思う。後、懐かしかったのはリモート転送の歴史という感じで、Variantの安全配列、UDT、MBV、ADO、XMLとかの変遷の条り。そういやUDTとかあったなぁ。UDTもMBVも使ったものだし。

ちなみに、スクリプティングのセッションは、ビジネスオブジェクトをビューに埋め込むのはダメダメだけど、楽だからついやっちゃうんだよね、いかんいかんという話(+ユーザビリティを考えたら、なんでもHTML、なんでもファットクライアントという、なんでも主義はだめですなとか)。で、ASP.NETはコードビハインドで一見ビューとモデルの分離に見えるけど、それは間違いだから気をつけろっていうように繋がる。確かに、コードビハインドのソースのほうはCだし、WebフォームのほうはVで、Mは別に外に置くのが正しい。というわけで、内容的には良いセッションだったのかも。

コンポーネントの10年については、導入部については我田引水(自分に都合が良いように引っ張る)が目立ち過ぎてたきらいがあった。(冗談交じりかな? と思うのは、抽象化の歴史とか言ってMDA,AOP……DSL,RUP,XPとか全然関係ないものをずらずら並べているところとか。知っててやってるのは間違いないし)

たとえば、MFCやATLは「呼ぶもの」か? いや違う。どちらも「呼ばれる」ものだ。継承ベースで利用するクラスライブラリはテンプレートメソッドに対するはめ込みだからね。当然、利用の仕方は「呼ばれる」となる。それをIoCに繋げるために「呼ぶもの」にしてしまうのは、いささか乱暴すぎる。というように考えてみると(セッション関係なく)なぜ、ファウラーがIoCではなくDIと言い出したかわからないでもない。IoCというと古き良きクラスライブラリと変わらないとも言えるからだ。新たな概念にふさわしい名前が必要であろうということでDIと付けたんだろうな。

とは言え、おもしろかったのは事実である。しかし、HttpModuleという言葉からFilterを想像するのは難しそうだなぁとか思ったけど。

_ 温故知新

うが、「おんちこしん」といくら入れても変換しないと思ったら「おんこちしん」だった。これまで口にしたことなかっただろうな……

というのはどうでも良く、「Common Lispオブジェクトシステム―CLOSとその周辺― bit1989年1月別冊 共立出版」の、井田昌之さんの概説から適宜抜き出してみる。

まず冒頭から

オブジェクトの概念の形成は、1960年代後半のSIMULAにさかのぼることができる。そしてSmalltalkを経て現在のオブジェクト指向言語へと流れている。このことを疑う余地はないが、それらすべてが必ずしも同一のオブジェクト指向概念に基づいているものではないことには留意する必要がある。

ということで、1980年代後半には、すでにいろんな考えがあることがうかがわれる。では、SIMULAとはどんな言語なのか? 既に1989年ですら過去のものとなっているのか、井田氏は丁寧に説明してくれている。

書棚の中のほこりをかぶったSIMULAのマニュアルを久しぶりに取り出してみた。SIMULAにはclass宣言があり、そこでは、ブロック構造の手続きを定義する。その手続きに属する局所データの宣言機構が付属する。SIMULAでのオブジェクト生成とは手続きの呼び出しそのものである。すなわち、オブジェクトというのは関数定義であり、それを生成するというのはその定義を実行させることだというイメージのほうが近い。Common Lispでたとえれば、クロージャの定義機構+単一継承がSIMULAのオブジェクト指向昨日の中心概念といえよう。

そう言えば、この本より前に多分bitを読んでいたら、おそらくCommon LISPのオブジェクト指向機能はクロージャを元にするのかと思ったらdefstructの延長みたいで驚いたというような記述があったのを思い出した(ちなみに、同書では、defclassをdefstructの延長と単純に考えるのは危険だと強調している)。

Smalltalkについては、

一般にはSmalltalkをもってオブジェクト指向の元祖としている。Smalltalkではすべてがオブジェクトであるという大きな特徴が評価されている。

とのことだ。

では、1989年、井田氏の概論ではオブジェクトとはどのようなものとして定義されているのだろうか?

従来、オブジェクトとは、

(1)それ自身のプライベートデータをもつ。

(2)そのデータの上で行われる操作の組みがある。

という認識をもとに、これら(1)、および(2)を包括するものとして考えられてきた。

そしてこれらをまとめて

(1)Encapsulation

(2)Integrity

(3)Operationality

(4)Modularity

という4つの概念を解説した後に結論として

「データと操作の定義に対して抽象データ型とuniform external interfaceが提供され、それを用いて、ソフトウェア開発者はモジュラーにプログラムを作成できる」

と、特徴付けるが、続けて、それだけならADAのパッケージやCLUクラスターもオブジェクト指向になってしまうがそうは呼ばない。なぜなら

オブジェクト指向を特徴付けるもう1つの重要な概念は、「継承」である。それがどんなものであっても、継承(もしくはその発展概念)がなければ意味が無い。上記の4つは「継承」の裏付けをもっているのである。

とまとめている。

では継承とは何か?

「データおよびそれらに対する操作の組みを再定義する手間を省き、それらを部分共有しながら新しいオブジェクトを定義する」概念である。

というように、共有と拡張のための機構と位置付けられている。

いやはや、1989年に読んだときはさーぱりわからなかったが、今読み返すと、なんてわかりやすいことか。

#多態が出て来ないことに注目。多態というのは以前ある方から「人それぞれの多態」のようなusenet上の抜書きみたいなニュース記事を紹介されたことがあるが(残念なことにどこだか忘れた。comp.なんとかだとは思うが)、多分、一意となる定義はなかったように覚えている。

Polymorphism is a ubiquitous concept in object-oriented programming and is

defined in many ways以降を1ページにまとめたのを見たのかな?

本日のツッコミ(全4件) [ツッコミを入れる]
_ sumim (2004-09-09 12:16)

お邪魔します。多態性については、CLOS では総称関数を用いている都合、手続きがオブジェクトに属さないため、そもそも多態性という概念を巧く伝えにくい…という事情もあるのかな、とも思いました。

_ arton (2004-09-09 19:43)

なるほど。でもオブジェクト指向の概説について(CLOSとは直接関係なく)書いているので、CLOSでは伝えにくいから省いたということはないのではないでしょうか(憶測ですが)。<br>個人的には、多態性は結果的にそうなるというだけなので重視されていないのかな、と思っていました。<br>あと、defmethodで引数特定子を付加することで特定のクラスとメソッドを関連付けることができます。(そのため通常のオーバーロードに近いのかと思いましたが考えてみれば)実行するメソッドの決定に引数として与えられたインスタンスの型が影響できるので、多態性というのが実行時まで実際に呼び出すメソッドの選択を後回しにすることであれば、必ずしも伝えにくくもないように思えます。

_ sumim (2004-09-10 01:56)

そうですね。おっしゃるとおり、説明しようとすればけっしてできないわけではないので、あえて省いた(重要視していない)というご推察がやはり妥当なのかもしれません。

_ まつもと (2005-01-21 16:16)

LispにはCLOS以前から多態関数があったから、あえて重視しなかったというのもありえる話かも。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|

ジェズイットを見習え