日々の破片

_ テキストとバイナリー

たとえばrubyのプログラムと拡張ライブラリ。

ASPでのCOMコンポーネント。

シェルとコマンド。

遡ればJCLとプログラム。

こういう組み合わせってWebアプリケーションではどうなっているのかな。部分的にはJSP（最終的にはコンパイルされてJVMにロードされるわけだが）とタグlibとかで無いわけではないが。でもそれは表示にまつわる部分だけで、ASPとCOMコンポーネントというのとは違うようだし。追記：web.xmlだのstruts-configだとかはちと違うと思う。まあ、選択と組み合わせを決定しているテキストではあるから完全に違うというとそれも間違いだとは思うが。

というようなことを疑問に持つ。

もちろん、テキストの部分なんて不要だという考えもあるだろうが、組み合わせるということが制約なのか知恵なのかで判断はわかれるだろうし。

#追記：もちろん、知恵だと僕は考える。

_ イメージ

個体と液体というか、粘性の液体（変かな）で満たした水槽の中にビー玉が入っているようなイメージだろうか。

ビー玉はお互いに点でしか接触できないとか、固いからお互いにうまく結合することはできない。それでドロドロしたというと表現がネガティブだから別の言い方、たとえばしなやかで弾力性に富んだものでそれぞれをくるみながらつなげていくとか。ただ、そっちは柔らかいから簡単に形が変わってしまう。ところが形が変わってはまずいものがある。そこでその部分は固くしておくとかかな。

追記：グルーというのとは随分イメージが異なる。グルーだと緩衝材という意味は見えにくい。繋げるという側面だけを取り上げればグルーかも知れないが、むしろ固いもの同士がぶつかりあってお互いが壊れるのを防ぐという意味を持たせたい。

結局は通信なんだけど、通信は通信としてノイズを混入できるようにしておきたい、つまりjumpとかcallといった機械語で繋げたくはないってことに尽きるのだな。

ノイズを混入っていうとネガティブ方面だから、フィルタリングしたりプロクシをかませたり中継したりが可能なように、つまりホンモノの通信として扱えるようにしたいといえば良さそうだ。

_ メッセージパッシング

で、コンセプトとしてのメッセージパッシングをいかに実際のメッセージパッシングに近づけるかという方法論としてデザインパターンとか（たとえばフィルターとか）があって（まあそういうことができるようになるためにはオーバーヘッドが許容可能になるくらいインフラの整備が必要だったわけだが）、フィルターをかけるためにはインターフェイスベースの継承が（強い型付け言語では）必要とかがあって、でもそれだけでは実体をどうするのよ、ってのがあるから発見のためのプロトコルとしてたとえばJNDIのような生なものがあったりしたけどそれでもプルしてくるわけで、そこにDIみたいなプッシュされてくるものへの転換があったり。

でなんでメッセージパッシングを外に出してそこに介入したいかというと、それがアスペクトであるとか。で合ってるのかな？ ではサブジェクトってのはなんだろう、というのは用語（というのは基盤となる考え方が異なるからだろう）の問題だろうか。で、それは定義だから調べれば済むからおいておいて。

_ 2種類のユニットテスト

あるビー玉のテストについて、そのビー玉それ自身のテストと、そのビー玉が満たすべき入出力のテストの2種類があって、前者はいわゆるユニットテストで良いが（newすれば良いの世界）、後者は交換可能なテストが必要だというのは、通信のノード実装のテストと同じか。

でも交換するというのは、単純な移植でなければ何かが違うはずだから、そこをどうテストするかが後者のキモだな。ではどうするか。副作用型の呼び出しなら副作用の検証をテストに外挿しできる仕組みを用意すれば良さそうだ。っていうか、それがもともとのexpectedが記述できるモックオブジェクトなんだが、それ自身がコードされてコンパイルされてしまうという罠。

_ キンクスのCDレビュー

まあ、評を読まずに買って聴いたわけだが、あらためて眺めていたら

映画『Percy』（性転換手術で男になった主人公がイチモツの元の持ち主を捜すという物語）のサウンドトラックからの「God's Children」も収められている。

なんてぶっとんだ映画というか発想なんだろう(キンクスとは関係ないと思ったけどこのぶっとんだ映画の関係者がサントラとして選んだということであながち無関係なわけでもあるまい)。

_ 多態性

多態性がなければ、オブジェクト指向言語を利用する意味のうち相当大きな部分がなくなるように思える反面（っていうか現実に僕は困るぞ）、別にオブジェクト指向言語云々とは関係ない概念なのか、とまつもとさんの指摘を眺めていて思った。

なんとなく、気分的になのだが、多態関数とオブジェクト指向での（3本柱みたく言われるところの）多態性とは区別して考えていたが、実際には自分でも書いていたりするくらいに、メソッドの引数の型によってそのコンテキストに合った実際の関数（とselfとかthisとかからは取り合えず切り離した言い方をしてみて）を呼ぶ仕組みというのはそれほど目新しいことでもない（と思うんだが実例は知らないが、でも想像はつく）。オブジェクト指向言語だと引数のうちselfやthisが暗黙のうちに利用されるからほとんど意識することはないというだけのことなんだろうか（でも、その意識するかしないかの差は相当大きいようにも思える）。

的を外しているような気がするが指を使って考えを外出しすることにはどうも自分にとって意味があるようなのでやってみるが、多態関数（と書いて、総称関数との違いがわからなくなったぞ。総称関数は多態関数を記述しやすくするための機構で考え方は同じものなのかな？ それはそれとしてsumimさんのWikiは勉強になるなぁ）って、型無し言語だと自分で型をチェックして処理を分岐させるからいまいち楽しくないんだが、どっちが得なんだか。というか単に向き不向きの問題かも。（やっぱりうまく書けないや）

追記：なんかついこないだも多態性（追記：性を抜いて書くのはおかしいんだな）について似たようなことを書いていたような気がしてきたけどまあいいや。

#プログラミング言語の（それ自体の）実装技術と、（その言語の）利用技術、ソフトウェアの（構成に関わる）概念、現実への適用時の（その現実への写像としての）概念、そういったものを同じ用語で語るとわけがわからなくなるかも、というやつの一種かも。オブジェクト指向なんてのがまさにそうなわけだが。

_ 現実つまりビジネスへの適用

1989年頃のオブジェクトにおいては、

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

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

(3)継承を利用した再利用性

なのだが、このうちビジネスロジックとかビジネスコンポーネントとか呼ばれるものに当てはまるものはなんだろうか？

まず、ビジネスロジックはそれ自身のプライベートデータを持たない。ビジネスデータは外部にある。そこにミスマッチを見つけるとDAOとかになるのだが、それも結構妙なのは操作の組みはデータベースマネージャなどのリソース管理の機構の延長であって、その持たれたデータの操作とは異なるものだからだ。で、そこにビジネスメソッドと呼ばれるものを入れるとどうなるかというと、これも単にどこにメソッドを配置するかという実装戦略に過ぎないのは当然。なぜならば元々内部で利用するためのプライベート（アクセス制御の用語と紛らわしいな）データという考え方とは乖離しているからだ。データは伝票じゃないからだ。伝票オブジェクトというのはシンプルだな、それにしても。

継承が利用できるかと言うと、実際には個々のビジネスロジックに継承は無い。というのは1つのビジネスルールが時間の経過とともに変化することはあっても（時間軸に沿った継承。でもこれはそのものの変更を要求するわけだし）、横並びに継承可能ではない（もし継承可能ならそれはビジネスルールと言えるのか？ というかそういうアスペクトはありえるだろうが）。

でも業務の手順はどうだろうか？ 手順は大体決定されていて、伝票を受け取ってルールを適用（というか処理して）たらい回す。その処理そのものはオブジェクトと考えられる。

したがって、ある業務の全体についてはオブジェクトと見ることは可能だ。（って言うか、これはSOAのサービスのことになってしまうな。粒度が粗いからだ。でも実際にはこの単位でカプセル化されているのだからしょうがない。伝統的なオブジェクトの粒度を超えているから別な言葉としてサービスと呼ぶわけだろう。）そこで業務アプリケーションのフレームワークみたいなものは幾らでもある。だがその業務全体の中の個々のプロセス（ビジネスロジック）は伝統的なオブジェクトの概念を持たない。でもあまり正確じゃないな。たとえば特定の料率のようなものはその料率を利用するビジネスロジックのプライベートなデータと見なすことも可能だからだ。その反面、仮に個々のビジネスロジックの中に閉じているように見えても実際には外部要因で決定されて後から与えられるわけだから結局は外部データと考えるほうが正しそうだ。（で、この単位もやはりオブジェクトという言葉との乖離があるので、ビジネスコンポーネントという呼び方があるということになるのかな）

個々のビジネスロジックはこの全体としてのオブジェクトの中のプライベートなデータとして見なすと収まりが良い。収まりが良いというのは、実際のプログラミング言語によってプログラムする対象として考えやすいということだ。つまり実装に結びつくということである。

で、データなんだからそれなりの扱い方があるということになる。