- 1 名前：デフォルトの名無しさん mailto:sage [04/08/09 18:36]
- 一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
最近、気になるのでスレ立てました。
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
それではスタート！
本家 seasar.org
www.seasar.org/
Seasar Projectグループ
seasarproject.g.hatena.ne.jp/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
pc5.2ch.net/test/read.cgi/tech/1077465099/
Java⇔RDBのMapping-Frameworkを語るThre Vol.3
pc5.2ch.net/test/read.cgi/tech/1090653286/
- 331 名前：デフォルトの名無しさん mailto:sage [04/10/06 03:11:04]
- 似たような方向の技術ならスタンダードなものを選んで習得するのが鉄則。
となると、EJB以外の選択肢は無い訳で。
- 332 名前：sage [04/10/06 05:47:27]
- >>330
>ソースコードトレースがし難くなるのは避けられない
これはDIの概念を読んだときからずっと気になってた。スキルの低い技術者が
出入りする大規模なプロジェクトでは影響がでかくない？
モデリングがちゃんとできる人がインターフェースの設計まで
きっちり終えてからコーディングさせないとメンテ不能なソースになりそう。
ひが氏はクラス図すらいらないみたいな事をどこかで言ってた気がするけど。
開発者もメンテナもくーすに従えば解決するのだろうか？
- 333 名前：332 mailto:sage [04/10/06 05:49:57]
- sage間違えて恥ずかちぃ
- 334 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:27:38]
- >>323
何だSpring派がS2叩きしてるだけか
- 335 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:29:10]
- >>324
少数精鋭をどう育てるの？
- 336 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:32:15]
- >>324
スキルのない奴が淘汰されるのは当然だろ？
- 337 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:33:15]
- >>323
で、オマエはRodの言ってることどれだけ理解して実践してるの？
- 338 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:36:42]
- で、お前等結局
１）S2が邪魔
２）ひがが嫌い
３）羽生がウザイ
のどれYO？
- 339 名前：219 mailto:sage [04/10/06 06:38:27]
- 俺のおかげでスレも伸びたし S2 も注目されたわけだ。感謝汁！
- 340 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:55:09]
- 羽生ウザイ
羽生はキチガイ
羽生はデブ
羽生はウンコ
羽生は氏ね！
- 341 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:17:30]
- >323
Spring派とかいうわけでも無いんじゃね？
>331
EJBとがどこがどう似てるんだろ？スタンダードってのは
2.0なのか、それとも先の3.0のことを指してるんだろうか？
先のことを指すんであればそれこそJDOも含めて、流れが
どうなるか判らんと思うんだが
>330
(2)、(3)は今後のくーす次第かな、S2を使うからどうなるわけでもない。
(4)は疑問自体が難しいな、逆にどう思います？
(5)についてはDIコンテナが依存性を注入するので汚染？と
言われてもと思うんだけど
だからトレースやりづらくなるというのは判らなくもない
- 342 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:19:48]
- >340
ID表示が無い板だからといって朝から釣りはやめような
- 343 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:25:08]
- ＞＞３４２オマエ羽生だな（ｗ
- 344 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:25:54]
- 羽生氏ね（藁
- 345 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:29:44]
- 219頑張れ！219は正しい！219はネ申！羽生氏ね！
- 346 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:34:43]
- >343
釣れて小躍りしてるかもしれんけど赤の他人だ、
数少ない君の人生の喜びを奪って申し訳無い。
>332
どうだろう？メンテナというかカットオーバーしてチーム
が解散、保守は引継ぎってところで発生する問題点は
まだ言及されてないんじゃないかな。
diconのまとめかたを含めて330のトレースの問題が
出てくるかもしれない。
- 347 名前：デフォルトの名無しさん mailto:sage [04/10/06 08:59:40]
- >>330
全て、S2やSpringを使えば無条件にというわけではないというのは前提。
> (1) S2を使うと、本当にテストがしやすくなるのか
コンポーネントが独立するので異なる環境で動かしやすくなる。
> (2) S2を使うと、本当によいものができるのか
よいものの定義にもよる。
同じものであれば早くできるようになると考えれば、よいものにするための時間が多く取れるのでよいものができる確率が高いといえるかも
> (3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか
スキルが低い人が一定の品質を保てるのではなくて、スキルが低い人がいても一定の品質を保てる、だと思われ。
コンポーネントの独立度が高くなるので、スキル低い人の影響が減らせる。
> (4) S2を使わないと、上記のようなことはできないのか
DI+AOPを使わないと、初期コストがかかりがち。
ただし、その場合はプロジェクト用フレームワークをかっちり作ることになるので、DI+AOPを単純に使う場合よりも楽にできるかも。
でも、同じ努力をDI+AOPを使ってやったらもっとやりやすくなるだろう。
> (5) 成果物全体がS2に汚染されるけど、それはOKなのか
設計がDI前提のものになるだけで、個々はあまり依存しない。POJOだし。
だから、S2とSpringを切り替えることも、S2を使わなくすることも、個々の部分には影響なくできる。
と思う。
- 348 名前：デフォルトの名無しさん mailto:sage [04/10/06 09:02:27]
- ソースコードのトレースが難しくなるって
んなもん、ＯＯＰになってから諦めてますよ
ただ、インターフェースの設計をかっちりやらないとダメなのは同意
くーすでは単なる単体テストがやりやすいとかでなくて、
設計やら仕様のテストについても言及があってしかるべしだとおもうんだが
- 349 名前：デフォルトの名無しさん mailto:sage [04/10/06 11:28:08]
- 今更だが。
>>245 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 17:56:40
>>半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ
スペースが入ってるほうが見やすいだろ？
Java 標準 API ドキュメント日本語版や Eclipse 言語パック適用後みたいにな。
それとも、こいつらも珍しいから直してもらうか w
- 350 名前：デフォルトの名無しさん mailto:sage [04/10/06 12:21:09]
- >>349
いや、キミを判別しやすくて便利だから構わんのだけど。
- 351 名前：デフォルトの名無しさん mailto:sage [04/10/06 16:19:56]
- >んなもん、ＯＯＰになってから諦めてますよ
俺的にはOOPになってから、スキルの低い人が書いたソースは
前(構造化設計)より酷くなったけど、スキルが高い人が書いたソースは
前と比較にならないくらい読みやすくなったと思う。
クラス図を見ればどの実装がどこにあって、それぞれの責任範囲が見えてくるから。
ヘボが書いたソースは不可思議なところにメソッドが実装されていて
ソースを追うのが困難。スキルはそこそこだけどオブジェクト指向に慣れていない技術者は
画面または機能ごとにクラスを作っていて、「これじゃC言語を構造化設計で
ソースファイル分割していたのと大して変わらんなあ」というのが多い。
- 352 名前：デフォルトの名無しさん mailto:sage [04/10/06 17:59:54]
- 要するに、クラス図があればオッケーってわけで、
なければやっぱりトレースしにくいと思う。
ソースだけで一番追いやすいのは、最後の
「スキルそこそこオブ不慣れ」のソース。
勿論良い悪いは別ですよ。
きちんとドキュメントは残しましょうって事ですかね。
- 353 名前：デフォルトの名無しさん mailto:sage [04/10/06 18:01:39]
- ああそうか、diconファイルが上手いこと
ドキュメントになりゃいいのか。
- 354 名前：デフォルトの名無しさん [04/10/06 18:48:42]
- そりゃそうだ。
DIベースのプログラミングの従来型からの違いはそこにあるわけだし。
- 355 名前：デフォルトの名無しさん mailto:sage [04/10/06 18:57:14]
- >ソースだけで一番追いやすいのは、最後の
>「スキルそこそこオブ不慣れ」のソース。
それは確かにそうかも。
diconからドキュメントにするのはどうかなあ。シーケンス図をかかないと
そのインターフェースで必要十分なのかどうか判断しづらいと思う。
実装に入ってからレビューすると修正作業が多くなるので、やっぱり
あらかじめクラス図とシーケンス図を元にPLがちゃんとレビューして、
修正が終わってから実装に入った方がトータルでは楽じゃない？
まあくーすとは路線が違うのかもしれんが。
- 356 名前：デフォルトの名無しさん mailto:sage [04/10/06 19:14:53]
- DIコンテナのBean定義ファイルは、オブジェクトの関連図になるよね。
コラボレーション図になるのかな。
- 357 名前：デフォルトの名無しさん mailto:sage [04/10/06 19:19:09]
- >>355
そうだよなー。だから開発プロセスについて
あーだこーだ盛り上がるわけだ。
オブジェクト指向のおかげで（せいで？）
ゴリゴリ書いて動けばおしまいってのじゃ
済まなくなったと。
くーす本、楽しみです。
実業務に則して、要件定義から見積もり提示とか
そういうのまで含めてくれるととても嬉しい。
- 358 名前：デフォルトの名無しさん mailto:sage [04/10/06 19:30:30]
- あー、見積りは嬉しいかも
- 359 名前：デフォルトの名無しさん mailto:sage [04/10/06 20:16:01]
- くーすは、要件定義がインプットになるから、要件定義とか見積りとかは無い。
くーすでなくてもいいから、見積りは欲しい。
- 360 名前：デフォルトの名無しさん mailto:sage [04/10/06 20:22:12]
- 結論：EJB3.0 >>> Spring >>>>> S2
- 361 名前：デフォルトの名無しさん mailto:sage [04/10/06 20:30:32]
- EJB3.0が本当に良いならS2EJBが出るような気もするがな
- 362 名前：デフォルトの名無しさん mailto:sage [04/10/06 21:18:38]
- SpringならGeronimo::Springがすでにあるけどね。
プロジェクトだけ。
- 363 名前：デフォルトの名無しさん mailto:sage 釣られ [04/10/06 21:56:25]
- >360
比較できるほど三つとも使い込んでいるのか。
どこでどう差がつくのか是非教えて欲しい。
- 364 名前：デフォルトの名無しさん mailto:sage [04/10/06 22:04:01]
- >360
リリースされてないしさ。まだまだ仕様は変わっていくので
比較は出来ないでしょ。
- 365 名前：デフォルトの名無しさん mailto:sage [04/10/06 22:13:01]
- 是非>>360にEJBとJDOの統合による将来像というのを教えてもらいたい
- 366 名前：デフォルトの名無しさん mailto:sage [04/10/06 23:24:06]
- ひがさんがここを見てるかもしれないんですよね？
ってことはこの板で一番要望が高いS2JSFで「こんなんほしい！」ってのを
書き込むと良いんではないでしょうか？＞ほしがってる方々
- 367 名前：デフォルトの名無しさん mailto:sage [04/10/06 23:35:52]
- はぶ氏が作ったサイトにアクセスしてみたけど、かなり頻繁にMySQLのエラーを吐くな。
もちっと余裕があるサイトに引っ越したほうがいいような。
- 368 名前：デフォルトの名無しさん [04/10/06 23:48:29]
- ロジックとデータの分離って、やりにくくね？
- 369 名前：デフォルトの名無しさん mailto:sage [04/10/06 23:54:26]
- >>366
自分でひが氏のブログにコメントしろ！
ちゃんと返事来るぞ。
- 370 名前：デフォルトの名無しさん mailto:sage [04/10/07 00:07:47]
- >>368
やりにくい部分もあるけど、やれる部分のほうが多くない？
- 371 名前：330 [04/10/07 00:25:56]
- みんな朝からありがﾄﾝ
提案目的は、S2が使えるシチュエーションと注意事項を確認したい、ということね。
330で提示した中で、
(2)と(3)を聞いた意味は、自然なモデリングを変に崩すことになったり、制約が変な方に
働いて妙なものができてこないか
(4)は、書き方がまずかったが、DIパターンの目的である「依存関係のreasonableな分離」
を実現するためにS2は適切なのか
(5)は、importが云々という話の他に、例えば、「コンポーネントはsingleton、状態はク
ライアントが持つ」という考え方に染まったコードになり、理解者（というより共感者？）
以外は気持ち悪い思いをするよね？ということ。
個人的に気になるのは、作成するソフトウェアの複雑性を緩和するブレイクスルーがない
ように見えることなんだよな。
例えば、状態はクライアントに持たせ、コンポーネントはステートレスという思想という
か制約。データとロジックを分離させる方が有効なケースがあるのはわかる。コンポーネ
ントを作りやすくなるケースがあるのもOK（小規模な場合しか想像できないが）。
ただ、一般的には複雑性が増すわけで、適用箇所次第では、複雑性のしわ寄せがクライア
ント側にくるだろうし、コンポーネントも組みにくくなる。
さらに、346が言うように、思想を理解させなければ、こうやって組まれた構成の第三者
の理解およびメンテナンスが困難だ。
というわけで、ぶっちゃけた話、ある程度大きなアプリの適用例とメイキングオブが知り
たいわけだが。これは身をもって体験するのが一番か？
S2に限らず、J2EEのメリットが出るような規模のサンプルって、ほとんど表に出てこない
しね。抽象的か、短すぎる事例報告だけ。というわけで、もーちょっと様子見かな。
- 372 名前：デフォルトの名無しさん [04/10/07 00:27:23]
- >>370
「構造体と関数」って感じで慣れないな。
どうしてもドメインモデルで考えてしまうYO。
ロジックをビジネスロジックとビジネスルールに分けて、
ルールの方はドメインオブジェクトに記述するのはどうだろ。
問題はS2DAOでとってきたEntityに他との関連をインジェクト
しないといけないとこだな。
- 373 名前：330 [04/10/07 00:27:49]
- あ、ソースコードトレースがしにくいってのは、メタデータ使う
フレームワーク全般に言える事ね。オブジェクト指向レベル
どうこうというよりは、頭の中の回路を頻繁に切り替えるのが
おっくう。該当箇所探索もフレームワークのメタデータ特有の
探索方法に特化した知識や支援手段が必要になるのがウザイ。
だいたい、インピーダンスミスマッチがないレイヤーで、
別言語(?)によるコンフィギュレーション使う必然性って
あるんかいな。
テスターは再ビルド権限がないとか、SIerには再ビルド許さん
けど自由度は与えたいとか、そういう運用的理由なら、
わからんでもないが。
というわけで、DIコン使うならPico/HiveMind派（しょーもない着眼点だな、おい）。
- 374 名前：デフォルトの名無しさん [04/10/07 00:33:41]
- ・言葉がダサイ
「ダイコン」「くーす」「から騒ぎ」ちょと恥ずかしい。
・オタくさい
から騒ぎの後、アニソンカラオケ大会。きしょい。
- 375 名前：デフォルトの名無しさん [04/10/07 00:48:22]
- Web層 フレームワーク固有のオブジェクト
↑
DTO
↓
ビジネスロジック層 DTO or ドメインオブジェクト
↑
ドメインオブジェクト
↓
ビジネスルール層 ドメインオブジェクト
↑
ドメインオブジェクト
↓
データアクセス層
こんな感じか。
- 376 名前：デフォルトの名無しさん [04/10/07 00:51:41]
- 戻り値にDIするインターセプタかな。
- 377 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:12:22]
- >372
スマン、ここでのビジネスルールの粒度がイマイチ判らなかった。
揚げ足取りじゃないんだけど、ビジネスって曖昧な伝わり方もするんで、
例えばで良いんで教えて貰えますか？
PicoもHiveMindもよく知らないんだけど、どんな手順でDIするのかな？
>373
S2と関係無くメタデータと上手く付きあわないかんのもしゃあないでしょう。
ひょっとすると、今後は基本設計レベルではメタデータ定義するだけってな
思想になるかもしれんし。実装のソースコード書く人と完全分業みたいなことにも。
>374
ベタベタなほうが伝わりやすいってのもあるしさ。
あ、あとブログ読むと、アニオタ臭いのはコミュニティのごくごく一部な気もする。
ちなみに、から騒ぎ→からさわぎ、な。
- 378 名前：デフォルトの名無しさん [04/10/07 01:33:48]
- >>377
Picoについては
www.picocontainer.org/Two+minute+tutorial
この辺みとけ。お前に与えられた時間は２分間だ（意味が逆）
クソ長いメソッドが多いが、エイリアスで短い名前も用意されてる。
>>367
ブザマだよな（苦笑）。
サービス運用規模の見積もり失敗でつか。
まーボランティアでそれなりの環境用意するのは金かかるので
大変なのはわかるが、今年は2004年です。
- 379 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:38:17]
- >>377
思いつきなんで、はっきりとはしてないんだけど、例えば
・計算フィールドの導出
単純な計算ですむ場合もあるし、導出にStrategyパターンを使う場合もある。
・他エンティティとの関連
User.isMemberOf(Group)みたいなメソッドが欲しい。
ロジック層でisMember(Group, User)ってなるとヤだなって思う。
ビジネスロジックをアクティビティ図で表すとき、それぞれのアクティビティ状態
をルールって呼ぶような感じかな。
- 380 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:41:39]
- >>371
ソフトウェアの複雑性というのは、結局かわらないんじゃないかと思う。
単純に言えば、作るものが決まると、そのプロダクトのエントロピーの下限というのが決まるんではないかと。
そして、管理のしやすいソフトウェアというのは、エントロピーが低いソフトウェアだといえると思う。
フレームワークを使うというのは、エントロピーをフレームワークに押し付けて、コア部分のエントロピーを下げることになる。
ライブラリというのも、エントロピーをプロジェクトの外に追いやる手段だね。
あと、JavaのコードはBean定義ファイルに比べて情報量が多いから、コードを書かかずにBean定義を書くということはエントロピーを下げることにつながる。
そうやって、プロジェクトが管理する成果物のエントロピーを低い状態に保つというのが、すごくざっくり見たDI+AOPの効果ではないかな。
そういう意味では、無限の可能性をもつJavaコードを書く変わりに、数限られたXMLタグで同じことを実現する仕組みであれば、なんでもエントロピーが下げれていいんだよね。
XMLタグの表現力が上がると、それぞれのタグの情報量があがっていくから、またどこかにエントロピーを追いやる必要が出てくるわけだけど。
- 381 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:47:54]
- それを推し進めると、浅見たん提唱のXMLによる伝票指向アーキティクチャになるのか。
- 382 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:48:36]
- 記述の選択肢が少ない、というのが肝ね。
- 383 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:55:40]
- S2はマンセーだけどくーすは疑問
DI（IoC）に関しては >380の言うエントロピーの軽減が目的ってことでFA。
どのコンテナがいいか。
SpringやPicoと比べると、設定の手軽さと機能の豊富さでS2が一番だと思う。
欲しい機能があったとき、Rod Johnsonにメール出すより、ひがさんのblog
にコメントする方が敷居が低いし、レスポンスも速い。
Springはクドい。
くーすは、今公開されているサンプルやトライアル程度では、実際のプロジェクト
になったときに上手くいくか判断しかねる。
本を執筆中ということだけど、付録CDに実装までのサンプルでもあればいいのだが。
今までの開発手法（ユースケース駆動とか）も、本では上手く言ってるけど、
実際大変じゃんってことで、くーすを考案中なんだし、くーすも同じ轍を踏まない
とも限らんすね。
- 384 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:29:30]
- おれはDIコンテナってのは、ファクトリを自前でがりがり書く代わりにコンテナに
お願いできる（ファクトリ機能の外出し）ってことで理解してる。
それ以外の部分（Hibernate連携とか）はあくまでオプションだと思ってる。
くーすはよくわからん。資料がたりん....
- 385 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:53:44]
- くーすの内容をみずにレス
よくある開発手法は、一般的にやろうとしてたり、実装と独立しようとしてて、使えなくなってると思われ。
くーすの場合は、業務システムをSeasar使って作るという具合に、用途を限定しているから、変に一般化しようとしなければ問題ないんじゃなかろうか。
- 386 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:55:05]
- >>385
資料っていうか、資料へのリンクがない気がする。
たぶん、探せば資料はきっとある。
- 387 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:55:10]
- くーすは特にSeasar2に限定されるものではなかったような。
- 388 名前：デフォルトの名無しさん mailto:sage [04/10/07 02:56:07]
- 限定じゃなくて、前提だね。
- 389 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:04:20]
- ごめん、はてなの解説を「Diconを使ったときの・・・」と読み取ってしまってた。
あのへんのブログをぐるぐる回ったけど、くーす自体にはたどり着けなかった。
- 390 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:06:06]
- もうこういうの飽きた
- 391 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:07:58]
- っていうか、くーすってどこにあるの？
- 392 名前：371 [04/10/07 03:10:42]
- >>380
大筋で同意。うまく言葉にできなかったことを、シンプルな言葉でまとめてくれてありがと。
オブジェクト指向はデータとアルゴリズムをバインドさせることで、エントロピーを低減させた
と考えることができるが（C++普及前夜に、関数ポインタを構造体に持たせたコードが増えたのが
なつかしいな）、そういう視点でのブレイクスルーがあるの？ということを
言いたかった。
自由度が小さい記述方法を使うことで局所的なエントロピーは下がると思うが、
全体的にはどうなんだろ。フレームワークと、その根底に流れる思想を理解するための
情報量の扱い、という意味で。
「くーす」という哲学を理解というか納得した者同士は、下げられるって
ことなんだろうな、たぶん。
- 393 名前：デフォルトの名無しさん [04/10/07 03:25:19]
- >>391
弟子による「くーす」教本
marrow.strnet.com/wiki/pukiwiki.php?%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%BC%EA%CB%A1%A4%AF%A1%BC%A4%B9
ひが尊師やその弟子たちによる教えへのポインタ
www.wikiroom.com/tpircs/?higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1
「ダイコン時代５秒前」くらいまでは読んでみてから、
拾い読みするといいかも。少なくとも修羅場突破用
割り切り基準としては優れている。
- 394 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:32:03]
- クレクレ君ばっかだね
- 395 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:36:29]
- >>393
ありがと。
- 396 名前：デフォルトの名無しさん mailto:sage [04/10/07 03:37:57]
- >>394
あなたみたいに頭よくないからね。
- 397 名前：デフォルトの名無しさん [04/10/07 03:53:58]
- >>383
> 設定の手軽さと機能の豊富さでS2が一番だと思う。
設定の手軽さで一番、というのは理解できん。
XMLのvalidation考えると特に。
ある程度大きな、例えばconstractor injectionの
インスタンス数が100とか言い出すと、コストが逆転する
かもしれんけど（まぁそこまでいくとXMLも専用エディタ
使わんと苦しいな）。
フィーリングとしてどれくらい？＞リーズナブルな規模
機能の豊富さはXMLの表現力と等価なわけで、情報量が（略）。
相手が日本人だと楽、というのは同意。自分も含めて
技術者として情けないがな……。一時期、Xalanコミュニティ
とかに顔つっこんでみたことがあるけど、やっぱりスケール
の違いを感じた。ロシア人の英語はよめねー。
>>384
そうね。個人的にもそこがコアだと思う。
AOPはそれを効率よく実現するための手段という考え。
そもそも「FactoryやAFactoryはDIコンテナで代用
できます！」ってのは、DIがFactoryの一流派だけ
なんじゃないかと小一時間（略
- 398 名前：デフォルトの名無しさん mailto:sage [04/10/07 10:26:57]
- >>367
鯖提供者募集中だそうです。
- 399 名前：デフォルトの名無しさん mailto:sage [04/10/07 11:07:16]
- しかし、こういうリフレクション全開のしくみが定着すると、いままで語られてた
「型安全性」だとか「コンパイルによる事前検証」のメリットってどうよ？と思わないでもない。
- 400 名前：デフォルトの名無しさん mailto:sage [04/10/07 14:10:56]
- >>399
大いにそう思う。
いままでだと、型の安全性ってのは基本的にコンパイラが
あるていどの保証(とはいってもぴんきりだが)を
してくれていたわけだが、そういった部分に頼れないと
いうことだからね。
- 401 名前：デフォルトの名無しさん mailto:sage [04/10/07 16:46:22]
- 強い型付けはJavaのウリでもあるけども、オブジェクト指向的な利点を
徹底利用しにくいところもあったね。たとえばListnerを使ったコールバック的な
委譲モデルでも、おれはListnerインターフェイスをimplementsするんじゃなくて、
モデル側にMethodオブジェクトを渡してやるほうがなんぼかましじゃないかと
思ったりもするし。
たとえばThreadにRunnableオブジェクトを渡すんじゃなくて、実行して
ほしいMethodを渡して、Thread側ではinvoke()するとかのほうがもっとフレキシ
ブルなんじゃないかと。Runnableをimplementsする必要すらなくなるし。
こういう、型なんて関係ない、メソッドがあればいい、という使い方は本来、
オブジェクト指向ならではだったわけで。
DIコンテナの場合、利用側ではインターフェイスをもとにしたプログラミングを
行なうわけで、型安全性も十分保証できてると思うし。
- 402 名前：デフォルトの名無しさん mailto:sage [04/10/07 17:14:14]
- キャストごりごりのコードになるよね？
- 403 名前：デフォルトの名無しさん mailto:sage [04/10/07 17:28:17]
- >>401
C#のデリゲート、MSがJavaの仕様に入れようと提案したら
Sunに断られたそうで。
- 404 名前：デフォルトの名無しさん mailto:sage [04/10/07 17:29:09]
- そうだな、DIコンテナ使うとキャストは増える。Object型返すしなあ。
たしかにそこでの型安全性は低くなってると思う。Cast例外って
実行時例外だったよなあ。
- 405 名前：デフォルトの名無しさん mailto:sage [04/10/07 17:39:34]
- キャストは増えない。setter使えば勝手に入れてくれるから
- 406 名前：デフォルトの名無しさん mailto:sage [04/10/07 18:37:15]
- 最初の入り口さえどうにかすれば、あとは大丈夫という感じだね。
そういえば。
オブジェクトの遅延生成ができるともっといいね。
遅延というか、オンデマンド。
getXxx使ったときに生成されるような。
じゃないとイモヅル式にオブジェクトが生成されてしまう。
できるんだっけ？
- 407 名前：デフォルトの名無しさん mailto:sage [04/10/07 19:26:43]
- >>405
いやコンテナ内のオブジェクトはいいんだよ。増えるところは
S2の例：
Hello hello = (Hello) container.getComponent(Hello.class);
この部分ね。まあ対した問題じゃないんだけどね。文法上
cast失敗を気にする必要もないだろうし。
- 408 名前：デフォルトの名無しさん mailto:sage [04/10/07 19:58:36]
- 使うとわかるけどcontainerの外でcontainerを使う方が珍しいと思う
- 409 名前：sage [04/10/07 20:27:27]
- まー依存性注入するところでcontainer使うんだから、
奇麗に設計できている場合はそうね。
- 410 名前：デフォルトの名無しさん mailto:sage [04/10/07 20:43:38]
- インスタンスがいもづる式に生成されまくるという問題ってないの？
- 411 名前：デフォルトの名無しさん mailto:sage [04/10/07 20:57:04]
- インスタンスはcontainerが保持しているから問題なし
- 412 名前：デフォルトの名無しさん mailto:sage [04/10/07 21:15:04]
- そのメモリはどこから出てくるの？
- 413 名前：デフォルトの名無しさん [04/10/07 21:24:48]
- >>380はエントロピーって言葉に何か間違ったイメージを持ってるな
- 414 名前：デフォルトの名無しさん mailto:sage [04/10/07 21:34:59]
- >410
基本はSingletonだ
- 415 名前：デフォルトの名無しさん mailto:sage [04/10/07 21:36:14]
- ソフトウェアにおけるエントロピーの定義を教えてくれませんか？
- 416 名前：デフォルトの名無しさん mailto:sage [04/10/07 22:09:49]
- >>414
そうすると、ソフトウェア中で必要なオブジェクトがすべて生成されてしまうことにならないかな。
- 417 名前：デフォルトの名無しさん mailto:sage [04/10/07 22:13:33]
- >>415
これぐらいは自力で調べる癖をつけようね。
ja.wikipedia.org/wiki/%E3%82%A8%E3%83%B3%E3%83%88%E3%83%AD%E3%83%94%E3%83%BC
これの「情報理論におけるエントロピー」のところにある。
> ある確率分布 p(x) をもつ確率変数 X が与えられたとき、
>
> H(X) = -Σ_{x∈X}{p(x)log(p(x))}
>
>この量 H を 確率変数 X のエントロピー という。
- 418 名前：デフォルトの名無しさん mailto:sage [04/10/07 22:20:41]
- >>413
その言葉のもつ本来の意味を知らず、また、知ろうともせず、
単に語感やニュアンスだけでカッコいい言葉を使ってみる、
というのはどこに行ってもありがちだけどね。
>>380の言わんとしていることは分かったけど。
- 419 名前：デフォルトの名無しさん mailto:sage [04/10/07 22:23:27]
- >>415
ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
整理されてなく、どこになにがあるかわからないソフトウェアはエントロピーが高い。
Javaのコードは選択肢が多いから、一行の情報量が多い。
対して、SeasarやSpringなどのBean定義ファイルは選択肢が少ないので情報量が少ない。
また、規模の大きいソフトウェアも、行ごとの情報量が大きくなる。
系が閉じているときのエントロピーの総和は一定なので、どこかのエントロピーを下げようと思うとどこかにエントロピーを押し付ける必要がある。
整理してどこになにがあるか推測しやすい状態で、選択肢の少ないコーディング技術を使って、コード量を少なくすると、エントロピーが低くなる。
作成するソフトウェアのエントロピーを下げようと思えば、ライブラリやフレームワークを使うことのほかに、開発管理がある。
管理された成果物のエントロピーは低いけど、管理作業自体のエントロピーが高いから。
- 420 名前：415 mailto:sage [04/10/07 22:35:34]
- >>417,419
ありがとうございました。勉強になりました。
- 421 名前：デフォルトの名無しさん [04/10/07 22:58:07]
- くーすを実案件に適用した例ってあるのかな？
- 422 名前：デフォルトの名無しさん mailto:sage [04/10/07 23:05:47]
- いまオフショア開発でやってるんじゃなかったっけ？
- 423 名前：デフォルトの名無しさん mailto:sage [04/10/07 23:08:14]
- >>420
-log(p(x))っていうのが情報量ね。確率の対数。で、エントロピーは情報量の平均(期待値)
- 424 名前：デフォルトの名無しさん mailto:sage [04/10/07 23:17:48]
- ×確率の対数
○確率の逆数の対数
文法のルールが多いほどコードのエントロピーは低くなる。
だから、Javaのコードは型の緩い言語よりエントロピーが低くなるんだね。
そのかわり、文法を勉強するためのエントロピーが高くなる。
- 425 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:13:25]
- >>416
すべて生成したとしてもデータを持たないオブジェクトという前提ならそれほど問題ないのでは？
- 426 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:15:39]
- >416
ソフトウェア中で必要なすべてじゃなくて、DIContainerに登録されているものすべて。
prototypeとouterを除く。
なんでもかんでもDIContainerに登録するわけじゃないよ。
多分416が思ってるほど多くはない。
- 427 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:23:41]
- JFrameとかを登録する方針にしたら、えらいことなりそうだけど。
- 428 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:35:41]
- VBとかDelphiで起動時に全フォームクリエイトしておいて
使うときにはShow()するような感じ？
Delphiでちゃんとしたアプリ作るときはちゃんと生成・消滅を管理するけど(VBはシラネ)、
- 429 名前：デフォルトの名無しさん mailto:sage [04/10/08 01:45:53]
- そう、そんな感じ。
JFrameはシングルトンにしなければいいのかな。
- 430 名前：デフォルトの名無しさん [04/10/08 03:27:40]
- ＞ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
…ヲイヲイ…。
- 431 名前：デフォルトの名無しさん [04/10/08 03:43:00]
- JFrameをDIContainerに登録するなら、prototypeになるはずだから
問題なしだ。VB、Delphiは良く知らんが、一つだけインスタンスを
生成しておいて、必要な時はコピーを生成してShow()するようになる。
これくらい分からんような奴らが、「ドキュメントすくねえ」とか
「全然優しくねえ」とかほざいてるのであれば、ひが氏は気に留める
必要ない。ドキュメント整備した所で使えねーよ。
S2Daoの機能強化やS2JSFの方に注力して欲しい。
|
 |
