国産オープンソースDIコンテナSeasar V2(S2)

国産オープンソースDI ..

348:デフォルトの名無しさん
04/10/06 09:02:27
ソースコードのトレースが難しくなるって
んなもん、ＯＯＰになってから諦めてますよ

ただ、インターフェースの設計をかっちりやらないとダメなのは同意

くーすでは単なる単体テストがやりやすいとかでなくて、
設計やら仕様のテストについても言及があってしかるべしだとおもうんだが

349:デフォルトの名無しさん
04/10/06 11:28:08
今更だが。

>>245 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 17:56:40
>>半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ

スペースが入ってるほうが見やすいだろ？
Java 標準 API ドキュメント日本語版や Eclipse 言語パック適用後みたいにな。
それとも、こいつらも珍しいから直してもらうか w

350:デフォルトの名無しさん
04/10/06 12:21:09
>>349
いや、キミを判別しやすくて便利だから構わんのだけど。

351:デフォルトの名無しさん
04/10/06 16:19:56
>んなもん、ＯＯＰになってから諦めてますよ
俺的にはOOPになってから、スキルの低い人が書いたソースは
前(構造化設計)より酷くなったけど、スキルが高い人が書いたソースは
前と比較にならないくらい読みやすくなったと思う。

クラス図を見ればどの実装がどこにあって、それぞれの責任範囲が見えてくるから。
ヘボが書いたソースは不可思議なところにメソッドが実装されていて
ソースを追うのが困難。スキルはそこそこだけどオブジェクト指向に慣れていない技術者は
画面または機能ごとにクラスを作っていて、「これじゃC言語を構造化設計で
ソースファイル分割していたのと大して変わらんなあ」というのが多い。

352:デフォルトの名無しさん
04/10/06 17:59:54
要するに、クラス図があればオッケーってわけで、
なければやっぱりトレースしにくいと思う。
ソースだけで一番追いやすいのは、最後の
「スキルそこそこオブ不慣れ」のソース。
勿論良い悪いは別ですよ。

きちんとドキュメントは残しましょうって事ですかね。

353:デフォルトの名無しさん
04/10/06 18:01:39
ああそうか、diconファイルが上手いこと
ドキュメントになりゃいいのか。

354:デフォルトの名無しさん
04/10/06 18:48:42
そりゃそうだ。
DIベースのプログラミングの従来型からの違いはそこにあるわけだし。

355:デフォルトの名無しさん
04/10/06 18:57:14
>ソースだけで一番追いやすいのは、最後の
>「スキルそこそこオブ不慣れ」のソース。
それは確かにそうかも。

diconからドキュメントにするのはどうかなあ。シーケンス図をかかないと
そのインターフェースで必要十分なのかどうか判断しづらいと思う。
実装に入ってからレビューすると修正作業が多くなるので、やっぱり
あらかじめクラス図とシーケンス図を元にPLがちゃんとレビューして、
修正が終わってから実装に入った方がトータルでは楽じゃない？

まあくーすとは路線が違うのかもしれんが。

356:デフォルトの名無しさん
04/10/06 19:14:53
DIコンテナのBean定義ファイルは、オブジェクトの関連図になるよね。
コラボレーション図になるのかな。

357:デフォルトの名無しさん
04/10/06 19:19:09
>>355
そうだよなー。だから開発プロセスについて
あーだこーだ盛り上がるわけだ。

オブジェクト指向のおかげで（せいで？）
ゴリゴリ書いて動けばおしまいってのじゃ
済まなくなったと。

くーす本、楽しみです。
実業務に則して、要件定義から見積もり提示とか
そういうのまで含めてくれるととても嬉しい。

358:デフォルトの名無しさん
04/10/06 19:30:30
あー、見積りは嬉しいかも

359:デフォルトの名無しさん
04/10/06 20:16:01
くーすは、要件定義がインプットになるから、要件定義とか見積りとかは無い。
くーすでなくてもいいから、見積りは欲しい。

360:デフォルトの名無しさん
04/10/06 20:22:12
結論：EJB3.0 >>> Spring >>>>> S2

361:デフォルトの名無しさん
04/10/06 20:30:32
EJB3.0が本当に良いならS2EJBが出るような気もするがな

362:デフォルトの名無しさん
04/10/06 21:18:38
SpringならGeronimo::Springがすでにあるけどね。
プロジェクトだけ。

363:デフォルトの名無しさん
04/10/06 21:56:25
>360
比較できるほど三つとも使い込んでいるのか。
どこでどう差がつくのか是非教えて欲しい。

364:デフォルトの名無しさん
04/10/06 22:04:01
>360
リリースされてないしさ。まだまだ仕様は変わっていくので
比較は出来ないでしょ。

365:デフォルトの名無しさん
04/10/06 22:13:01
是非>>360にEJBとJDOの統合による将来像というのを教えてもらいたい

366:デフォルトの名無しさん
04/10/06 23:24:06
ひがさんがここを見てるかもしれないんですよね？
ってことはこの板で一番要望が高いS2JSFで「こんなんほしい！」ってのを
書き込むと良いんではないでしょうか？＞ほしがってる方々

367:デフォルトの名無しさん
04/10/06 23:35:52
はぶ氏が作ったサイトにアクセスしてみたけど、かなり頻繁にMySQLのエラーを吐くな。

もちっと余裕があるサイトに引っ越したほうがいいような。

368:デフォルトの名無しさん
04/10/06 23:48:29
ロジックとデータの分離って、やりにくくね？

369:デフォルトの名無しさん
04/10/06 23:54:26
>>366
自分でひが氏のブログにコメントしろ！
ちゃんと返事来るぞ。

370:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/07 01:12:22
>372
スマン、ここでのビジネスルールの粒度がイマイチ判らなかった。
揚げ足取りじゃないんだけど、ビジネスって曖昧な伝わり方もするんで、
例えばで良いんで教えて貰えますか？
PicoもHiveMindもよく知らないんだけど、どんな手順でDIするのかな？

>373
S2と関係無くメタデータと上手く付きあわないかんのもしゃあないでしょう。
ひょっとすると、今後は基本設計レベルではメタデータ定義するだけってな
思想になるかもしれんし。実装のソースコード書く人と完全分業みたいなことにも。

>374
ベタベタなほうが伝わりやすいってのもあるしさ。
あ、あとブログ読むと、アニオタ臭いのはコミュニティのごくごく一部な気もする。
ちなみに、から騒ぎ→からさわぎ、な。

378:デフォルトの名無しさん
04/10/07 01:33:48
>>377

Picoについては
URLﾘﾝｸ(www.picocontainer.org)
この辺みとけ。お前に与えられた時間は２分間だ（意味が逆）
クソ長いメソッドが多いが、エイリアスで短い名前も用意されてる。

>>367

ブザマだよな（苦笑）。
サービス運用規模の見積もり失敗でつか。

まーボランティアでそれなりの環境用意するのは金かかるので
大変なのはわかるが、今年は2004年です。

379:デフォルトの名無しさん
04/10/07 01:38:17
>>377
思いつきなんで、はっきりとはしてないんだけど、例えば
・計算フィールドの導出
　単純な計算ですむ場合もあるし、導出にStrategyパターンを使う場合もある。

・他エンティティとの関連
　User.isMemberOf(Group)みたいなメソッドが欲しい。
　ロジック層でisMember(Group, User)ってなるとヤだなって思う。

ビジネスロジックをアクティビティ図で表すとき、それぞれのアクティビティ状態
をルールって呼ぶような感じかな。

380:デフォルトの名無しさん
04/10/07 01:41:39
>>371
ソフトウェアの複雑性というのは、結局かわらないんじゃないかと思う。
単純に言えば、作るものが決まると、そのプロダクトのエントロピーの下限というのが決まるんではないかと。
そして、管理のしやすいソフトウェアというのは、エントロピーが低いソフトウェアだといえると思う。
フレームワークを使うというのは、エントロピーをフレームワークに押し付けて、コア部分のエントロピーを下げることになる。
ライブラリというのも、エントロピーをプロジェクトの外に追いやる手段だね。
あと、JavaのコードはBean定義ファイルに比べて情報量が多いから、コードを書かかずにBean定義を書くということはエントロピーを下げることにつながる。

そうやって、プロジェクトが管理する成果物のエントロピーを低い状態に保つというのが、すごくざっくり見たDI+AOPの効果ではないかな。
そういう意味では、無限の可能性をもつJavaコードを書く変わりに、数限られたXMLタグで同じことを実現する仕組みであれば、なんでもエントロピーが下げれていいんだよね。

XMLタグの表現力が上がると、それぞれのタグの情報量があがっていくから、またどこかにエントロピーを追いやる必要が出てくるわけだけど。

381:デフォルトの名無しさん
04/10/07 01:47:54
それを推し進めると、浅見たん提唱のXMLによる伝票指向アーキティクチャになるのか。

382:デフォルトの名無しさん
04/10/07 01:48:36
記述の選択肢が少ない、というのが肝ね。

383:デフォルトの名無しさん
04/10/07 01:55:40
S2はマンセーだけどくーすは疑問

DI（IoC）に関しては >380の言うエントロピーの軽減が目的ってことでFA。
どのコンテナがいいか。
SpringやPicoと比べると、設定の手軽さと機能の豊富さでS2が一番だと思う。
欲しい機能があったとき、Rod Johnsonにメール出すより、ひがさんのblog
にコメントする方が敷居が低いし、レスポンスも速い。
Springはクドい。

くーすは、今公開されているサンプルやトライアル程度では、実際のプロジェクト
になったときに上手くいくか判断しかねる。
本を執筆中ということだけど、付録CDに実装までのサンプルでもあればいいのだが。
今までの開発手法（ユースケース駆動とか）も、本では上手く言ってるけど、
実際大変じゃんってことで、くーすを考案中なんだし、くーすも同じ轍を踏まない
とも限らんすね。

384:デフォルトの名無しさん
04/10/07 02:29:30
おれはDIコンテナってのは、ファクトリを自前でがりがり書く代わりにコンテナに
お願いできる（ファクトリ機能の外出し）ってことで理解してる。
それ以外の部分（Hibernate連携とか）はあくまでオプションだと思ってる。
くーすはよくわからん。資料がたりん....

385:デフォルトの名無しさん
04/10/07 02:53:44
くーすの内容をみずにレス
よくある開発手法は、一般的にやろうとしてたり、実装と独立しようとしてて、使えなくなってると思われ。
くーすの場合は、業務システムをSeasar使って作るという具合に、用途を限定しているから、変に一般化しようとしなければ問題ないんじゃなかろうか。

386:デフォルトの名無しさん
04/10/07 02:55:05
>>385
資料っていうか、資料へのリンクがない気がする。
たぶん、探せば資料はきっとある。

387:デフォルトの名無しさん
04/10/07 02:55:10
くーすは特にSeasar2に限定されるものではなかったような。

388:デフォルトの名無しさん
04/10/07 02:56:07
限定じゃなくて、前提だね。

389:デフォルトの名無しさん
04/10/07 03:04:20
ごめん、はてなの解説を「Diconを使ったときの・・・」と読み取ってしまってた。
あのへんのブログをぐるぐる回ったけど、くーす自体にはたどり着けなかった。

390:デフォルトの名無しさん
04/10/07 03:06:06
もうこういうの飽きた

391:デフォルトの名無しさん
04/10/07 03:07:58
っていうか、くーすってどこにあるの？

392:371
04/10/07 03:10:42
>>380
大筋で同意。うまく言葉にできなかったことを、シンプルな言葉でまとめてくれてありがと。

オブジェクト指向はデータとアルゴリズムをバインドさせることで、エントロピーを低減させた
と考えることができるが（C++普及前夜に、関数ポインタを構造体に持たせたコードが増えたのが
なつかしいな）、そういう視点でのブレイクスルーがあるの？ということを
言いたかった。

自由度が小さい記述方法を使うことで局所的なエントロピーは下がると思うが、
全体的にはどうなんだろ。フレームワークと、その根底に流れる思想を理解するための
情報量の扱い、という意味で。

「くーす」という哲学を理解というか納得した者同士は、下げられるって
ことなんだろうな、たぶん。

393:デフォルトの名無しさん
04/10/07 03:25:19
>>391

弟子による「くーす」教本
URLﾘﾝｸ(marrow.strnet.com)

ひが尊師やその弟子たちによる教えへのポインタ
URLﾘﾝｸ(www.wikiroom.com)

「ダイコン時代５秒前」くらいまでは読んでみてから、
拾い読みするといいかも。少なくとも修羅場突破用
割り切り基準としては優れている。

394:デフォルトの名無しさん
04/10/07 03:32:03
クレクレ君ばっかだね

395:デフォルトの名無しさん
04/10/07 03:36:29
>>393
ありがと。

396:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/07 10:26:57
>>367

鯖提供者募集中だそうです。

399:デフォルトの名無しさん
04/10/07 11:07:16
しかし、こういうリフレクション全開のしくみが定着すると、いままで語られてた
「型安全性」だとか「コンパイルによる事前検証」のメリットってどうよ？と思わないでもない。

400:デフォルトの名無しさん
04/10/07 14:10:56
>>399
大いにそう思う。
いままでだと、型の安全性ってのは基本的にコンパイラが
あるていどの保証(とはいってもぴんきりだが)を
してくれていたわけだが、そういった部分に頼れないと
いうことだからね。

401:デフォルトの名無しさん
04/10/07 16:46:22
強い型付けはJavaのウリでもあるけども、オブジェクト指向的な利点を
徹底利用しにくいところもあったね。たとえばListnerを使ったコールバック的な
委譲モデルでも、おれはListnerインターフェイスをimplementsするんじゃなくて、
モデル側にMethodオブジェクトを渡してやるほうがなんぼかましじゃないかと
思ったりもするし。
たとえばThreadにRunnableオブジェクトを渡すんじゃなくて、実行して
ほしいMethodを渡して、Thread側ではinvoke()するとかのほうがもっとフレキシ
ブルなんじゃないかと。Runnableをimplementsする必要すらなくなるし。
こういう、型なんて関係ない、メソッドがあればいい、という使い方は本来、
オブジェクト指向ならではだったわけで。

DIコンテナの場合、利用側ではインターフェイスをもとにしたプログラミングを
行なうわけで、型安全性も十分保証できてると思うし。

402:デフォルトの名無しさん
04/10/07 17:14:14
キャストごりごりのコードになるよね？

403:デフォルトの名無しさん
04/10/07 17:28:17
>>401
C#のデリゲート、MSがJavaの仕様に入れようと提案したら
Sunに断られたそうで。

404:デフォルトの名無しさん
04/10/07 17:29:09
そうだな、DIコンテナ使うとキャストは増える。Object型返すしなあ。
たしかにそこでの型安全性は低くなってると思う。Cast例外って
実行時例外だったよなあ。

405:デフォルトの名無しさん
04/10/07 17:39:34
キャストは増えない。setter使えば勝手に入れてくれるから

406:デフォルトの名無しさん
04/10/07 18:37:15
最初の入り口さえどうにかすれば、あとは大丈夫という感じだね。
そういえば。
オブジェクトの遅延生成ができるともっといいね。
遅延というか、オンデマンド。
getXxx使ったときに生成されるような。
じゃないとイモヅル式にオブジェクトが生成されてしまう。

できるんだっけ？

407:デフォルトの名無しさん
04/10/07 19:26:43
>>405
いやコンテナ内のオブジェクトはいいんだよ。増えるところは

S2の例：
Hello hello = (Hello) container.getComponent(Hello.class);

この部分ね。まあ対した問題じゃないんだけどね。文法上
cast失敗を気にする必要もないだろうし。

408:デフォルトの名無しさん
04/10/07 19:58:36
使うとわかるけどcontainerの外でcontainerを使う方が珍しいと思う

409:sage
04/10/07 20:27:27
まー依存性注入するところでcontainer使うんだから、
奇麗に設計できている場合はそうね。

410:デフォルトの名無しさん
04/10/07 20:43:38
インスタンスがいもづる式に生成されまくるという問題ってないの？

411:デフォルトの名無しさん
04/10/07 20:57:04
インスタンスはcontainerが保持しているから問題なし

412:デフォルトの名無しさん
04/10/07 21:15:04
そのメモリはどこから出てくるの？

413:デフォルトの名無しさん
04/10/07 21:24:48
>>380はエントロピーって言葉に何か間違ったイメージを持ってるな

414:デフォルトの名無しさん
04/10/07 21:34:59
>410
基本はSingletonだ

415:デフォルトの名無しさん
04/10/07 21:36:14
ソフトウェアにおけるエントロピーの定義を教えてくれませんか？

416:デフォルトの名無しさん
04/10/07 22:09:49
>>414
そうすると、ソフトウェア中で必要なオブジェクトがすべて生成されてしまうことにならないかな。

417:デフォルトの名無しさん
04/10/07 22:13:33
>>415
これぐらいは自力で調べる癖をつけようね。
Wikipedia項目ﾘﾝｸ
これの「情報理論におけるエントロピー」のところにある。
> ある確率分布 p(x) をもつ確率変数 X が与えられたとき、
>
> H(X) = -Σ_{x∈X}{p(x)log(p(x))}
>
>この量 H を確率変数 X のエントロピーという。

418:デフォルトの名無しさん
04/10/07 22:20:41
>>413
その言葉のもつ本来の意味を知らず、また、知ろうともせず、
単に語感やニュアンスだけでカッコいい言葉を使ってみる、
というのはどこに行ってもありがちだけどね。
>>380の言わんとしていることは分かったけど。

419:デフォルトの名無しさん
04/10/07 22:23:27
>>415
ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
整理されてなく、どこになにがあるかわからないソフトウェアはエントロピーが高い。
Javaのコードは選択肢が多いから、一行の情報量が多い。
対して、SeasarやSpringなどのBean定義ファイルは選択肢が少ないので情報量が少ない。
また、規模の大きいソフトウェアも、行ごとの情報量が大きくなる。

系が閉じているときのエントロピーの総和は一定なので、どこかのエントロピーを下げようと思うとどこかにエントロピーを押し付ける必要がある。
整理してどこになにがあるか推測しやすい状態で、選択肢の少ないコーディング技術を使って、コード量を少なくすると、エントロピーが低くなる。
作成するソフトウェアのエントロピーを下げようと思えば、ライブラリやフレームワークを使うことのほかに、開発管理がある。
管理された成果物のエントロピーは低いけど、管理作業自体のエントロピーが高いから。

420:415
04/10/07 22:35:34
>>417,419
ありがとうございました。勉強になりました。

421:デフォルトの名無しさん
04/10/07 22:58:07
くーすを実案件に適用した例ってあるのかな？

422:デフォルトの名無しさん
04/10/07 23:05:47
いまオフショア開発でやってるんじゃなかったっけ？

423:デフォルトの名無しさん
04/10/07 23:08:14
>>420
-log(p(x))っていうのが情報量ね。確率の対数。で、エントロピーは情報量の平均(期待値)

424:デフォルトの名無しさん
04/10/07 23:17:48
×確率の対数
○確率の逆数の対数

文法のルールが多いほどコードのエントロピーは低くなる。
だから、Javaのコードは型の緩い言語よりエントロピーが低くなるんだね。
そのかわり、文法を勉強するためのエントロピーが高くなる。

425:デフォルトの名無しさん
04/10/08 01:13:25
>>416
すべて生成したとしてもデータを持たないオブジェクトという前提ならそれほど問題ないのでは？

426:デフォルトの名無しさん
04/10/08 01:15:39
>416
ソフトウェア中で必要なすべてじゃなくて、DIContainerに登録されているものすべて。
prototypeとouterを除く。

なんでもかんでもDIContainerに登録するわけじゃないよ。
多分416が思ってるほど多くはない。

427:デフォルトの名無しさん
04/10/08 01:23:41
JFrameとかを登録する方針にしたら、えらいことなりそうだけど。

428:デフォルトの名無しさん
04/10/08 01:35:41
VBとかDelphiで起動時に全フォームクリエイトしておいて
使うときにはShow()するような感じ？

Delphiでちゃんとしたアプリ作るときはちゃんと生成・消滅を管理するけど(VBはシラネ)、

429:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/08 09:14:31
>>430
じゃエントロピーってなに？

434:デフォルトの名無しさん
04/10/08 09:45:49
>>417の定義のままだと思うのだが。

435:デフォルトの名無しさん
04/10/08 09:51:35
>>433
俺≠430だけど、こんな感じじゃない。

持ちうるデータのバリエーションの許容量⇒情報量
それの系全体(平均)⇒エントロピー

あるいは、バリエーションの許容量ではなく
絶対量そのものを指す人も多いかも。
どちらにせよ、Wikipediaのと違いはないと思う。

436:433
04/10/08 10:00:18
>>435
実は、情報量と書いてる部分も、エントロピーと書くべきだった気がする。
情報量っていうのは、たとえばJavaコードを1行取り出したときに
S2Container container = S2ContainerFactory.create(PATH);
だったときにどれだけ意外性があるか、という、それぞれの事象に対する量だからね。

437:デフォルトの名無しさん
04/10/08 10:06:07
>>431
こういう、足りない点を指摘するやつをバカにする方が、スレを荒らしてるわけだが。
こうやって評判落とすようなマネするのって、ヒガさんに実は恨みがあるから？

438:デフォルトの名無しさん
04/10/08 10:55:14
>>432
そりゃいるだろ。2chだからな。

439:デフォルトの名無しさん
04/10/08 10:57:34
>>437
恨みはないかもしれないが
妬みややっかみを持っている
ヤシはいるんだろうな。

440:デフォルトの名無しさん
04/10/08 10:58:46
>>438
羽生さんもいるくらいだからな。

441:デフォルトの名無しさん
04/10/08 11:00:56
>>439
で、ひがさんを擁護するフリをして、Seasar2は敷居が高い、とか、欠点に対する指摘を受け付けない、とかそういう逆宣伝をしてるわけか。

442:デフォルトの名無しさん
04/10/08 11:03:29
>>440
羽生さんがいるところには常に粘着するわけか。
大変だな。羽生さんも追っかけもｗ

443:デフォルトの名無しさん
04/10/08 11:04:03
恨みを買ってもしょうがないようなところあるからな。
人の話を遮って自分だけ延々と喋るし。
たいていは人の話に耳を貸さないくせにそれは相手によるし。
嫌いなやつは多いだろう。

444:デフォルトの名無しさん
04/10/08 11:07:09
>>443
まあそういう話はスレ違いってことで。
呼び出しくらうよ。

445:デフォルトの名無しさん
04/10/08 11:08:04
>>443
何だオマエ知り合いなのか。
本人に直接言ってやれよｗ

446:デフォルトの名無しさん
04/10/08 11:12:59
直接言えないから粘着してるんだよｗ

447:デフォルトの名無しさん
04/10/08 11:15:20
それにしても、よく観察してるね。

448:デフォルトの名無しさん
04/10/08 11:22:09
DIの利点って、分からん奴らにはメソッドの仕様だけ渡して、
その部分だけ他に影響を与えずに作らせることができるという
ことだと思います。
Rodの本なんかを読んだり、ソース調べたり、自分で試したり
できる人とできない人で、Seasarに関わる人は分化されるのです。
S２を作る人、使う人、使われる人の３種類になるのでしょう。
それぞれのスキルにあった役割を与える。これも優しさです。

使われる人は、他に問題を波及させずにとりあえず、与えられた
メソッドの実装を行えばよくなります。
使う人は、実装を外注しやすくなり、Springと比べてもテストや
設定が格段に楽になります。

その点の説明が公式サイトにないので（日記にはあるが）使われる人が
勘違いして、ちょっと調べれば分かることをここでゴチャゴチャ騒いで
いることでしょう。

ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。

449:デフォルトの名無しさん
04/10/08 12:01:27
何だ羽生氏に話を聞いて欲しい奴が騒いでるだけなのか？
ひが氏もいい迷惑だな

>>448
＞ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。
禿同
ひが氏にはどんどんS2を磨いていってもらいたい
とりあえず2.1期待ageだ

450:デフォルトの名無しさん
04/10/08 12:38:41
>>449
話をさえぎられて自分の出番を取られてしまった人じゃないの？

451:デフォルトの名無しさん
04/10/08 15:00:40
やられたらやりかえせｗ

452:デフォルトの名無しさん
04/10/08 15:17:48
>分からん奴らにはメソッドの仕様だけ渡して、
>その部分だけ他に影響を与えずに作らせることができるという

ちゃんと詳細設計ができてれば普通のOOPどころか構造化設計でもそうです。

ドキュメントがどうとかは(俺は言ってないけど)せっかく匿名で本音を吐いてくれてるのに
それを粘着呼ばわりする被害妄想は止めて欲しい

453:デフォルトの名無しさん
04/10/08 15:37:25
DIだと、影響を与えないための労力が少ない、ってことじゃね？

454:デフォルトの名無しさん
04/10/08 16:37:56
枠組みとして用意されているのでいろんなスキルの人がまざっても
平準化しやすい、という事なら納得できるけど。
というか詳細なインターフェース設計をしてからじゃないと実装始められないよ、
ということか。それはいいかも。でも実装し始めてから設計ミスを直すのが
めんどくさそうな肝汁

strutsがMVCモデルを強制してもActionにビジネスロジック書く奴がいて、
結局ちゃんとOOAしないとMVCのメリットがでない
↓
ちゃんとOOA出来る人がいたらstrutsの仕組み必要ない
(設定ファイルの手間が増えるし。taglibは便利だけど)

みたいな事にはならないのかな？全然Seasarの話じゃなくて申し訳ないが

455:デフォルトの名無しさん
04/10/08 17:04:12
DIというか、クラス名やらメソッド名を外部設定ファイルに埋め込むと、リファクタリング機能が効かないから不便かも。

strutsのMVCはアプリケーション全体でいえばVの中のローカルなMVCだからしかたないね。

456:デフォルトの名無しさん
04/10/08 18:15:12
>>453
YES

>>454
だからくーすを作ったんじゃないかな

457:デフォルトの名無しさん
04/10/08 19:38:28
>>448
>使う人は、実装を外注しやすくなり、Springと比べてもテストや
>設定が格段に楽になります。

まじ参考までに教えて欲しいんですけど、Seaser2がSpringと比べて
テストや設定がしやすい部分ってどういうところなんでしょうか？
SpringとSeasar2の比較をいろいろ探したんですが、どれもいまいち
ピンと来ないもので。

458:デフォルトの名無しさん
04/10/08 21:32:42
>>452
人をうんこ呼ばわりしてあげつらったヤシが
いるんだから被害妄想もある程度仕方ない
と漏れは思う。ひが氏の日記が大人しくなって
しまったのが個人的には残念だ。

459:デフォルトの名無しさん
04/10/08 21:39:32
議論のアンチパターン～不毛な議論を避けるために～
URLﾘﾝｸ(homepage1.nifty.com)

460:デフォルトの名無しさん
04/10/08 22:59:10
外注というと書かれるコードの中身は汚くてもいいという印象があってよくない

461:デフォルトの名無しさん
04/10/08 23:06:46
外注はよくないけど、とりあえずS2について言うと、
欲しい機能を（Javaでやるという前提であるならば）考えられうる限りできるだけシンプルに実装できるもので
割と好印象。

462:デフォルトの名無しさん
04/10/08 23:10:56
少なくともJ2EEを作った香具師より頭いいのは確かだ

463:デフォルトの名無しさん
04/10/08 23:13:14
先にinterfaceありきと考えると
仮にコードが汚くてもUnitテストさえ
クリアしていれば安心が得られると
いう利点があるかなと思うけどどうかな？

464:デフォルトの名無しさん
04/10/08 23:18:59
>>463
テストをするのは当然で
汚いのはリファクタリングの原則に反するのでよくない

465:デフォルトの名無しさん
04/10/08 23:22:32
もちろんそうなんだけど
外注に出して汚いコード
だったとしてもまだ安心度が
保てるように思うんだが

466:デフォルトの名無しさん
04/10/08 23:27:35
設計は変わるもんだ。外注にやるとプログラマからのフィードバックが得られない。
S2は外注向けと考えるならそれは間違い。もともとソフトウェア開発はそういうものじゃない。

467:デフォルトの名無しさん
04/10/08 23:38:23
ほんとはみんなデスマが好きなのさ。
どっぷりとデスマに浸かることで、
自分は仕事をしているんだ！
という満足感が得られるからなのさ。

さらに、デスマを解消したり
回避する方法を考えるのは
もっと好きなのさ。
なんでかというと、
自分はこんなすごいことをやったんだ！
という優越感が得られるからなのさ。

Seasarってのはそうやって生まれたの。

468:デフォルトの名無しさん
04/10/08 23:39:03
外注に出さないプロジェクトって、小さなプロジェクトか小さな会社くらいでは？

469:デフォルトの名無しさん
04/10/08 23:45:27
>464
汚いのはリファクタリングの原則に反する、ってのはどういう意味？
リファクタリングの対象になる、ならわかるけど。
ついでにいうとユニットテスト通ってるならリファクタリングも気楽にできるね。

470:デフォルトの名無しさん
04/10/08 23:45:59
>>468
S2の話とはもう違うだろ。
外注に出すところのコスト構造って本当に酷いよ。

471:デフォルトの名無しさん
04/10/08 23:49:42
DI 使うとデバッガ使えないの？テストうんぬんではなく、
ステップ実行とかできないの？

472:デフォルトの名無しさん
04/10/09 00:02:32
>>467
おかげでデスマにならずに済むなら漏れはありがたい。

>>471
S2のコードも全部放り込んでおけばいいんじゃない？

473:デフォルトの名無しさん
04/10/09 01:51:38
>>472
デスマはなくならないよ。

まず>>467でいう満足感と優越感がなくなっちゃうからね。

それに、新たな方法論を導入して解決するのは
「今までのステージにおけるデスマ」であり、
「次のステージにおけるデスマ」が控えているんだよ。

デスマあってのSeasarであり、
デスマある限りSeasatは進化し続け、
そしていつまで立ってもデスマはなくならない。

しかし、これがみんなの幸せにつながる。

474:デフォルトの名無しさん
04/10/09 02:18:01
＞デスマあってのSeasarであり、

(　ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ
　
(；ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ
　　_, ._
（；ﾟ Дﾟ） …?!

'`,､'`,､('∀`) '`,､'`,､

475:デフォルトの名無しさん
04/10/09 02:58:52
>> 457
設定ファイルやテストコードを書くためのタイプ量がS2の方が少ない。
DIを使うと、これらの煩雑さが問題となってくる。

476:デフォルトの名無しさん
04/10/09 07:44:22
>471
DIは問題ない。初期化より後は普通だから。
でもAOPを使うとデバッガで追えない。
バイトコードいじってるやつ全般に言えることだけどね。

477:デフォルトの名無しさん
04/10/09 08:49:04
>>476
AOPを使っても追えるよ。
意味不明なクラスに行くけどそこもトレース実行すればその後は問題なかった。

478:デフォルトの名無しさん
04/10/09 14:05:50
>>476
デバッガで追えないのは、AspectJ。
S2は普通に追える。

479:デフォルトの名無しさん
04/10/09 15:42:43
>>462
J2EEっていうかEJB？
後だしじゃんけんだからなぁ。
DynamicProxyのおかげの部分もあるし。

480:デフォルトの名無しさん
04/10/09 16:24:41
>>479
S2はDynamicProxyは使ってないけどね。
cglibでバイトコードいじっているから同じようなものだけど。

481:デフォルトの名無しさん
04/10/09 16:54:24
・・・そうなんだね。
cglibのページの「Open source projects use cglib」に載ってないのが寂しいけど。

482:デフォルトの名無しさん
04/10/09 23:49:20
バイトコード操作してる地点で実案件に使えるのかなぁ。。
とても使わせてもらえなそうだが。。

483:デフォルトの名無しさん
04/10/10 01:01:18
オイオイ、どういう判断基準なんだ？
といことはcglib使ってるモノはすべてだめなんだね。
HibernateとかSpringとかも。

484:デフォルトの名無しさん
04/10/10 01:37:22
>>483
コンテナ部分は使ってないぞ。Spring。readme.txtに書いてある。
なので、AOPやDAO機能を捨てれば非バイトコード操作なDIコンテナとしては使える。
あと、PicoContainerも非バイトコード操作なDIコンテナだよね。

>>482
なので、あくまでもDIコンテナが使いたいならS2以外の選択もある。
AOPを利用したい時にはS2のほうが簡単だと思うけどね。

485:デフォルトの名無しさん
04/10/10 01:45:20
AOPなければ、意味がかなり減るんだけども。
SpringのAOP定義はめっさめんどり。

486:デフォルトの名無しさん
04/10/10 04:53:02
>>403
偉いなMS。蚊帳の外でもコミットしようとするなんて。
これだけ見るとSUNだめだな。
空のインプリメソッドがゴミのようにある俺のソース…。何とかしてくれ。

487:デフォルトの名無しさん
04/10/10 05:05:49
いろいろ考えたんだけどさ、EJBとかDIコンテナとか
やっぱりなんかくだらない気がしてきた。

アプリケーション毎に必要な機能って違うじゃんか。
（負荷分散・クラスタリング・動的再配置・トランザクション・必要になるパフォーマンス、とかいろいろ）
シンプルな実装をアプリケーション毎に作ったほうが、ムリヤリ共通して使える実装を探さなくてもいい。

488:デフォルトの名無しさん
04/10/10 05:07:32
シンプルに構造を分割する考え方（～層、とかいろいろ）の話を延々としているほうがいいと思うよ。
実装はアプリケーション毎に行こう。

489:デフォルトの名無しさん
04/10/10 05:15:47
>>455
リファクタをキジムナに期待age

490:デフォルトの名無しさん
04/10/10 05:23:48
>>487
それはアプリ毎に必要な機能じゃなくシステムの構成・設定。
487の言う「いろいろ」こそ共通して使える実装部分じゃろ。

491:489
04/10/10 05:56:56
>>330
> ところで、S2が正しくinjectionしてくれるかどうかの
> テストはどう書けば？（汗）
キジムナ使へば下に出るぞ。singletonだけかもしれんが。
それをキャプチャしたのをテスト結果とすると良いかも。

>>399
>>400
キジムナ使え。事前検証バリバリだぞ。

>>作者
コード補完機能ｷﾎﾞｿ

492:デフォルトの名無しさん
04/10/10 08:16:10
>>487
だから、アプリケーションごとに違う非機能要件をAOPを
使って処理するんじゃん。

493:デフォルトの名無しさん
04/10/10 08:30:30
>>486
俺もMSの態度は偉いと思う。
片思いなのがこれまた哀愁がただよってて
ヘンに共感してみたり。いやそりゃヨタだけども。

でもコーディング量が増えても
インターフェイスという考え方で統一したいって
気持ちもちょっと判るんだよねー。

494:デフォルトの名無しさん
04/10/10 08:36:10
>>490

トランザクションの基盤なんて単純なものならほんの数行のコードで実装できるし、
動的再配置するためのライブラリ（ちょっとしたネームサービス）あればいい
クラスタリングや負荷分散となると、それはアプリケーション毎にかなり違うもんだと思う

あんまり仰々しいフレームワークを用意されても、結局複雑にしてしまうだけではなかろうか

495:デフォルトの名無しさん
04/10/10 09:05:12
>>487
そんなこといったらJDBCもいらんってことにならんか？
何を持ってシンプルな実装というかだな。

496:デフォルトの名無しさん
04/10/10 09:41:42
>>494
ぎょうぎょうしいフレームワークって何。
S2はシンプルだと思うけど。
POJOが基本で、コアはDIとAOPの機能だけ。

コア以外の機能もいろいろあるけど、
使えるものは使えばいいし、無理に使わず自前で実装しても良い。

ただ、クラスタリングや負荷分散を自前で実装するやつは、
よっぽどのツワモノだと思う。

497:デフォルトの名無しさん
04/10/10 10:39:55
>>487
EJBはくだらないが、DIはくだらなくないよ。
アプリケーション毎に、というより、アプリケーション内で必要な機能をアプリケーション内で共通して使うためにDI+AOPが有効だと思われ。

498:482
04/10/10 12:58:13
>483

SpringもHibernateもDynamicProxyで代用できませんでしたっけ？
#フル機能使えなくてもさ

DIコンテナってテストが簡単とか、複雑じゃないとか利点ばっか挙げられてるが，
商用EJBコンテナが提供するような分散・スケールアウト手法は確立されているの？

499:デフォルトの名無しさん
04/10/10 13:02:41
>496
毎回毎回自分で実装できるような奴ならいらんのでしょ。
負荷分散・クラスタリング・動的再配置・トランザクションをシンプルな実装で
アプリケーションごとにバグ少なく作成できるような凄い人はうちの周りには
いないけどね。

500:デフォルトの名無しさん
04/10/10 13:10:21
>>499

負荷分散・クラスタリングって、パフォーマンスとの兼ね合いでいろいろ調整いるだろうから、
自分で実装っていうのが基本では。
それを補助く小さなライブラリ（タプルスペース扱うやつは便利だ）があれば満足。

501:デフォルトの名無しさん
04/10/10 13:18:19
>>500
スーパーな人発見。
釣りじゃないならすごいね。
そういうのは、アプリケーションサーバか負荷分散装置だとかに
任せるものだと思っていたよ。

502:デフォルトの名無しさん
04/10/10 13:21:07
まぁ、EJBとかに比べると仰々しくは無いのだけど、
Lightweightなプログラミング言語を使っているとどうしても大げさに感じてしまうのよね。

503:デフォルトの名無しさん
04/10/10 13:24:26
>>500
バイトコードいじくるものより、自分で組んだ負荷分散やらクラスタリングのほうがあてにならんなぁ。
トランザクションも、基盤は数行でも、いろいろなところに埋め込まれて、そっちの方があてにならんなぁ。

504:デフォルトの名無しさん
04/10/10 13:27:27
Lightweightなプログラム言語使ってる人って、ライブラリやフレームワークを勉強して数行でまとめて書けるコードを、頭使わず勉強せず数十行あっちこっちに書くほうが手軽だと思いがちだよねぇ。

505:デフォルトの名無しさん
04/10/10 13:31:12
>>501
貧乏人は自分で作るんですよ。多分。

506:デフォルトの名無しさん
04/10/10 13:32:18
スケールアウト、負荷分散いらないんじゃそもそもEJB使ってねえぞ。
これらの機能提供しないのに，EJBの代替物と歌われてもねぇ、、、

507:デフォルトの名無しさん
04/10/10 13:33:55
>>505
作っているものによると思うけどね。
一体どういうものを想定している？

HTML文章返すだけのウェブサーバとネットワークゲームのサーバではそりゃ負荷分散の手法は違ってくる

508:デフォルトの名無しさん
04/10/10 13:40:01
基本的に業務システム以外は対象外だからねぇ。

509:デフォルトの名無しさん
04/10/10 13:40:48
というか、ネットワークゲームのサーバーでEJBがどうのこうのいうほうが間違ってる。

510:デフォルトの名無しさん
04/10/10 14:26:38
>>509
そこはそれ、アプリ層のインプリだけ構造を統一するためにEJBの
スタイルを借りて、サーバー部分は最適化したものを自作、デスよ。

…ほんまかいな。

511:デフォルトの名無しさん
04/10/10 14:38:02
ネ申？

512:デフォルトの名無しさん
04/10/10 14:40:51
自ｲ乍ﾈ申

513:デフォルトの名無しさん
04/10/10 14:48:56
どの層で分散がいるかなんて、これはアプリケーション毎に違うでしょ？
どでかいコールセンターで検索したい人が多いなら単にデータベースを大量に水平に並べればよい。
核爆発シミュレーション計算の分散も基本的にはコンピュータ並べるが、自作率は後者のほうが多くなるだろうな。

514:デフォルトの名無しさん
04/10/10 15:03:27
>506
EJBの代替物とは謳ってないんじゃない？
J2EEの機能を使いやすくする、でしょ。

J2EE=EJBだと思ってるなら間違い。
ついでに言うとまだ発展途上なのに「全部無いなら使わん」とかいうならご自由に。

使いたいとこ、使えるとこだけ使えばいいんだ。
あとは自作なり他製品と組み合わせるなり。

515:デフォルトの名無しさん
04/10/10 15:06:12
語尾に「なり」をつけるやつは嫌いだ。

516:デフォルトの名無しさん
04/10/10 15:07:29
>>513
とりあえず対象となってない分野をもってきて、使えないとかわめくのって、悲しいね。

517:デフォルトの名無しさん
04/10/10 15:13:06
>>506
いつからEJBの主目的が負荷分散になったんだ？

518:デフォルトの名無しさん
04/10/10 15:14:39
EJBの代替物にもなってないしねぇ。

519:デフォルトの名無しさん
04/10/10 15:16:13
いや、当初から主要な目的の一つではあったが…。
負荷分散しないのにEJB使っても今ひとつ甘みが無い。

520:デフォルトの名無しさん
04/10/10 15:16:25
>>516
クラスタリング・負荷分散に共通して使える対象なんてありえないってことを示す例

521:デフォルトの名無しさん
04/10/10 15:18:24
業務システムに絞れば、共通して使えるしくみはあるんだけども。
で、とりあえずS2が話題にしてるのは業務システムなんだけども。

522:デフォルトの名無しさん
04/10/10 15:20:57
S2に限らずDIな連中が言ってるのは
EJBを使うのは大袈裟なシステムが
世の中には多いんだから別の手を
使おうぜってことでしょ。EJBが必要な
人はそっちを選べばいい。

523:デフォルトの名無しさん
04/10/10 15:21:36
まずは軽快なJavaを読めということでFAだな

524:デフォルトの名無しさん
04/10/10 21:28:23
それは負荷分散をしないって手？

525:デフォルトの名無しさん
04/10/10 21:35:31
負荷分散なんて、DBやアプリケーションサーバーにまかせればいいから、プログラムでは考えなくていい。
いくつかの注意点はあるけども。

526:デフォルトの名無しさん
04/10/10 22:39:39
APサーバに任せるメジャーな手段が、EJ(r

527:デフォルトの名無しさん
04/10/10 22:58:32
つか、なんかどーでもよいことに話がいってない？
負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。
（てか、んなことまでサポートしだしたらLightweightなコンテナじゃなくなるじゃん）

もう少しS2自体の話があるとうれしいのだけど。

528:デフォルトの名無しさん
04/10/10 23:11:40
>>520

フレームワーク外の作りこみ一切禁止なんて縛りがあるわけでもないのに、
なぜそこで完璧を目指す必要があるのか理解できない。
パレート原則で言う8割の側を押さえるだけで十分では?

529:デフォルトの名無しさん
04/10/10 23:23:01
しってる難しそうな言葉をならべて賢くなった気になる遊びですた。

530:デフォルトの名無しさん
04/10/10 23:53:24
>>529
理解できない会話に無理に加わる必要はないよ、坊や。

531:デフォルトの名無しさん
04/10/10 23:56:29
2chだな～

532:デフォルトの名無しさん
04/10/11 01:57:15
>>527
> 負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。
だってDIコンテナの作者らがEJBｲﾗﾈって言ってんだもん。

次ページ