コレって定義以上に掘り起こせる概念なんだろうか。方法」な意味以上に,「実装/設計上」何か有益な意味が出てくるんだろうか。コンテナを作るにあたって参考にしているのは,『J2EEパターン』とそれにまつわるネットの説明で,この本自体はいい本なんだと思う。業務アプリを作る(設計する)場合,読んでなきゃマズいだろう,という本なんだと思います。なんつか,この本やその類似本を読んだ人の理解の仕方が,むふぅ......。必要以上に難しく考えすぎてるんじゃないかと思ったりします。具体的な記述は挙げないけれども,ここまで来るとほとんど与太話に近い(気がする)。サル用語なんでね?みんながみんなでないのは分かってるんですけれど,難しげなコンサル用語を振り回す人の中には,必要以上に難しい言葉を使う割に,本当に基礎的な事柄について全く理解が欠けている人がいたりします。リクエストとレスポンスの組は,プロトコルレベルでどんなデータをやり取りしているのか,とか,ビジネスロジックやコンテキストを抽象化するにあたって,言語仕様的にどのようなオーバーヘッドが発生しているのか,とかいった話。言うまでもなく,上掲『J2EEパターン』がパターン化しているグッドプラクティスは,そのような基礎的な話を踏まえたうえで掲げられているわけで,ここら辺の話が理解できていないと,問題の所在からして既に外していることになってしまう。基礎的な事柄というのは,頭を絞りに絞って理解するような難儀な話でもないわけで,実装や(詳細)設計に直結する実践的な話だったりもする。リクエスト/レスポンスを抽象化する仕組みとして提案されています。この話における問題の所在は,通常のやり方だと,アプリケーションの入出力がプロトコルに依存してしまうところにある。HTTP)に依存してしまうと,それ以降のレイヤーでこのオブジェクトを使うオブジェクトも,プロトコルに依存することになってしまいます。意識して実装/設計しなくちゃいけなくなってしまう,と。まま処理した方が安上がり(になる傾向がある)なはずだけれども,開発側の都合で抽象化しているところがあったりする(と思う)わけです。言わなくても説明できる。このことが,要件を定義したり設計を行うにあたって取捨選択の対象になるわけで(パフォーマンスを重視するのか高可用性を重視するのか),そゆのが本当の意味での設計っつもんなんでねいだろうか,と思うんですけど,どんなもんなんでしょ。あたしの理解不足ってのも多分にあるんでしょうけど,そこまで難しく考えなくちゃいけないもんなのかってな疑念はどうも払拭されない。そもそも,何を目的にしてそんなに難しく考えるのだろう。