トップページ⇒tech
1001コメント376KB

国産DIコンテナSeasarとくーす その３

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさんNGNG
一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。

あと、開発プロセス「くーす」の話題もこちらでどうぞ。


本家 seasar.org
http://www.seasar.org/

Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/

ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/


前スレ
その１　http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その２　http://pc5.2ch.net/test/read.cgi/tech/1098885253/


関連スレ(なのか?)

Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
0810デフォルトの名無しさん2005/04/20(水) 23:45:51
>>807
Strutsは単にフォームへの入力をBeanに格納してくれるただのライブラリだ。
0811デフォルトの名無しさん2005/04/20(水) 23:52:58
いくらRubyがよくってもまだまだ採用しやすい状況じゃないんだよね。
5年かもっと前のJavaみたいなもんで、ユーザとか元請けのSIerから
止められるのが普通じゃない？ ちっちゃいところはいいかもしれんけど。
Rubyできるやつサクッと集められるとも思えないしね。
だから、ここでRubyが最適とかいわれても逃避にしか見えない。
Javaでどうするか、DIでどうにかなるのか、って所でスゲーやつの
話が聞きたいです。
0812デフォルトの名無しさん2005/04/20(水) 23:57:13
>>809
いや、大抵は>>803みたいに最後だけ見て「こりゃだめだ」って切り捨てられる罠。

そろそろ筆置きます。
長文連発すまなかった。＞スレの人々
あと、S2から凄く離れてしまってすまん。
長々付き合いありがとう。>>807
0813デフォルトの名無しさん2005/04/21(木) 01:35:17
>>788
>>787が1行目で言いたいのは、
メジャーなリリースと、マイナーなバージョンアップを分けてほしいということかと。
08147872005/04/21(木) 01:51:04
>>813
いや、S2StrutsとかS2JSFとか、全部含んでSeasar2.x.xとして出して欲しいってことです。
S2JSFのこのバージョンはSeasar2.1.8じゃないと動きませんよ、とか、でもS2XXXはこのバージョンでは動きませんよとか、わけわからん。
0815デフォルトの名無しさん2005/04/21(木) 10:33:20
XMLファイルで生成物を変更できる小洒落たファクトリーとしてしか理解できてない
んだけど、十分に単純で便利だと思うんだが・・・・・・
なんでここでは否定的な意見の方が多いんだろう？
0816デフォルトの名無しさん2005/04/21(木) 10:41:59
簡便なものが実用可能となると決まって反発がある。
そんな感じじゃないですか。

eclipseからJava始めた人はクラスパスとか
判ってなくてけしからん、とか。
俺は知らなくてもできるんならそれでいいし
トラブルになったらその時に調べて
覚えりゃいいと思うんだがなあ。
0817デフォルトの名無しさん2005/04/21(木) 10:53:27
>>815
この理解で概ね合っていると思っていいよな？駄目だったら頭いい人突っ込んでくれ。
AbstractFactoryにしたくなるような生成部分を統一的な方法で提供しているって
理解なんだけど。
0818デフォルトの名無しさん2005/04/21(木) 11:11:31
>>815
それならSpringの方が日本語の資料も多くて便利
0819デフォルトの名無しさん2005/04/21(木) 11:22:28
>>815
ここで小難しいこと言ってSeasarだめ論(もっと言うとJavaだめ論)を展開してる人って、
案外そういう簡単なことが分からないのかもね。
難しく考えすぎと言うか。

>>818
それは好みの問題でしょう。
0820デフォルトの名無しさん2005/04/21(木) 11:34:14
>>819
Seasarの説明に、次世代どうのこうのとか小難しく書いてあるから。
0821デフォルトの名無しさん2005/04/21(木) 11:45:14
>>814
S2とS2Daoと、あと戦略商品としてS2JSFをバンドルしてくれればいい。
個人的にはS2Strutsも。
0822デフォルトの名無しさん2005/04/21(木) 11:59:00
koichikさんﾚｽｱﾘｶﾞ㌧
0823デフォルトの名無しさん2005/04/21(木) 12:09:22
>>807
> Seasar使うくらいならPure Servletのほうがいいよ。
> シンプルにやりゃいい。

シンプルっていうよりサンプルしか作ったことないとか？
まともに開発したことあるやつとは思えない。

> バックエンドとの分離も簡単シンプル、台数並べれば並べるほど比例して処理を分散する
> みたいな仕組みも作れる。そのプログラミングも贅肉なしのライブラリが使えるし。

後ろが分散できたってしょうがないだろ。なんか素人くさい。学生？
0824デフォルトの名無しさん2005/04/21(木) 12:13:42
>>821
標準セットパッケージみたいな感じだよね。
これ一個でとりあえず美味しい汁を吸えますみたいな。
0825デフォルトの名無しさん2005/04/21(木) 12:14:32
>>823
まぁまぁ、そう反応しなさんな。
見てる切り口が多分全然違うのだよ。
0826デフォルトの名無しさん2005/04/21(木) 12:26:10
>>823
Strutsすら必要ないなら、Seasarも使わずServletに処理ベタ書きの方がいいってことじゃない？
仕事にはいろんな規模のものがあるんだから、それはそれでいいかと。
0827デフォルトの名無しさん2005/04/21(木) 12:27:54
>>824
S2JSFがSeasarのコンテナ機能を使わずUtilだけ使ってるんだったら、UtilをわけてS2+S2DAO+Util/S2JSF+Utilというふたつのパッケージでもいい。
0828デフォルトの名無しさん2005/04/21(木) 12:37:09
>>827
普通にjsf.diconとかあるけど
0829デフォルトの名無しさん2005/04/21(木) 15:57:26
>>826
もちろんそれはそれで良いと思う。
けど、だからつって物知り顔で「誰にとってもフレームワークひいてはS2イラネ」って言うのはどうかと思う。
あんだけ自信満々で言われちゃうと、漏れみたいなお馬鹿チンは「本当にいらないのかな…」って不安になっちまう。
自分は今有効に使えてるのにね。
0830デフォルトの名無しさん2005/04/21(木) 16:23:42
>>829
残念だけど、その取捨選択は君がするしか無いと思うよ。
人の言っていることを盲目的に受け入れるべきなのかそうでないのかって
ことだから。ここの人は自分が思うことを好き勝手に書いているだけだし。
>>790->>807みたいにちゃんと突っ込んだ話をしないとその根拠が
明白にならないからなかなか判断しようが無いのだけれど。

で、自分は彼の話がごく一部しか捉えていないようだと判断した。

＞自分は今有効に使えてるのにね。
これを根拠に「自分には必要だ」でも良いんじゃない？
0831デフォルトの名無しさん2005/04/21(木) 20:39:58
>>819
日本語資料の多寡は「好みの問題」ではありません。
0832デフォルトの名無しさん2005/04/21(木) 21:57:18
Tapestryが好みでしか使えないように、Seasar2も好みでしか使えないと。
0833デフォルトの名無しさん2005/04/21(木) 22:53:58
またTapestryが何者だか訳分からんのだよなｗ
JAVAはフレームワーク多すぎ！て言うか、なんでもかんでもフレームワーク
って呼びすぎ！
俺のこれまでの知識では、「フレームワーク＝湯の張られた鍋」と理解してた。
具材を入れていくと料理になるという、そんなイメージ？
でも、JAVAでは制御の反転が絡むと全部フレームワークって呼びやがる。
Seasarでどんな料理が出来上がるのか、10日も探し回っちまったじゃねぇ～か！
当然、それだけでは料理になんかなるわけねぇ～！そもそも、鍋ですらねぇ～！
どっちかっつぅ～と、やかん？とにかく、俺の馬鹿＿|￣|○|||
0834デフォルトの名無しさん2005/04/21(木) 22:57:07
Seasarってフレームワークだっけ？

最初からIoCコンテナ(DIコンテナ)としか言ってないような。やかんどころかコンロですな。
0835デフォルトの名無しさん2005/04/21(木) 23:04:07
>>833
コールバックを含むライブラリのことをフレームワークと呼ぶのだよ。
0836デフォルトの名無しさん2005/04/21(木) 23:04:50
>>834
分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は
ある。て言うか、変な人ほどフレｄｊさｋｌｊｆｓぢｊｆさいｊふぉいｊ

やかんの心は、冷たい液体から温かい液体を生成するファクトリー
0837デフォルトの名無しさん2005/04/22(金) 00:11:45
>>836
> >>834
> 分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は

JARの名前がs2-framework～である件について
0838デフォルトの名無しさん2005/04/22(金) 00:24:17
Apache AvalonがFrameworkを名乗るからには、SeasarだってFrameworkって名乗ったっていいだろうなあ。

Avalonは(Jamesみたいな）サーバアプリケーションを作成するためのフレームワークと銘打ってるけどね。
0839デフォルトの名無しさん2005/04/22(金) 00:39:32
>>838
Seasarの場合は、S2Daoとか周辺を含まずにフレームワークなわけで。
0840デフォルトの名無しさん2005/04/22(金) 00:49:59
>>839
Avalon Frameworkだって周辺も何も含まずにフレームワークを名乗っていた。
あれはコンテナとコンポーネントのコントラクトを規定しただけのライブラリ。
Avalon Excaliburがコンテナの実装、Avalon Phenixになるとサーバ
アプリケーション用のフレームワークという位置づけになっていたかと。
Marlinはよーわからんがそうやって発散してお亡くなりに…
0841デフォルトの名無しさん2005/04/22(金) 01:18:27
まぁ、分類は学問的なこと考える人たちがすれば良い訳で。
分類の根拠がなんなのか位は抑えておいてもいいだろうけどな。
0842デフォルトの名無しさん2005/04/22(金) 10:52:46
Javaでは>>835の定義だな。
0843デフォルトの名無しさん2005/04/22(金) 10:53:49
テンプレートメソッドなクラスがあれば、フレームワークなのだよ。
0844デフォルトの名無しさん2005/04/22(金) 21:10:01
とゆーか生Servletだってフレームワークだし
0845デフォルトの名無しさん2005/04/22(金) 21:57:18
DIコンテナって、いろんな実装があるけど・・・
俺も学習用につくってみてもいいか？
0846デフォルトの名無しさん2005/04/22(金) 23:45:49
>>843
それは文字通りのフレームワークだと思う。

ファンクタを要求する単体のオブジェクトはどうなんだろう？
IoCを伴ってはいるけど、これをフレームワークと呼ぶのに
は激しく抵抗を感じる。

>>845
いいんじゃない？
DIコンテナという言葉こそ出てこないけど、JAVAの格言に
は、抽象ファクトリーパターンと動的クラスローディングの
組み合わせ例として、iniファイルを利用したDIコンテナが紹
介されてる。
0847デフォルトの名無しさん2005/04/23(土) 02:17:41
>>845
いいよ。
AOPまで実装すれば、とりあえずSeasarの対抗馬としてプロモーションできるし。
ドキュメントとメディアの取り込みさえできれば、すぐ広められる。
ただし、そういうプロダクトを運営するのには、結構手間がかかるし、覚悟がいる。
0848デフォルトの名無しさん2005/04/23(土) 02:32:29
>>847
SeasarやSpringと張り合おうなんて気は毛頭ないから安心してくれ。
あくまで学習用だからきれいでシンプルな実装をしたい。
0849デフォルトの名無しさん2005/04/23(土) 10:43:19
>>848
俺はそういう取り組みの繰り返しが将来の技術力を養うと思う。頑張れ。
0850デフォルトの名無しさん2005/04/23(土) 11:24:16
>>848
そしたら、機能的にはPicoContainerとかをまず見てみるといいかも。
0851デフォルトの名無しさん2005/04/23(土) 11:42:02
>>849
おいらはいい加減おっさんだが35歳で限界を迎えないように精進するよ。ありがとね。

>>850
Spring、Seasar、PicoContainerあたりの実装は確認済み。
PicoContainerのシンプルさは好きだね。

で、CgLibとjavassistの比較してるサイトとかしらん？
0852デフォルトの名無しさん2005/04/23(土) 22:31:40
>>851
>で、CgLibとjavassistの比較してるサイトとかしらん？
ここらへんってちょっと前にSeasarでも話題になってたし、はてなでもいって探せば
参考になるサイトとか出てくるんじゃねー
0853デフォルトの名無しさん2005/04/24(日) 01:43:13
>>817

AbstractFactoryが必要な部分ってシステムのコアに相当する部分で、
ここは自由にプログラミングできてしかるべきところを、
言語の非標準機能を使ってまで、統一的にする意味あんのかってあたりが微妙で、
テストしやすいとかいってるけど、これも結構あやしいと思う。
要するに、モックオブジェクトを返したいってことなんだろうけど、
冷静に考えて、それを作りたいシーンって、ホントにシステムのコアに相当する部分で、
ごく一部であって、そこをフレームワークにまかせてどうにかなるってことも、
無い気がする。有効なシーンがあれば教えてほしい。
0854デフォルトの名無しさん2005/04/24(日) 02:39:08
>>853
もうフレームワークって呼ぶな。話が無駄に混乱する。

有効なシーンも何も、幹と枝葉の相関を切りたいという要求は
普通にと言うより普遍的にあるはずだが・・・・・・
0855デフォルトの名無しさん2005/04/24(日) 02:57:19
>>854
切りたい欲求はそんなに無い、あったとしても、
そこはそのアプリケーションに合った適切な切り方をしたほうが
DIコンテナ機構を使うよりいいってこと思うんだけど
0856デフォルトの名無しさん2005/04/24(日) 21:42:58
>>855
> そこはそのアプリケーションに合った適切な切り方をしたほうが

「アプリケーションに合った」部分をDIコンテナは侵食しないぞ。
あなたの設計だと、Factory部分のコードがアプリケーションによって変わってくるのか？
かなりひどい設計だと想像するけど。
0857デフォルトの名無しさん2005/04/24(日) 22:57:32
俺はもう説明を諦めたんだが・・・・・・

>>856
どう言っても無駄だと思うぞ。
変な話だが、円滑なコミュニケーションにデザパタがどれほど大き
く寄与してるか実感した。

JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
からコンパイルへの依存を排除できる点」だよ。
で、説明は終わりなんだよな。
多段に積み重なった知識の最上段のみを対象に会話を進めていく
って行為は、モードの違う相手とはチャンネルが合わないんだなとｗ
0858デフォルトの名無しさん2005/04/24(日) 23:44:32
>>857
> JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
> からコンパイルへの依存を排除できる点」だよ。
> で、説明は終わりなんだよな。

使ってるやつはそれで説明が終わりと思ってて、使ってないやつにとってはそれでは説明になってないと思う。
0859デフォルトの名無しさん2005/04/25(月) 00:10:03
DIはパターンとしては優れてると思うんだが、
SeasarにしてもSpringにしても使うのちとめどい・・・
Picoのほうが個人的には好きなのだが、それほど使われてない模様

SeasarにコアのDI以外にも便利な機能って何が入ってるのさ
S2Strutsはそれほど便利でなかったし、
JDBC連携もDbUtilsとかで代用できんの？

ともかくXMLの設定とかめどい
0860デフォルトの名無しさん2005/04/25(月) 02:07:25
AOPのこともたまには思い出してやってください…
0861デフォルトの名無しさん2005/04/25(月) 02:24:32
>>856
>Factory部分のコードがアプリケーションによって変わってくるのか？

ソフトウェアの核になる部分って、やっぱり
キャッシュを解放するタイミングとか、ログの取り方、バックアップの取り方、パフォーマンスの計測とか
いろいろやることがあって、変わるに決まってると思うのだが
0862デフォルトの名無しさん2005/04/25(月) 02:56:03
もう、なんつーかさ、スルーしとけばいいのか？
0863デフォルトの名無しさん2005/04/25(月) 14:14:53
>>859
XMLがめんどいというやつは、Springをちょっと使って、
Seasarを使ってないやつに多い｡

Picoがいいというやつは、最近あまりみたことないが、
PicoよりはSeasarが簡単だろう｡
同じようにコンストラクタによるAutowireができて、
classを登録するだけですむんだから｡

APIをじかにたたく分には、SeasarもPicoもあまりかわらない。
0864デフォルトの名無しさん2005/04/25(月) 18:17:21
>>861
ファクトリーは生成のパターンだから構造や制御とは無関係だよ。
0865デフォルトの名無しさん2005/04/25(月) 19:03:38
>>862
頭がツルツルなのがきたら、スルーでおっけ
0866デフォルトの名無しさん2005/04/25(月) 19:08:27
某所のコンサルで、

　　factory method数≒全クラス数

　　ただしfactory methodは大抵singletonを返す

ってのが居た。あの類だろｗ
0867デフォルトの名無しさん2005/04/26(火) 00:15:33
>>864
フツーにnewするのがナニが不満なのか。
なんでもないところにAbstractFactory用いる意味は無い。

もしAbstractFactoryを導入する価値のある個所があるのだとすれば、
それはシステムのコアであるから、どっちにしろ、ここは自由にプログラミング
できないと無意味である。
0868デフォルトの名無しさん2005/04/26(火) 00:21:47
つうか、じゃあ今のEJB使ってロジック層作ってみれば、なんでDIコンテナが出てきたか
なんて、１日の試用でわかるんじゃねえの？ EJB使った上で、DIなんて無意味非効率めんどくせえ、
とかいうやつがいたら、どっかいかれてるとしか思えん。
0869デフォルトの名無しさん2005/04/26(火) 00:58:12
ソロプログラマでRAD使いの臭いがプンプンするな。
て言うか、十中八九こいつVBプログラマだｗ
08708662005/04/26(火) 01:35:32
>>866に書いたのは、>>861や>>869みたいな頓珍漢の事ね。
0871デフォルトの名無しさん2005/04/26(火) 01:54:49
>>868
あれだね。
EJBを必要と思わなかったら、まったく意味のない比較だね。
めちゃくちゃめんどいEJBがめんどいDIになっただけということ？
0872デフォルトの名無しさん2005/04/26(火) 02:44:31
>>871
そりゃそうだろ。DIコンテナが生まれてきた経緯を考えると、EJBへのアンチテーゼ
そのものなんだし。解決しようとしてる土俵で比較するのが筋じゃないか？

めちゃめちゃしんどいEJBが楽なDIコンテナに変わったってことだろ。
EJBはめんどいけど、コンテナのインスタンス制御機能（つまりファクトリとしての機能）や、
コンテナ制御のトランザクションなんて機能自体は必要なんだよ。そのために苦労して
EJB使うわけで。

DIコンテナはその両方を簡単に解決するじゃん。DIコンテナよりも簡単にEJBの機能を
提供してるものがあるんだったら、おれはすぐにでもそっちに乗り換えるよ。
0873デフォルトの名無しさん2005/04/26(火) 03:30:16
つうことはEJB3がでりゃSeasarは必要ないってことだね。
0874デフォルトの名無しさん2005/04/26(火) 04:05:05
そうか？
0875デフォルトの名無しさん2005/04/26(火) 04:14:52
DIコンテナ機能あるし、簡単に使えるツールも出るだろうし。
0876デフォルトの名無しさん2005/04/26(火) 05:00:17
XMLで定義する意味っていえば、
XMLはツールとの相性のよさってのがあって、
人間にも読めて機械にも読めるフォーマットとして意味があると思うんだけど、
なんつーか、DIコンテナなんつーものは、
本来はプログラミング言語が兼ね備えているべきレベルでの単純すぎるオブジェクト生成
にしか使えなくて、フツーにnew するのと変わらん。そんなのに意味あるか。

むしろそういうことなら、Eclipseのプラグインアーキテクチャにおけるxmlによる、
読み込むクラスの定義のほうが、価値があると思う。
0877デフォルトの名無しさん2005/04/26(火) 05:46:20
>>876
XMLでの定義がいやなら、アノテーション。
0878デフォルトの名無しさん2005/04/26(火) 06:58:17
S2GroovyBuilderもあるぞ
0879デフォルトの名無しさん2005/04/26(火) 09:33:51
>>876
＞本来はプログラミング言語が兼ね備えているべきレベルでの単純すぎるオブジェクト生成
＞にしか使えなくて、フツーにnew するのと変わらん。そんなのに意味あるか。
このあたりが何を言いたいのかもう少し知りたい。
それと、どんなアプリを作る人なの？
この辺の違いがわかると話が噛み合ってくると思う。
0880デフォルトの名無しさん2005/04/26(火) 18:29:17
>>873
正直、EJB3は全く追いきれてないんだが、DIコンテナ＋AOPという小さな
機能部品としてのSeasarには需要が残り続けると思う。
0881デフォルトの名無しさん2005/04/26(火) 18:41:16
>Eclipseのプラグインアーキテクチャにおけるxmlによる
>読み込むクラスの定義のほうが、価値があると思う。
いや、それがDI(Dependency Injection = 依存性の挿入)でしょ？
コンパイルへの依存性を排除できるって、そういう事だと思ワン？

「価値があると思う」って、思いっきり認めちゃってるみたいだけど・・・・・・
えと、どういう事？DIコンテナは認めるけど、Seasarは駄目って話？
て言うか、スレが進むうちに段々DIコンテナの利点が分かってき
たんじゃないか？別に無理繰り否定する必要はないんだぞ？
0882デフォルトの名無しさん2005/04/26(火) 19:36:20
>>881
それを一般アプリケーションに広げる価値はないといってるのでは？
0883デフォルトの名無しさん2005/04/26(火) 20:19:59
EJBもめんどいと思うがDIも十分めんどい
もっと楽な方法が出てきそう
0884デフォルトの名無しさん2005/04/26(火) 20:22:20
>>881
DIをするための方法として、一般的にDIコンテナと呼ばれている物の
方法は良くないと言いたいのかねぇ。

あ、違うよ。きっと彼はプラグインがDIだってわかってなかったんだ。

むしろそういうことなら、こんな不毛な議論なんかやめて
別の話したほうが、価値があると思う。
0885デフォルトの名無しさん2005/04/26(火) 23:39:22
>>867 >>876

「AとBを結びつけるときに、その結びつきがAやBの中に直接埋
め込まれているのではなく、Cがその仲介をしてあげてくれると
AとBの実装がお互いに依存しなくて嬉しい」

っていうのがDIのありがたみだと思うのだけれど、これ自体には
異論はないのかな。
それともこれ自体に異論があるのか？

で、DIコンテナは上記のCにあたるところを一括して面倒みてく
れるのだけれど、その方法として「AやBの生成を請け負う」とい
うやりかたをしているため、その副作用として「生成したものを一
定の方法で改ざんできる（＝AOPを適用できる）」というメリットが
出てきていて、そこが個別にAbstractFactoryを用いるのとは決
定的に異なるのかなと。
0886デフォルトの名無しさん2005/04/27(水) 01:09:19
>>885
あらたにCを導入して依存関係を複雑にしてるだけにも読めるが。
ともあれDI使ったところでAとBは依存するし、使わなくても実装が依存しないようにできるし。
0887デフォルトの名無しさん2005/04/27(水) 01:17:55
アンチDIさんにはそろそろDIレスな素敵な実装キボンヌ
0888デフォルトの名無しさん2005/04/27(水) 01:58:33
具体的な提案もないし、いちゃもんつけてるだけの厨にしかみえん
つーかスレ違いだ。DIスレでやれ
0889デフォルトの名無しさん2005/04/27(水) 02:28:03
>>886
インターフェースに対しても同じ様な反応があるな。
AクラスとBクラスがそれぞれCインターフェースに依存してる。依存関係を複雑にしてる
だけなのではないか？と・・・・・・
「インターフェースに対してプログラミングする事でクラス間の依存性を排除できる」とい
う教科書的な説明は、間を省略し過ぎてて実は説明になってない。
インターフェースに対してプログラミングする事で直接的に排除できるのは特定のクラス
型に対する依存性で、これを排除しようとするモチベーションはJAVAが多重継承をサポ
ートしていないという点から湧いてる。
例えば、スレッドの実現にそのサブクラスである事を要求されたら？コールバックを実現
するのに特定のクラス型を要求されたら？インターフェイスを用いてクラス間の依存性を
排除するとはこういう事を指してる。

DIについても同じ視点から考察してみてほしい。教科書的な説明よりも、もう少し詳細な
視点で、DIが本当に排除してる依存性とは何なのかと、俺なりの視点については明日の
晩にでも書くつもりだけど、先ずは自分なりに考えてみてほしい。
0890デフォルトの名無しさん2005/04/27(水) 05:05:20
>>881
コンパイル依存排除が目的っていうなら、それは無意味だ
拡張するためのアプリケーションで、拡張方法が明確に定義されているときのみ、
xmlでインスタンス化する対象を定義する意味があるのであって、
一般的なアプリケーションでわざわざxmlを書いてインスタンス化するもの
決める必要な無い。

>>889
Javaにインターフェースがある理由って、ハッキリ言わせてもらうと、型が合ってないと
コンパイルエラーで実行前に知らせてくれるっていう、それ以外にありえない。

インターフェース無くして、実行時にメソッドの有り無しのみでポリモーフィズム
やっても、問題は無いでしょ。
デメリットはコンパイルエラーが無くなってちょっとエラー発見が遅れることなのであって。
0891デフォルトの名無しさん2005/04/27(水) 08:01:16
DIの議論はDIスレへ
http://pc8.2ch.net/test/read.cgi/tech/1099827125/
0892デフォルトの名無しさん2005/04/27(水) 09:22:49
DIが排除する依存は、オブジェクト間の依存であってクラス間の依存は排除されない
0893デフォルトの名無しさん2005/04/27(水) 11:02:17
Seasar無関係の話(例: DI, Interface, 初心者質問, その他信念表明 等)は、
それぞれ別スレでやるべきですね。
0894デフォルトの名無しさん2005/04/27(水) 11:10:36
DIはSeasarとは無関係です。
InterfaceはSeasarとは無関係です。
初心者はSeasarとは無関係です。
さすが、閉鎖的なことで定評のあるSeasarです。
0895デフォルトの名無しさん2005/04/27(水) 12:17:08
スレ違いと誘導するよりも、進んでネタを振りましょうｗ
0896デフォルトの名無しさん2005/04/27(水) 13:04:42
Seasarに関係したい奴が絡んでるだけか
0897デフォルトの名無しさん2005/04/27(水) 13:53:59
郵政民営化とSeasarはもちろん関係があるし、意外と知られていないが後藤真希の胸がGカップまで巨大化した件は依存性の注入という点からみると非常に関係が深い。
0898デフォルトの名無しさん2005/04/27(水) 14:53:25
(； ・`д・´)　!? (`・д´・ (`・д´・ ；) な、なんだってー!?
0899デフォルトの名無しさん2005/04/27(水) 15:30:51
注入！どひー
0900デフォルトの名無しさん2005/04/27(水) 20:37:36
これだけは言わせてくれ
>>896
そういう無意味な煽りが、余計にウンチを産んでるのをいい加減分かれよ。それともおまいもアンチSeasar/DI？

で、>>890 >>インターフェースがある理由
理由はそうであれ、そこを原点にして様々なメリットが生まれてる。

あと、遅れるのは「ちょっと」どころではないぞ。規模が大きくなればなるほどね。
テスト段階でも発見できなくて、稼動後に発見なんて可能性も大いにある。これは大問題だ。
0901デフォルトの名無しさん2005/04/27(水) 22:25:54
結論：EJB >>>>>>>>>>>> DI
0902デフォルトの名無しさん2005/04/27(水) 22:40:38
動的型付けができないからインターフェースがあるですよ
EJB3は素敵ですよ
Seasar2はS2Daoが素敵ですがS2JSFはいうほどではありません。
0903デフォルトの名無しさん2005/04/27(水) 22:41:46
インターフェイスなどどうでもいい。
ttp://220.111.244.199/otakara/idol/050427a1.jpg
0904デフォルトの名無しさん2005/04/27(水) 22:43:49
-----------------------------------
　　チンパンジーのアイちゃんが
　　　　　　　　　書き込んでいます（はぁーと
　　　　　　　　　　　　　　　　　　　(霊長類研)
-----------------------------------
0905デフォルトの名無しさん2005/04/28(木) 02:03:16
しかし、ジャバワールドのインタビューの写真、特集1日目のブタと3日目のクマに入れ替えても誰もきづくまい。
0906デフォルトの名無しさん2005/05/02(月) 22:13:23
http://www.atmarkit.co.jp/fjava/rensai3/springdi01/springdi01_1.html

非常に分かり易くDIについて書かれてる。
これくらい噛み砕いてあると、非JAVA脳な人にはすんなり入ると思う。
0907デフォルトの名無しさん2005/05/03(火) 07:53:38
おれは>>885の説明がわかりやすかった。ありがとう>>885
0908デフォルトの名無しさん2005/05/03(火) 14:27:05
@ITってネタをベタにするメディアだからなぁ

局所化してデバッグしやすいとかいって、
DIのメリットとオブジェクト指向プログラミングのメリットを
すり替えしてんじゃん。
こんなネタに騙される奴なんか顔も見たくないよ。
0909デフォルトの名無しさん2005/05/05(木) 22:48:43
>908
>局所化してデバッグしやすいとかいって、
>DIのメリットとオブジェクト指向プログラミングのメリットを
>すり替えしてんじゃん。

禿同。
最近そこんとこを勘違いしてる人が多いよね。

まあ、勘違いであろうがなかろうが、テスタビリティの高い(=高凝集で疎結合な)プログラムが作られることは大歓迎。
レス数が900を超えています。1000を超えると表示できなくなるよ。