テキストとバイナリーたとえばrubyのプログラムと拡張ライブラリ。ASPでのCOMコンポーネント。遡ればJCLとプログラム。いう組み合わせってWebアプリケーションではどうなっているのかな。部分的にはJSP(最終的にはコンパイルされてJVMにロードされるわけだが)とタグlibとかで無いわけではないが。それは表示にまつわる部分だけで、ASPとCOMコンポーネントというのとは違うようだし。追記:web.xmlだのstruts-configだとかはちと違うと思う。選択と組み合わせを決定しているテキストではあるから完全に違うというとそれも間違いだとは思うが。いうようなことを疑問に持つ。テキストの部分なんて不要だという考えもあるだろうが、組み合わせるということが制約なのか知恵なのかで判断はわかれるだろうし。#追記:もちろん、知恵だと僕は考える。イメージ個体と液体というか、粘性の液体(変かな)で満たした水槽の中にビー玉が入っているようなイメージだろうか。ビー玉はお互いに点でしか接触できないとか、固いからお互いにうまく結合することはできない。それでドロドロしたというと表現がネガティブだから別の言い方、たとえばしなやかで弾力性に富んだものでそれぞれをくるみながらつなげていくとか。そっちは柔らかいから簡単に形が変わってしまう。ところが形が変わってはまずいものがある。そこでその部分は固くしておくとかかな。追記:グルーというのとは随分イメージが異なる。グルーだと緩衝材という意味は見えにくい。繋げるという側面だけを取り上げればグルーかも知れないが、むしろ固いもの同士がぶつかりあってお互いが壊れるのを防ぐという意味を持たせたい。結局は通信なんだけど、通信は通信としてノイズを混入できるようにしておきたい、つまりjumpとかcallといった機械語で繋げたくはないってことに尽きるのだな。ノイズを混入っていうとネガティブ方面だから、フィルタリングしたりプロクシをかませたり中継したりが可能なように、つまりホンモノの通信として扱えるようにしたいといえば良さそうだ。メッセージパッシングで、コンセプトとしてのメッセージパッシングをいかに実際のメッセージパッシングに近づけるかという方法論としてデザインパターンとか(たとえばフィルターとか)があって(まあそういうことができるようになるためにはオーバーヘッドが許容可能になるくらいインフラの整備が必要だったわけだが)、フィルターをかけるためにはインターフェイスベースの継承が(強い型付け言語では)必要とかがあって、でもそれだけでは実体をどうするのよ、ってのがあるから発見のためのプロトコルとしてたとえばJNDIのような生なものがあったりしたけどそれでもプルしてくるわけで、そこにDIみたいなプッシュされてくるものへの転換があったり。なんでメッセージパッシングを外に出してそこに介入したいかというと、それがアスペクトであるとか。サブジェクトってのはなんだろう、というのは用語(というのは基盤となる考え方が異なるからだろう)の問題だろうか。それは定義だから調べれば済むからおいておいて。2種類のユニットテストあるビー玉のテストについて、そのビー玉それ自身のテストと、そのビー玉が満たすべき入出力のテストの2種類があって、前者はいわゆるユニットテストで良いが(newすれば良いの世界)、後者は交換可能なテストが必要だというのは、通信のノード実装のテストと同じか。交換するというのは、単純な移植でなければ何かが違うはずだから、そこをどうテストするかが後者のキモだな。副作用型の呼び出しなら副作用の検証をテストに外挿しできる仕組みを用意すれば良さそうだ。いうか、それがもともとのexpectedが記述できるモックオブジェクトなんだが、それ自身がコードされてコンパイルされてしまうという罠。Children」も収められている。なんてぶっとんだ映画というか発想なんだろう(キンクスとは関係ないと思ったけどこのぶっとんだ映画の関係者がサントラとして選んだということであながち無関係なわけでもあるまい)。多態性がなければ、オブジェクト指向言語を利用する意味のうち相当大きな部分がなくなるように思える反面(っていうか現実に僕は困るぞ)、別にオブジェクト指向言語云々とは関係ない概念なのか、とまつもとさんの指摘を眺めていて思った。なんとなく、気分的になのだが、多態関数とオブジェクト指向での(3本柱みたく言われるところの)多態性とは区別して考えていたが、実際には自分でも書いていたりするくらいに、メソッドの引数の型によってそのコンテキストに合った実際の関数(とselfとかthisとかからは取り合えず切り離した言い方をしてみて)を呼ぶ仕組みというのはそれほど目新しいことでもない(と思うんだが実例は知らないが、でも想像はつく)。オブジェクト指向言語だと引数のうちselfやthisが暗黙のうちに利用されるからほとんど意識することはないというだけのことなんだろうか(でも、その意識するかしないかの差は相当大きいようにも思える)。的を外しているような気がするが指を使って考えを外出しすることにはどうも自分にとって意味があるようなのでやってみるが、多態関数(と書いて、総称関数との違いがわからなくなったぞ。それはそれとしてsumimさんのWikiは勉強になるなぁ)って、型無し言語だと自分で型をチェックして処理を分岐させるからいまいち楽しくないんだが、どっちが得なんだか。いうか単に向き不向きの問題かも。(やっぱりうまく書けないや)追記:なんかついこないだも多態性(追記:性を抜いて書くのはおかしいんだな)について似たようなことを書いていたような気がしてきたけどまあいいや。#プログラミング言語の(それ自体の)実装技術と、(その言語の)利用技術、ソフトウェアの(構成に関わる)概念、現実への適用時の(その現実への写像としての)概念、そういったものを同じ用語で語るとわけがわからなくなるかも、というやつの一種かも。オブジェクト指向なんてのがまさにそうなわけだが。現実つまりビジネスへの適用1989年頃のオブジェクトにおいては、(1)それ自身のプライベートデータをもつ。(2)そのデータの上で行われる操作の組みがある。(3)継承を利用した再利用性なのだが、このうちビジネスロジックとかビジネスコンポーネントとか呼ばれるものに当てはまるものはなんだろうか?まず、ビジネスロジックはそれ自身のプライベートデータを持たない。ビジネスデータは外部にある。そこにミスマッチを見つけるとDAOとかになるのだが、それも結構妙なのは操作の組みはデータベースマネージャなどのリソース管理の機構の延長であって、その持たれたデータの操作とは異なるものだからだ。そこにビジネスメソッドと呼ばれるものを入れるとどうなるかというと、これも単にどこにメソッドを配置するかという実装戦略に過ぎないのは当然。内部で利用するためのプライベート(アクセス制御の用語と紛らわしいな)データという考え方とは乖離しているからだ。データは伝票じゃないからだ。伝票オブジェクトというのはシンプルだな、それにしても。継承が利用できるかと言うと、実際には個々のビジネスロジックに継承は無い。いうのは1つのビジネスルールが時間の経過とともに変化することはあっても(時間軸に沿った継承。いうかそういうアスペクトはありえるだろうが)。手順は大体決定されていて、伝票を受け取ってルールを適用(というか処理して)たらい回す。その処理そのものはオブジェクトと考えられる。したがって、ある業務の全体についてはオブジェクトと見ることは可能だ。(って言うか、これはSOAのサービスのことになってしまうな。実際にはこの単位でカプセル化されているのだからしょうがない。伝統的なオブジェクトの粒度を超えているから別な言葉としてサービスと呼ぶわけだろう。)そこで業務アプリケーションのフレームワークみたいなものは幾らでもある。その業務全体の中の個々のプロセス(ビジネスロジック)は伝統的なオブジェクトの概念を持たない。特定の料率のようなものはその料率を利用するビジネスロジックのプライベートなデータと見なすことも可能だからだ。その反面、仮に個々のビジネスロジックの中に閉じているように見えても実際には外部要因で決定されて後から与えられるわけだから結局は外部データと考えるほうが正しそうだ。(で、この単位もやはりオブジェクトという言葉との乖離があるので、ビジネスコンポーネントという呼び方があるということになるのかな)個々のビジネスロジックはこの全体としてのオブジェクトの中のプライベートなデータとして見なすと収まりが良い。収まりが良いというのは、実際のプログラミング言語によってプログラムする対象として考えやすいということだ。実装に結びつくということである。データなんだからそれなりの扱い方があるということになる。いうところにまで立ち戻れば、こういうネタがあります。22:45)お邪魔します。なにか含むところがある(多くは自分の思いついた定義を広めたいと思っている)のだとの印象が強いです。このこととは別に、オブジェクト指向を突き詰めて考えにくいものにしているのは、本来区別されるべきケイの考え方とストラウストラップの考え方が渾然一体のものとして語られることが多いからだと考えています。00:48)>ケイの考え方とストラウストラップの考え方が渾然一体<br>これ、僕も同感です(もっとも前者はすごく大雑把に知ってるつもりというだけですが)。<br>それとは別に、ソフトウェア実装インフラとしてのオブジェクト指向プログラミング言語の恩恵は多大に受けているんですが、どうも仕様の記述方法と実装がうまく結びつかないんでいろいろ考えるんですね。00:58)ここの文脈からは外れてしまうのですが私の修士のときの指導教官は、数学的に定義されていないという意味でオブジェクト指向は十分に定義されていない、と言っていました。<br>例えばlambda計算はきちんと定義されている、というようなことと対比してそういう言葉使いになってます。01:10)そうですね。数学的に定義されていない...という結構重要な切り口をすっかり忘れていました(^_^;)。上の2つに追加させてください。ケイのは哲学的(ライプニッツやプラトン)ですし、ストラウスとラップのは既存技術の寄せ集めに過ぎない(善く言えば組み合わせの妙である)ので数学的な証明は難しいでしょうね。