- 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/
- 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の方に注力して欲しい。
- 432 名前：デフォルトの名無しさん [04/10/08 05:12:15]
- 前に羽生さんに粘着してた香具師がいたような。。。
ここにもいたりしてw
- 433 名前：デフォルトの名無しさん mailto:sage [04/10/08 09:14:31]
- >>430
じゃエントロピーってなに？
- 434 名前：デフォルトの名無しさん mailto:sage [04/10/08 09:45:49]
- >>417の定義のままだと思うのだが。
- 435 名前：デフォルトの名無しさん mailto:sage [04/10/08 09:51:35]
- >>433
俺≠430だけど、こんな感じじゃない。
持ちうるデータのバリエーションの許容量⇒情報量
それの系全体(平均)⇒エントロピー
あるいは、バリエーションの許容量ではなく
絶対量そのものを指す人も多いかも。
どちらにせよ、Wikipediaのと違いはないと思う。
- 436 名前：433 mailto:sage [04/10/08 10:00:18]
- >>435
実は、情報量と書いてる部分も、エントロピーと書くべきだった気がする。
情報量っていうのは、たとえばJavaコードを1行取り出したときに
S2Container container = S2ContainerFactory.create(PATH);
だったときにどれだけ意外性があるか、という、それぞれの事象に対する量だからね。
- 437 名前：デフォルトの名無しさん mailto:sage [04/10/08 10:06:07]
- >>431
こういう、足りない点を指摘するやつをバカにする方が、スレを荒らしてるわけだが。
こうやって評判落とすようなマネするのって、ヒガさんに実は恨みがあるから？
- 438 名前：デフォルトの名無しさん mailto:sage [04/10/08 10:55:14]
- >>432
そりゃいるだろ。2chだからな。
- 439 名前：デフォルトの名無しさん mailto:sage [04/10/08 10:57:34]
- >>437
恨みはないかもしれないが
妬みややっかみを持っている
ヤシはいるんだろうな。
- 440 名前：デフォルトの名無しさん mailto:sage [04/10/08 10:58:46]
- >>438
羽生さんもいるくらいだからな。
- 441 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:00:56]
- >>439
で、ひがさんを擁護するフリをして、Seasar2は敷居が高い、とか、欠点に対する指摘を受け付けない、とかそういう逆宣伝をしてるわけか。
- 442 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:03:29]
- >>440
羽生さんがいるところには常に粘着するわけか。
大変だな。羽生さんも追っかけもｗ
- 443 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:04:03]
- 恨みを買ってもしょうがないようなところあるからな。
人の話を遮って自分だけ延々と喋るし。
たいていは人の話に耳を貸さないくせにそれは相手によるし。
嫌いなやつは多いだろう。
- 444 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:07:09]
- >>443
まあそういう話はスレ違いってことで。
呼び出しくらうよ。
- 445 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:08:04]
- >>443
何だオマエ知り合いなのか。
本人に直接言ってやれよｗ
- 446 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:12:59]
- 直接言えないから粘着してるんだよｗ
- 447 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:15:20]
- それにしても、よく観察してるね。
- 448 名前：デフォルトの名無しさん [04/10/08 11:22:09]
- DIの利点って、分からん奴らにはメソッドの仕様だけ渡して、
その部分だけ他に影響を与えずに作らせることができるという
ことだと思います。
Rodの本なんかを読んだり、ソース調べたり、自分で試したり
できる人とできない人で、Seasarに関わる人は分化されるのです。
S２を作る人、使う人、使われる人の３種類になるのでしょう。
それぞれのスキルにあった役割を与える。これも優しさです。
使われる人は、他に問題を波及させずにとりあえず、与えられた
メソッドの実装を行えばよくなります。
使う人は、実装を外注しやすくなり、Springと比べてもテストや
設定が格段に楽になります。
その点の説明が公式サイトにないので（日記にはあるが）使われる人が
勘違いして、ちょっと調べれば分かることをここでゴチャゴチャ騒いで
いることでしょう。
ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。
|
 |
