| 著作一覧 |
結局、文字化けの原因は言語設定Neutralのダイアログに対して（良くわからない理由により）日本語用メッセージが設定されていたためでした。原文に置き換えたので、解消しているはずです。
ムムリクさん、木村さん、どうもありがとうございました。
年輪とか魚の鱗のようなもので、最初はコアしかないのだが、そのまわりにライブラリとかがかぶさって、それを固めたコンポーネントがある。
開発時にパターン化できるようにモデルを与えるフレームワークとは別に、実行時にコンポーネントの相互運用を確保するためのフレームワークがある。
別のところにサービスがあって、より落とし込んでサブジェクトと呼ぶことにする。
ここにおいて、サブジェクト→フレームワーク→コンポーネントという3つ組ができる。
サブジェクトというのは、外部からは、情報をくれといえばくれて、情報を作れといえば作り、消せといえば消し、変えろといえば変えるものだ。副作用の有無（具体的にはサブジェクト間の相互作用）は、外部にとっては関心外である。当然だが、サブジェクトに対して作成した項には識別子が必要である。
ここで、RESTを適用することを考える。
その先を考える。
すると、あるサブジェクトのふるまいは、クライアントの事情や大人の事情で時々別のものとなる。
これをコンテキストと呼ぶ。
コンテキストを上のRESTなシステムに適用することを考える。
URLは変わらない。コンテキストは周辺事情であり、リソースそのものを変形したり、表現に影響したり、あるいはなんらかの副作用を伴うとしても、そのサブジェクトのそのリソースが異なるものになるわけではないからだ。
3種類の実装が考えられる。
1つは、URLの先でコンテキストによって実際に起動されるサブジェクトを変える方法で、それはルーティングの役割である。サブジェクトは静的なコンポーネントで良い。この方法は、つまらないし、まじめな実装であれば、コンテキストの増加によるコンポーネントの爆発的増加という結果となり、それはすべての条件判断のための実装継承のようなもので、捨てられた過去の方法だ。
1つは、OOな仕組みで、サブジェクトはクライアントごとに1インスタンスを割り当てることを前提とすれば、実行時に動的な変形が行われればよい。たった1つのサブジェクトが100クライアントを相手にしているときは、100の異なるふるまい＝コードを持ったインスタンスとして動作する。このふるまいの変更をどのように記述できるかは、1つのサブジェクトそのもので、関心領域だ。おそらく、最短はAOPでコンテキストとアスペクトの対応付けかもしれないが、現在のAOPの記述方法、つまり主となるモジュールに対応する少ないアスペクトという方法では、最初の方法と同じくコンテキストの増加（コンテキストが実行順にも影響すると前提すれば、加算でなく、べき乗となる）を整理して記述することはできない。
考え直そう。多数のデータを素早く整理して扱うための道具を利用する。すなわちコンピュータとプログラムである。幸いにしてノイマン型のコンピュータを使っているので、コードとはデータである。
……この方法は、詳細が記述できるようになったBPELのようなもののように見える。使えないな。
というわけで、3番目の方法を考える必要がある。
というような、話だったのかなぁ？
ジェズイットを見習え |
ありがとうございます。解消されていました。