Entry

Java 周りの概念って難しいと思う

2009年03月16日

C++ で作る Web コンテナについて,あれこれクラスを作っていたらなんかできそうな感じになってきたので,半ば本気になりつつあったりします。けど,参考にしている Java フレームワークで使われている概念が難しくて,ちと日和り気味。そんなに難しいコト考えないと作れないのか?これ。

難しいと言うのは,例えば,POJO と DI コンテナの話とか。POJO や DI の定義は分かる。けど,コレって定義以上に掘り起こせる概念なんだろうか。「非-EJB な方法」な意味以上に,「実装/設計上」何か有益な意味が出てくるんだろうか。コンテナを作るにあたって参考にしているのは,『J2EEパターン』とそれにまつわるネットの説明で,この本自体はいい本なんだと思う。つか,J2EE で業務アプリを作る(設計する)場合,読んでなきゃマズいだろう,という本なんだと思います。

J2EEパターン 第2版
J2EEパターン 第2版
posted with amazlet at 09.03.16
John Crupi Dan Malks 近棟 稔 吉田 悦万 小森 美智子 トップスタジオ
日経BP社
売り上げランキング: 82033
おすすめ度の平均: 5.0
5 久々に良いJ2EEの翻訳書にめぐり合えました
5 手抜きのないリファレンス書
5 すきのないJavaデザインパターンの解説書

ただ,なんつか,この本やその類似本を読んだ人の理解の仕方が,むふぅ……。必要以上に難しく考えすぎてるんじゃないかと思ったりします。具体的な記述は挙げないけれども,ここまで来るとほとんど与太話に近い(気がする)。コンサル用語なんでね?

みんながみんなでないのは分かってるんですけれど,難しげなコンサル用語を振り回す人の中には,必要以上に難しい言葉を使う割に,本当に基礎的な事柄について全く理解が欠けている人がいたりします。基礎的な事柄というのは,例えば,ウェブアプリで使われる HTTP リクエストとレスポンスの組は,プロトコルレベルでどんなデータをやり取りしているのか,とか,ビジネスロジックやコンテキストを抽象化するにあたって,言語仕様的にどのようなオーバーヘッドが発生しているのか,とかいった話。

言うまでもなく,上掲『J2EEパターン』がパターン化しているグッドプラクティスは,そのような基礎的な話を踏まえたうえで掲げられているわけで,ここら辺の話が理解できていないと,問題の所在からして既に外していることになってしまう。また,基礎的な事柄というのは,頭を絞りに絞って理解するような難儀な話でもないわけで,実装や(詳細)設計に直結する実践的な話だったりもする。

例えば,上掲書籍にある ContextObject パターン。これは,HTTP リクエスト/レスポンスを抽象化する仕組みとして提案されています。で,この話における問題の所在は,通常のやり方だと,アプリケーションの入出力がプロトコルに依存してしまうところにある。アプリケーションの入出力がプロトコル(この場合は HTTP)に依存してしまうと,それ以降のレイヤーでこのオブジェクトを使うオブジェクトも,プロトコルに依存することになってしまいます。つまり,テストするにしても部分開発するにしても,HTTP を意識して実装/設計しなくちゃいけなくなってしまう,と。アプリケーションの効率からすると,HTTP は HTTP のまま処理した方が安上がり(になる傾向がある)なはずだけれども,開発側の都合で抽象化しているところがあったりする(と思う)わけです。POJO とか言わなくても説明できる。

で,まさにこのことが,要件を定義したり設計を行うにあたって取捨選択の対象になるわけで(パフォーマンスを重視するのか高可用性を重視するのか),そゆのが本当の意味での設計っつもんなんでねいだろうか,と思うんですけど,どんなもんなんでしょ。

あたしの理解不足ってのも多分にあるんでしょうけど,そこまで難しく考えなくちゃいけないもんなのかってな疑念はどうも払拭されない。そもそも,何を目的にしてそんなに難しく考えるのだろう。超疑問です。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN