Dependncy Injectionを語るスレ
1 ：デフォルトの名無しさん：
依存性注入ということらしい。IoCともいわれる。
最近注目を集めているがその是非を論じてみよう。
参考
ttp://cvs.picocontainer.codehaus.org/viewrep/~raw,r=1.1/picocontainer/site/presentations/JavaPolis2003_ja.ppt
ttp://www.kakutani.com/trans/fowler/injection.html
最近注目を集めているがその是非を論じてみよう。
参考
ttp://cvs.picocontainer.codehaus.org/viewrep/~raw,r=1.1/picocontainer/site/presentations/JavaPolis2003_ja.ppt
ttp://www.kakutani.com/trans/fowler/injection.html
|
|
|
2 ：デフォルトの名無しさん：04/11/07 20:40:01
Java製DIコンテナ
Spring Framework
ttp://www.springframework.org/
PicoContainer
ttp://www.picocontainer.org/
HiveMind
ttp://jakarta.apache.org/hivemind/index.html
Seasar2
ttp://www.seasar.org/
Spring Framework
ttp://www.springframework.org/
PicoContainer
ttp://www.picocontainer.org/
HiveMind
ttp://jakarta.apache.org/hivemind/index.html
Seasar2
ttp://www.seasar.org/
3 ：デフォルトの名無しさん：04/11/07 20:46:16
RubyでDIという記事
ttp://jp.rubyist.net/magazine/?0002-RLR
上記の記事に出てないRuby製DIコンテナ
ttp://homepage1.nifty.com/ryugate/akabeko/
ttp://jp.rubyist.net/magazine/?0002-RLR
上記の記事に出てないRuby製DIコンテナ
ttp://homepage1.nifty.com/ryugate/akabeko/
4 ：デフォルトの名無しさん：04/11/07 20:48:53
関連ありそうなスレ
Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
国産DIコンテナSeaserとくーす その2
http://pc5.2ch.net/test/read.cgi/tech/1098885253/
Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
国産DIコンテナSeaserとくーす その2
http://pc5.2ch.net/test/read.cgi/tech/1098885253/
5 ：デフォルトの名無しさん：04/11/07 21:03:45
.NET版DIコンテナ
Spring.NET
ttp://www.springframework.net/
Dosanko
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/dosanko/
Kodama
ttp://sourceforge.jp/projects/kodama
Spring.NET
ttp://www.springframework.net/
Dosanko
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/dosanko/
Kodama
ttp://sourceforge.jp/projects/kodama
6 ：デフォルトの名無しさん：04/11/07 21:18:33
補足
PicoContainerにはRuby版と.NET版もあり。
PHP版のDIコンテナを作るというのもどこかで見かけた。
PicoContainerにはRuby版と.NET版もあり。
PHP版のDIコンテナを作るというのもどこかで見かけた。
7 ：デフォルトの名無しさん：04/11/07 22:15:50
結論
EJB3.0で決まり
EJB3.0で決まり
8 ：デフォルトの名無しさん：04/11/07 22:51:16
EJB3.0ってDIコンテナになるの？
9 ：デフォルトの名無しさん：04/11/08 00:24:44
10 ：デフォルトの名無しさん：04/11/08 16:59:38
11 ：デフォルトの名無しさん：04/11/08 17:15:14
Dependency Injection in Ruby
ttp://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc
ttp://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc
12 ：デフォルトの名無しさん：04/11/08 17:16:07
色々とあるもんだなー。
Perlはないのかな？
Perlはないのかな？
13 ：デフォルトの名無しさん：04/11/08 18:51:20
IOC - A lightweight IOC (Inversion of Control) framework
ttp://search.cpan.org/~stevan/IOC-0.08/
ttp://search.cpan.org/~stevan/IOC-0.08/
14 ：デフォルトの名無しさん：04/11/08 19:03:11
おーPerlだ。㌧ｸｽ
スクリプト系でもDIって流行ってきてるんだね。
Javaだけってわけじゃないんだ。
スクリプト系でもDIって流行ってきてるんだね。
Javaだけってわけじゃないんだ。
15 ：デフォルトの名無しさん：04/11/09 05:58:21
で、DIって具体的にどういう的に便利なの？
・小規模...わざわざxmlに定義するよりPOJOでやった方が簡単
・大規模...インスタンスの生成管理したいので大部分では使わない
→ソース追いづらくなるしDI使わないに統一した方がいい
・中規模...ウォーターフォールでインターフェースを決め打ちできる
＆インスタンスが始めから無駄に一個ずつ生成されていてもどうでもいい
程度の規模ならメリットあり
って感じ？あ、こういうのもあるね。
・中規模...設計がわかった気になった厨くんの自己満足に最適
現場の人間のモチベーションは大事だからね
・小規模...わざわざxmlに定義するよりPOJOでやった方が簡単
・大規模...インスタンスの生成管理したいので大部分では使わない
→ソース追いづらくなるしDI使わないに統一した方がいい
・中規模...ウォーターフォールでインターフェースを決め打ちできる
＆インスタンスが始めから無駄に一個ずつ生成されていてもどうでもいい
程度の規模ならメリットあり
って感じ？あ、こういうのもあるね。
・中規模...設計がわかった気になった厨くんの自己満足に最適
現場の人間のモチベーションは大事だからね
16 ：デフォルトの名無しさん：04/11/09 06:05:50
規模にかかわらず、OOPの真のメリットが理解出来ない人達(残念ながら結構いるよね)を
束ねて開発する際に、始めに指針をきちんと提示してあげればソースの綺麗さを
ある一定の水準に保てることかな。
ちゃんとしたOOPとOOPモドキが混じったソースは汚いことこの上ないからね。
全部構造化設計で共通処理をちゃんとサブルーチン化して、あとは
システムが処理する順番通りに記述していった方がはるかにマシ。
前時代的だけど。
束ねて開発する際に、始めに指針をきちんと提示してあげればソースの綺麗さを
ある一定の水準に保てることかな。
ちゃんとしたOOPとOOPモドキが混じったソースは汚いことこの上ないからね。
全部構造化設計で共通処理をちゃんとサブルーチン化して、あとは
システムが処理する順番通りに記述していった方がはるかにマシ。
前時代的だけど。
17 ：デフォルトの名無しさん：04/11/09 10:05:18
15さん>
どんな規模でもユニットテストを厳密にしようと思ったら有効化と。
単体テストの網羅率が低いプログラムを4年もメンテしたら考えが変わりますよ。
どんな規模でもユニットテストを厳密にしようと思ったら有効化と。
単体テストの網羅率が低いプログラムを4年もメンテしたら考えが変わりますよ。
19 ：デフォルトの名無しさん：04/11/09 11:41:20
>>15
> わざわざxmlに定義するよりPOJOでやった方が簡単
DIで使うのはPOJOなんだけど。
あと、わかんないなら、StrutsとHibernate使うときになんか便利とか、その程度で最初はいいと思う。
基本的にはある種のパラダイムシフトだから、やってみないことにはメリットは実感できないよ。
やらないうちは、ファクトリ書くのとどう違うの？って感じだけど。
「DIってどういうときに便利なの？」っていうのは「オブジェクト指向ってどういうときに便利なの？」という問いがばかげてるのと似てる。
> わざわざxmlに定義するよりPOJOでやった方が簡単
DIで使うのはPOJOなんだけど。
あと、わかんないなら、StrutsとHibernate使うときになんか便利とか、その程度で最初はいいと思う。
基本的にはある種のパラダイムシフトだから、やってみないことにはメリットは実感できないよ。
やらないうちは、ファクトリ書くのとどう違うの？って感じだけど。
「DIってどういうときに便利なの？」っていうのは「オブジェクト指向ってどういうときに便利なの？」という問いがばかげてるのと似てる。
20 ：デフォルトの名無しさん：04/11/09 11:46:36
>>18
DI使わないで書いてますので間違ってる所はバンバン指摘してくださいね。
DI使うと単体検査の網羅率が変わるんですか？
どの項目になにを入力したらエラーになる、というのは
結局人が書かないといけないと思うのですが。
太田さんが言われてるのは趣味の延長でやっているような
検査仕様書といえば正常系の画面遷移くらいしか記述しないような
人たちのことを言っていますか？
あえていえば、xmlファイルでクラス名やメソッド名を書き間違えると
実行時クラスキャストエラーになってプログラムが停止してしまうので
最低限一通り正常処理は通しておかないと目も当てられない、
というのはあるかと思いますが、ってこれは極端か。
DI使わないで書いてますので間違ってる所はバンバン指摘してくださいね。
DI使うと単体検査の網羅率が変わるんですか？
どの項目になにを入力したらエラーになる、というのは
結局人が書かないといけないと思うのですが。
太田さんが言われてるのは趣味の延長でやっているような
検査仕様書といえば正常系の画面遷移くらいしか記述しないような
人たちのことを言っていますか？
あえていえば、xmlファイルでクラス名やメソッド名を書き間違えると
実行時クラスキャストエラーになってプログラムが停止してしまうので
最低限一通り正常処理は通しておかないと目も当てられない、
というのはあるかと思いますが、ってこれは極端か。
21 ：デフォルトの名無しさん：04/11/09 11:58:02
> DI使うと単体検査の網羅率が変わるんですか？
> どの項目になにを入力したらエラーになる、というのは
> 結局人が書かないといけないと思うのですが
単体検査をやりやすくなるので、網羅率が間接的に変わるかも。
オブジェクトとオブジェクトを結びつけるためだけのコードも減るので、やっぱり網羅率はあがるかも。
ただし、Javaコードの網羅率があがっても、DI定義の網羅率は低いことが多いので、トータルでは変わってないかも。
DI定義のテストをどう考えるか、というのは問題のひとつだと思う。
> xmlファイルでクラス名やメソッド名を書き間違えると
> 実行時クラスキャストエラーになってプログラムが停止してしまうので
該当クラスがないときは、DI定義の読み込み時でエラーになるコンテナが多いので、クラス名の間違いに関してはあまり問題なさそう。
あと、現実問題として、最初のひとつのオブジェクトを読み込むとあとは芋づる式にインジェクションされたオブジェクトを取得するので、クラスのキャストエラーというのも実は心配するほどもない。
Container.getInstance("name")みたいなことをすることは結構少ない。
ということで、やっぱ極端かと。
テストしろよ、という話でもあるし。
> どの項目になにを入力したらエラーになる、というのは
> 結局人が書かないといけないと思うのですが
単体検査をやりやすくなるので、網羅率が間接的に変わるかも。
オブジェクトとオブジェクトを結びつけるためだけのコードも減るので、やっぱり網羅率はあがるかも。
ただし、Javaコードの網羅率があがっても、DI定義の網羅率は低いことが多いので、トータルでは変わってないかも。
DI定義のテストをどう考えるか、というのは問題のひとつだと思う。
> xmlファイルでクラス名やメソッド名を書き間違えると
> 実行時クラスキャストエラーになってプログラムが停止してしまうので
該当クラスがないときは、DI定義の読み込み時でエラーになるコンテナが多いので、クラス名の間違いに関してはあまり問題なさそう。
あと、現実問題として、最初のひとつのオブジェクトを読み込むとあとは芋づる式にインジェクションされたオブジェクトを取得するので、クラスのキャストエラーというのも実は心配するほどもない。
Container.getInstance("name")みたいなことをすることは結構少ない。
ということで、やっぱ極端かと。
テストしろよ、という話でもあるし。
22 ：デフォルトの名無しさん：04/11/09 11:59:53
>>19
なるほど、言われてみれば確かにポインタを初めて勉強したときも、
ポインタのポインタや関数ポインタの話を聞いたときも、実際に
やってみるまで「なんのためにそんなことをするのか」わからなかった。
TemplateMethodパターンもAbstractProductはともかく、AbstractFactoryクラスまで
抽象化する意味が始めはよくわからなかった。
やってみろというのはその通りだ。でもメリットもわからないうちから
業務には適用できないし(してるアホもいるけどね)、なんか作ると便利なモノないかな。
どうせ時間かけるなら、その時間をOOのスキルアップに使った方が
いいような気がしてDIの勉強に本腰が入らないんだよね。
なるほど、言われてみれば確かにポインタを初めて勉強したときも、
ポインタのポインタや関数ポインタの話を聞いたときも、実際に
やってみるまで「なんのためにそんなことをするのか」わからなかった。
TemplateMethodパターンもAbstractProductはともかく、AbstractFactoryクラスまで
抽象化する意味が始めはよくわからなかった。
やってみろというのはその通りだ。でもメリットもわからないうちから
業務には適用できないし(してるアホもいるけどね)、なんか作ると便利なモノないかな。
どうせ時間かけるなら、その時間をOOのスキルアップに使った方が
いいような気がしてDIの勉強に本腰が入らないんだよね。
23 ：デフォルトの名無しさん：04/11/09 12:35:48
>>22
「OOのスキルアップ」が足りてないなら、そっちやったほうがいいのかもしれないけど、DIの勉強って、はっきりいってすることないから、ちょっと試しに何か使ってみればいい。
勉強っていっても、ほんとDIってsetXxxメソッド用意して<property name="xxx"><value>aaa</value></property>書くだけで、その文法とコンテナの準備が違うだけだし。
で、これ見ても「だから何？」なんだけど、やってみるとその「だから何？」のためにコードをたくさん書かされていたことに気づく。
「OOのスキルアップ」が足りてないなら、そっちやったほうがいいのかもしれないけど、DIの勉強って、はっきりいってすることないから、ちょっと試しに何か使ってみればいい。
勉強っていっても、ほんとDIってsetXxxメソッド用意して<property name="xxx"><value>aaa</value></property>書くだけで、その文法とコンテナの準備が違うだけだし。
で、これ見ても「だから何？」なんだけど、やってみるとその「だから何？」のためにコードをたくさん書かされていたことに気づく。
24 ：デフォルトの名無しさん：04/11/09 12:38:54
コンポーネントの再利用って、DI使わないときには、OOの技術やらデザインパターンの知識と有効活用が必要で、ちょっとキバらないといけないと思うんだけど、DI使うと、システムの一部分がなぜかどこでも使えるようになってたりするから不思議。
スキルアップが足りてると思ったら技術者として終わりだよね・・
26 ：デフォルトの名無しさん：04/11/09 13:14:47
誰も>>1の綴り間違いに気づかない
27 ：デフォルトの名無しさん：04/11/09 13:14:57
技術的な面での知識をつける事は勿論スキルアップだけど
マネジメントの視点から開発効率を考えて
より合理的な方法を探るのも立派な「スキルアップ」だと思うよ。
と自分にも言い聞かせてますけど。
>15の「設計がわかった気になった厨くんの自己満足に最適」
ってのは、ちょっと耳が痛いですなー。
マネジメントの視点から開発効率を考えて
より合理的な方法を探るのも立派な「スキルアップ」だと思うよ。
と自分にも言い聞かせてますけど。
>15の「設計がわかった気になった厨くんの自己満足に最適」
ってのは、ちょっと耳が痛いですなー。
28 ：デフォルトの名無しさん：04/11/09 13:58:53
>22自己レス
TemplateMethodじゃなくてFactoryMethodだね
TemplateMethodじゃなくてFactoryMethodだね
えーとすでに21さんが書かれていますが，
DIによって，依存性を分離すると，
より小さな要素のレベル(サブシステム→クラスの集合→クラス→メソッド)で，
高い網羅率を可能にすることができるということです。
FactoryとかSingletonとかFacadeとかを使いこなしても，
やはりクラスの依存関係が密になってしまって(色々回避するためのパターンはありますが)，
結果的に結合テストでえいやっってことになってしまっているのを
自分が関わった仕事を含めたびたび見てきたということです。
DIによって，依存性を分離すると，
より小さな要素のレベル(サブシステム→クラスの集合→クラス→メソッド)で，
高い網羅率を可能にすることができるということです。
FactoryとかSingletonとかFacadeとかを使いこなしても，
やはりクラスの依存関係が密になってしまって(色々回避するためのパターンはありますが)，
結果的に結合テストでえいやっってことになってしまっているのを
自分が関わった仕事を含めたびたび見てきたということです。
31 ：デフォルトの名無しさん：04/11/09 14:51:49
なんかどんどん色々なものが生まれてくるね。ついてゆけないや。
32 ：デフォルトの名無しさん：04/11/09 14:52:28
順調に伸びてまつね、このスレ。
33 ：デフォルトの名無しさん：04/11/09 15:03:20
>>22
DIってOOのパターンのひとつっぽい感じだと思う。
別に仕事でどうこうとか難しいことを考えなくても
簡単なサンプルをいくつか作るだけでも随分と印象が
変わる。
実は漏れもそうで最初またウザイフレームワークかと
思ったんだけど、結構目からウロコというか新鮮だった。
もちろん別の手間が増えるというのはあるんだけどね。
interfaceをしっかりと考えるとかさ。
ちょっと新しいOOのトレンドとして捉えて触ってみても
損は無いと思うよ。
DIってOOのパターンのひとつっぽい感じだと思う。
別に仕事でどうこうとか難しいことを考えなくても
簡単なサンプルをいくつか作るだけでも随分と印象が
変わる。
実は漏れもそうで最初またウザイフレームワークかと
思ったんだけど、結構目からウロコというか新鮮だった。
もちろん別の手間が増えるというのはあるんだけどね。
interfaceをしっかりと考えるとかさ。
ちょっと新しいOOのトレンドとして捉えて触ってみても
損は無いと思うよ。
34 ：デフォルトの名無しさん：04/11/09 15:40:29
DIって何なの？
DIなんて聞いた事も分からない漏れにも分かるように説明キボンヌ
DIなんて聞いた事も分からない漏れにも分かるように説明キボンヌ
35 ：デフォルトの名無しさん：04/11/09 15:40:53
Do It
36 ：デフォルトの名無しさん：04/11/09 15:42:37
スレタイと違うじゃんよ
37 ：デフォルトの名無しさん：04/11/09 16:12:24
Direct Injection
38 ：デフォルトの名無しさん：04/11/09 16:15:15
スレタイと違うじゃんよ
39 ：デフォルトの名無しさん：04/11/09 16:18:35
ていうか>>1のリンク先は読んだ？
40 ：デフォルトの名無しさん：04/11/09 16:57:17
実際にはDIはAOPと一緒に使って新しいパラダイムという感じになるし、実際DIだけだと単に便利なだけなので、スレタイにAOPを含めなかった1を少し恨む。
41 ：デフォルトの名無しさん：04/11/09 18:11:45
AOPは
ttp://pc5.2ch.net/test/read.cgi/tech/1004962559/
で語ることになってるのかと。
>15
ユニットの抽象化、ブラックボックス化が進むのが利点かと。
大規模開発する時、ここの作業領域が明確になって
分業が進むのが素敵チックに思います。
XMLで必死に定義書きまくるのはどうなんだといわれりゃその通りですが
結合を疎に持ってく方向自体は間違ってないかと。
ttp://pc5.2ch.net/test/read.cgi/tech/1004962559/
で語ることになってるのかと。
>15
ユニットの抽象化、ブラックボックス化が進むのが利点かと。
大規模開発する時、ここの作業領域が明確になって
分業が進むのが素敵チックに思います。
XMLで必死に定義書きまくるのはどうなんだといわれりゃその通りですが
結合を疎に持ってく方向自体は間違ってないかと。
42 ：デフォルトの名無しさん：04/11/09 18:30:01
AOPはAOPだけではどうしようもないし、DI+AOPではじめて両者の本当のメリットが得られると思うんだよね。
43 ：デフォルトの名無しさん：04/11/09 18:39:26
ほならスレタイなぞ気にせず語ってしまえばよいですよ。
44 ：デフォルトの名無しさん：04/11/09 18:55:11
語りにくいけど、そうする。
やっぱり、2chってスレタイと1の文は大事なんだよね。
AOPはDIあってこそだし、DIはAOPのためにあると思う。
AOPとして語られる横断的な関心事って、処理のことがとりあげられるけど、さまざまなオブジェクトで必要になるオブジェクトを横断的な関心事と考えると、DIはそれを織り込む仕組みになる。
やっぱり、2chってスレタイと1の文は大事なんだよね。
AOPはDIあってこそだし、DIはAOPのためにあると思う。
AOPとして語られる横断的な関心事って、処理のことがとりあげられるけど、さまざまなオブジェクトで必要になるオブジェクトを横断的な関心事と考えると、DIはそれを織り込む仕組みになる。
45 ：デフォルトの名無しさん：04/11/09 21:12:15
ＰＯＪＯって何だ？
ただの普通のクラスと何が違うんだ？
ただの普通のクラスと何が違うんだ？
46 ：デフォルトの名無しさん：04/11/09 21:39:02
むしろ、普通のクラス。
なにか特定のインターフェイスの実装やらクラスの継承を義務づけられてないということ。
だから、RMIのリモートオブジェクトとか、EJBとか、StrutsのActionとかActionFormはPOJOじゃない。
なにか特定のインターフェイスの実装やらクラスの継承を義務づけられてないということ。
だから、RMIのリモートオブジェクトとか、EJBとか、StrutsのActionとかActionFormはPOJOじゃない。
47 ：デフォルトの名無しさん：04/11/09 22:47:33
>>30
するってえと太田さんところでは単体検査とは本当にユニット単位で
検査すること(JUnitで出来るようなこと)であって、機能毎にプログラムの
分岐を現実的な範囲内で網羅するような試験ではないって事ですかね。
だとすると私とは前提が違うのでかみ合わないわけですね。
まあもともとDIに興味を持ったからこそいろいろ聞いているわけだけど、
調べていくうちに「なんかなー、いまいち手間に比べてメリットが薄い気がするなー」
というのが正直なところなわけですよ。メリットがあるのはわかるんだけど。
で、みんなにメリットを語ってもらおうと思って質問するんだけど、まだピンと来ない。
EclipseにSpringプラグインをいれたらxmlの定義を書いてるときもコード補完で
型検索とかできるの？
するってえと太田さんところでは単体検査とは本当にユニット単位で
検査すること(JUnitで出来るようなこと)であって、機能毎にプログラムの
分岐を現実的な範囲内で網羅するような試験ではないって事ですかね。
だとすると私とは前提が違うのでかみ合わないわけですね。
まあもともとDIに興味を持ったからこそいろいろ聞いているわけだけど、
調べていくうちに「なんかなー、いまいち手間に比べてメリットが薄い気がするなー」
というのが正直なところなわけですよ。メリットがあるのはわかるんだけど。
で、みんなにメリットを語ってもらおうと思って質問するんだけど、まだピンと来ない。
EclipseにSpringプラグインをいれたらxmlの定義を書いてるときもコード補完で
型検索とかできるの？
48 ：デフォルトの名無しさん：04/11/09 22:49:10
49 ：デフォルトの名無しさん：04/11/09 23:05:27
>>47
> 本当にユニット単位で検査すること(JUnitで出来るようなこと)
と
> 機能毎にプログラムの分岐を現実的な範囲内で網羅するような試験
って具体的にどう違うの？
後者はJUnitでは出来ないことなんだよね？
> 本当にユニット単位で検査すること(JUnitで出来るようなこと)
と
> 機能毎にプログラムの分岐を現実的な範囲内で網羅するような試験
って具体的にどう違うの？
後者はJUnitでは出来ないことなんだよね？
>>47
DIだけ見てて、AOPを見てないとか？
DIだけ見てて、AOPを見てないとか？
51 ：デフォルトの名無しさん：04/11/10 00:10:47
スレタイが「Dependency Injectionコンテナを語るスレ」だったら
AOPの話題もスレ違いにならなかった罠。
AOPの話題もスレ違いにならなかった罠。
52 ：デフォルトの名無しさん：04/11/10 00:17:47
>>47は以下のような依存関係を持つコンポーネントの単体テストを
どうやって実行してるんだろうか。
プレゼンテーション層のコントローラ
↓
ドメイン層のサービス
↓
データソース層のDAO
そもそも「そんな層分割は知らん」とか「一気通貫目視に決まってんだろ」とか
言うんだったら勉強して出直して来い。
「Mockで依存関係を切ってカバレッジ確保してます」ということならまずそこが
DIコンテナの出番。
どうやって実行してるんだろうか。
プレゼンテーション層のコントローラ
↓
ドメイン層のサービス
↓
データソース層のDAO
そもそも「そんな層分割は知らん」とか「一気通貫目視に決まってんだろ」とか
言うんだったら勉強して出直して来い。
「Mockで依存関係を切ってカバレッジ確保してます」ということならまずそこが
DIコンテナの出番。
>>51
AOPはスレ違いじゃないと思います。
http://www.kakutani.com/trans/fowler/injection.html#SomeFurtherIssues
>今のところ、本記事ではアスペクト指向については考慮していないが、今後追加するなり、
>他の記事を書くなりして、是非とも取り組んでみたいと思っている。
AOPはスレ違いじゃないと思います。
http://www.kakutani.com/trans/fowler/injection.html#SomeFurtherIssues
>今のところ、本記事ではアスペクト指向については考慮していないが、今後追加するなり、
>他の記事を書くなりして、是非とも取り組んでみたいと思っている。
54 ：デフォルトの名無しさん：04/11/10 00:33:54
55 ：デフォルトの名無しさん：04/11/10 00:59:42
>>49
うちの単体は機能単位でできることは出来るだけ網羅したい感じ。
画面遷移して前画面のパラメータも引きずってくるし、桁あふれを
狙うような無茶をするのも単体。テストデータはあまり厳密じゃない。
外部モジュールとは結合しないので代わりにエミュレーターを立てたりする。
JUnitでも頑張ってシナリオ持たせればできそうだけど、そうすると
今度はTestクラスの設計から始めないと、って感じじゃない？
結合検査は外部とも実際に繋ぐし、ログインからはじめて実際にあり得そうな
画面遷移のシナリオをいくつも用意してテスト。
ちっちゃい会社だから品質検査会社にテスト外注するわけでもないし、
この後はもうユーザーテストだけ。ユーザーテストでバグ出したくないから、
それぞれの重みはこうなっちゃうよ。場合によっちゃ客前で結合を
もう一回やるだけの事もあるし。
一般的なシステム会社から見たら単体の比重が大きいのかな？
ユーザーの前で単体テスト並のバグだしをする小さな会社も見てきたけど。
AOPのメリットはDIコンテナいれなくても享受できるでしょ。
AOPはDIとは別に見てる。AspectJとかちょこっといじってたし。
EclipseでTomcatプロジェクトと共用できなくて業務では使ってない。
AJDT入れると他のプラグインが挙動不審になったりしたし。
とまあこうしてスレの主題から脱線していくわけだが
うちの単体は機能単位でできることは出来るだけ網羅したい感じ。
画面遷移して前画面のパラメータも引きずってくるし、桁あふれを
狙うような無茶をするのも単体。テストデータはあまり厳密じゃない。
外部モジュールとは結合しないので代わりにエミュレーターを立てたりする。
JUnitでも頑張ってシナリオ持たせればできそうだけど、そうすると
今度はTestクラスの設計から始めないと、って感じじゃない？
結合検査は外部とも実際に繋ぐし、ログインからはじめて実際にあり得そうな
画面遷移のシナリオをいくつも用意してテスト。
ちっちゃい会社だから品質検査会社にテスト外注するわけでもないし、
この後はもうユーザーテストだけ。ユーザーテストでバグ出したくないから、
それぞれの重みはこうなっちゃうよ。場合によっちゃ客前で結合を
もう一回やるだけの事もあるし。
一般的なシステム会社から見たら単体の比重が大きいのかな？
ユーザーの前で単体テスト並のバグだしをする小さな会社も見てきたけど。
AOPのメリットはDIコンテナいれなくても享受できるでしょ。
AOPはDIとは別に見てる。AspectJとかちょこっといじってたし。
EclipseでTomcatプロジェクトと共用できなくて業務では使ってない。
AJDT入れると他のプラグインが挙動不審になったりしたし。
とまあこうしてスレの主題から脱線していくわけだが
56 ：デフォルトの名無しさん：04/11/10 01:14:33
>>52
このスレで続けていいのかな？ちょっと気がひけるけど。
うちはそもそもJUnitをまだ開発プロセスとして取り込んでない。
テスト項目漏れをチェックする基準がよーわからんから。
何回か導入すればノウハウも出てきてそれなりのクオリティで
検査できるようになるとは思うけど、お金もらって実験するほど
仕事なめてないから。胸張って導入できるほどの調査時間がとれない。
ただ、導入したいとは常々思ってる。
「それは一気通貫目視だからとっとと出直してこい」というなら
是非とも勉強したいので参考URLおせーて。その層は知ってるよ。
知ってるっていうよりjspでMVCモデル2とか言う言葉が出てくる前に
PACとかn層と実案件の関係を考えていて、n層の中でMVCでいうところの
Modelが機能(今でいうサービス？)、ユーティリティ、ドメインオブジェクト、dao
にわけたらキレイになるかなーとかやっていたので、その層はすんなり入ってきていた。
「Mockでカバレッジ」っていうのはわからん。
このスレで続けていいのかな？ちょっと気がひけるけど。
うちはそもそもJUnitをまだ開発プロセスとして取り込んでない。
テスト項目漏れをチェックする基準がよーわからんから。
何回か導入すればノウハウも出てきてそれなりのクオリティで
検査できるようになるとは思うけど、お金もらって実験するほど
仕事なめてないから。胸張って導入できるほどの調査時間がとれない。
ただ、導入したいとは常々思ってる。
「それは一気通貫目視だからとっとと出直してこい」というなら
是非とも勉強したいので参考URLおせーて。その層は知ってるよ。
知ってるっていうよりjspでMVCモデル2とか言う言葉が出てくる前に
PACとかn層と実案件の関係を考えていて、n層の中でMVCでいうところの
Modelが機能(今でいうサービス？)、ユーティリティ、ドメインオブジェクト、dao
にわけたらキレイになるかなーとかやっていたので、その層はすんなり入ってきていた。
「Mockでカバレッジ」っていうのはわからん。
57 ：デフォルトの名無しさん：04/11/10 01:19:46
>>52
ちなみにURLおせーて、っていうのは依存関係を持つコンポーネントの単体テストを
JUnitでわかりやすく実施するサンプルとかのことね。
でもコントローラーからdaoまでだったら、たとえばWebアプリなら普通に
URLのGETパラメータに情報載せてセッション帰ってきたらDBにアクセスして
値確認すればいいだけのような気がするけど、違うの？
ちなみにURLおせーて、っていうのは依存関係を持つコンポーネントの単体テストを
JUnitでわかりやすく実施するサンプルとかのことね。
でもコントローラーからdaoまでだったら、たとえばWebアプリなら普通に
URLのGETパラメータに情報載せてセッション帰ってきたらDBにアクセスして
値確認すればいいだけのような気がするけど、違うの？
すみませんすみません。DI+AOPもアリといういうことでお願いします。
AOP単独だとAspectJみたいな話になるし、そうすると別スレのほうが
いいのかなとか思ったりしますが、皆さんのご判断にお任せします。
初めてスレ立てしたので、気が回りませんでした。
回線吊って首切って逝ってきます。
>>48
ｵﾒ!
AOP単独だとAspectJみたいな話になるし、そうすると別スレのほうが
いいのかなとか思ったりしますが、皆さんのご判断にお任せします。
初めてスレ立てしたので、気が回りませんでした。
回線吊って首切って逝ってきます。
>>48
ｵﾒ!
59 ：デフォルトの名無しさん：04/11/10 01:26:35
>>55
> AspectJとかちょこっといじってたし。
> EclipseでTomcatプロジェクトと共用できなくて業務では使ってない。
> AJDT入れると他のプラグインが挙動不審になったりしたし。
> AOPのメリットはDIコンテナいれなくても享受できるでしょ。
享受できてないじゃんｗ
> AspectJとかちょこっといじってたし。
> EclipseでTomcatプロジェクトと共用できなくて業務では使ってない。
> AJDT入れると他のプラグインが挙動不審になったりしたし。
> AOPのメリットはDIコンテナいれなくても享受できるでしょ。
享受できてないじゃんｗ
60 ：デフォルトの名無しさん：04/11/10 01:30:29
連書きスマン
>依存関係を持つコンポーネントの単体テストをJUnitで
逆か。依存関係を切ったままJUnitでテストしろって話ね。
まあコントローラーでエラーになることは無いから(なったらテストクラスの
パラメータが足りないって事だから)Modelの段階でのエラーと
daoの段階でのエラーを分けて管理しろという事ですか。うーん、やっぱり
出直して勉強してきた方がいいみたいだけど、どのサイトorどの本を読めばそのメリットがわかる？
>依存関係を持つコンポーネントの単体テストをJUnitで
逆か。依存関係を切ったままJUnitでテストしろって話ね。
まあコントローラーでエラーになることは無いから(なったらテストクラスの
パラメータが足りないって事だから)Modelの段階でのエラーと
daoの段階でのエラーを分けて管理しろという事ですか。うーん、やっぱり
出直して勉強してきた方がいいみたいだけど、どのサイトorどの本を読めばそのメリットがわかる？
61 ：デフォルトの名無しさん：04/11/10 01:33:36
>>59
えーっと、俺が享受してたかどうかじゃなくて、DIに時間を割くべきかどうかの判断に
AOPは含まないよ、DI無しでAOPだけ導入することもできるから、って言いたかったんだけど
っていうか細かいツッコミにいちいち反応するなよ＜俺って感じ？
#これだけ書く時間があったらDIのサンプルぐらい動かせそうだな・・
えーっと、俺が享受してたかどうかじゃなくて、DIに時間を割くべきかどうかの判断に
AOPは含まないよ、DI無しでAOPだけ導入することもできるから、って言いたかったんだけど
っていうか細かいツッコミにいちいち反応するなよ＜俺って感じ？
#これだけ書く時間があったらDIのサンプルぐらい動かせそうだな・・
62 ：デフォルトの名無しさん：04/11/10 01:35:33
>>56
JUnitをいままでのテストを置き換えるものとしてとらえなくてもいいんじゃない？
むしろ、プログラマがプログラムが動いて自分の作業が完了したというためのものという感覚で。
いままでなら「コンパイルが通っただけでできたっていうなバカ、動作テストしたのか？」っていうところを、「ユニットテスト作ったのか？」っていう感じで。
JUnitをいままでのテストを置き換えるものとしてとらえなくてもいいんじゃない？
むしろ、プログラマがプログラムが動いて自分の作業が完了したというためのものという感覚で。
いままでなら「コンパイルが通っただけでできたっていうなバカ、動作テストしたのか？」っていうところを、「ユニットテスト作ったのか？」っていう感じで。
63 ：デフォルトの名無しさん：04/11/10 01:42:18
>>61
いや、>>55の書いていたような理由から、だれも実業務でAspectJなんか使えないし、つまりAOP使えてなかったんでしょ。
ほんとにAspectJでAOPだけ導入ができると思う？
で、DIコンテナですよ、と。
結局DIコンテナを評価するべきで、SpringとかSeasarとかはデータベース抽象化機能を提供してて宣言的トランザクションが使えて、と。
実際問題、DIコンテナは、宣言的トランザクションが気軽に使える仕組みだと最初はとらえていいんじゃないかと思ったりする。
いや、>>55の書いていたような理由から、だれも実業務でAspectJなんか使えないし、つまりAOP使えてなかったんでしょ。
ほんとにAspectJでAOPだけ導入ができると思う？
で、DIコンテナですよ、と。
結局DIコンテナを評価するべきで、SpringとかSeasarとかはデータベース抽象化機能を提供してて宣言的トランザクションが使えて、と。
実際問題、DIコンテナは、宣言的トランザクションが気軽に使える仕組みだと最初はとらえていいんじゃないかと思ったりする。
と勢いだけで書いてみたけど、AspectJで実際にシステム組んでるところってあるのかな？
パイロットプロジェクトという意味合いではなく。
パイロットプロジェクトという意味合いではなく。
65 ：かくたに ◆572YBhdE/s ：04/11/10 01:53:05
>>54 ありがとうございます。コテハンといっても基本ヲチなので捨てハンみたいなもんだからトリップ無用かな、と。
# とりあえずつけてみるテスト
AOP単体での導入はまんどくさいし、ニュータイプならぬPOJD(Plain Old Java Developer)には
見通し的に辛い。S2の文脈(というか他はまともには知らない)でのAOP適用は、
AOP的には邪道かもしれないけれど、DIと抱き合わせでついてくるし、コンポーネントに適用する、という
POJDに優しい枠組はうれしい。以上まとめると、63に禿同。
# とりあえずつけてみるテスト
AOP単体での導入はまんどくさいし、ニュータイプならぬPOJD(Plain Old Java Developer)には
見通し的に辛い。S2の文脈(というか他はまともには知らない)でのAOP適用は、
AOP的には邪道かもしれないけれど、DIと抱き合わせでついてくるし、コンポーネントに適用する、という
POJDに優しい枠組はうれしい。以上まとめると、63に禿同。
66 ：デフォルトの名無しさん：04/11/10 01:58:35
>>62
まーねー、それもそうなんだけど。折を見てみんなでやってみますわ。
でも新技術に積極的な人いないから、結局俺が使い方ちゃんと教えられるほど
になるまでノビノビ～というパターンだな。
>>63
AspectJが駄目だからDIコンテナをAOP込みで評価しろってことね。それもそだね。
そこで教えて欲しいんだけど、メソッドのin/outでトレースログを吐く以外に
どんなメリットがあるの？よくトランザクション管理が楽なんて見かけるんだけど、
マルチスレッドの時どうやって自分のトランザクションを取得するの？
今までのjdbcなら
Connection con = pool.getConnection();
con.setAutoCommit(false);
DaoTable1 dao1 = new DaoTable1(con);
dao1.update();
DaoTable2 dao2 = new DaoTable2(con);
dao2.update(); ...(1)
con.commit();
なんていう風にやっていて、AOPだとconを持ち回らなくていいなんていうけど、
(1)の時に別スレッドからこのトランザクションが開始されたとき、
conを持ち回らないでどうやって別々のトランザクションとして実行するのか
疑問だったんだけど。
まーねー、それもそうなんだけど。折を見てみんなでやってみますわ。
でも新技術に積極的な人いないから、結局俺が使い方ちゃんと教えられるほど
になるまでノビノビ～というパターンだな。
>>63
AspectJが駄目だからDIコンテナをAOP込みで評価しろってことね。それもそだね。
そこで教えて欲しいんだけど、メソッドのin/outでトレースログを吐く以外に
どんなメリットがあるの？よくトランザクション管理が楽なんて見かけるんだけど、
マルチスレッドの時どうやって自分のトランザクションを取得するの？
今までのjdbcなら
Connection con = pool.getConnection();
con.setAutoCommit(false);
DaoTable1 dao1 = new DaoTable1(con);
dao1.update();
DaoTable2 dao2 = new DaoTable2(con);
dao2.update(); ...(1)
con.commit();
なんていう風にやっていて、AOPだとconを持ち回らなくていいなんていうけど、
(1)の時に別スレッドからこのトランザクションが開始されたとき、
conを持ち回らないでどうやって別々のトランザクションとして実行するのか
疑問だったんだけど。
67 ：デフォルトの名無しさん：04/11/10 02:06:46
>>66
ThreadLocal
ThreadLocal
68 ：デフォルトの名無しさん：04/11/10 02:08:01
>>67
もしくはJTA
もしくはJTA
>>66
> AspectJが駄目だからDIコンテナをAOP込みで評価しろってことね。
そう。
つまり言語拡張の仕組みは受け入れにくいから、現実的にAOPのためにはDIが最適解かと。
それと、上の方に書いたけど、さまざまなオブジェクトから参照されるオブジェクトを横断的関心事として考えると、DIで横断的にインジェクションということも考えられる。
ThreadLocalは、サーブレットでのリクエストごとの情報を渡すのにとっても役に立って素敵。
> AspectJが駄目だからDIコンテナをAOP込みで評価しろってことね。
そう。
つまり言語拡張の仕組みは受け入れにくいから、現実的にAOPのためにはDIが最適解かと。
それと、上の方に書いたけど、さまざまなオブジェクトから参照されるオブジェクトを横断的関心事として考えると、DIで横断的にインジェクションということも考えられる。
ThreadLocalは、サーブレットでのリクエストごとの情報を渡すのにとっても役に立って素敵。
70 ：デフォルトの名無しさん：04/11/10 02:14:58
POJO
ぽじょ
POJD
ぽじゅどぅ
後者を発音すると一瞬自分がフィリップ・トゥルシエになった気分が味わえます(ウソ)。
ぽじょ
POJD
ぽじゅどぅ
後者を発音すると一瞬自分がフィリップ・トゥルシエになった気分が味わえます(ウソ)。
71 ：デフォルトの名無しさん：04/11/10 02:18:23
>>69
> ThreadLocalは、サーブレットでのリクエストごとの情報を渡すのにとっても役に立って素敵。
ThreadLocalは諸刃の剣だそうだ
http://d.hatena.ne.jp/higayasuo/20040828#1093674461
> ThreadLocalは、サーブレットでのリクエストごとの情報を渡すのにとっても役に立って素敵。
ThreadLocalは諸刃の剣だそうだ
http://d.hatena.ne.jp/higayasuo/20040828#1093674461
72 ：デフォルトの名無しさん：04/11/10 02:21:16
テストがしにくいってことね。なるほど。
73 ：デフォルトの名無しさん：04/11/10 02:22:17
POJDってなに？
74 ：デフォルトの名無しさん：04/11/10 02:27:45
75 ：デフォルトの名無しさん：04/11/10 02:30:05
結論：良さの判らない頭の悪い香具師は無理して使わなくて結構。
76 ：デフォルトの名無しさん：04/11/10 02:34:12
ageてまでいうことかと
77 ：デフォルトの名無しさん：04/11/10 02:35:41
かくたにさんとか太田さんとか良く名乗りを上げられるなと感心する。
本人かどうか疑えばきりが無いけどきっと本人でしょ？すごいな。
本人かどうか疑えばきりが無いけどきっと本人でしょ？すごいな。
>>74
つまりPOJDっていうのは、Javaの基本文法とJ2SEのライブラリは知ってるけど、他のライブラリとかフレームワークは知ったこっちゃない開発者ってことですね？
つまりPOJDっていうのは、Javaの基本文法とJ2SEのライブラリは知ってるけど、他のライブラリとかフレームワークは知ったこっちゃない開発者ってことですね？
中国語サイトのは、アノテーションのない普通の宣言ってことか。
みんなみんな、プレインオールドっていいたいだけ違うんかと。
そんなにプレインオールド好きなら、頭髪までプレインオールドになってしまえｗ
みんなみんな、プレインオールドっていいたいだけ違うんかと。
そんなにプレインオールド好きなら、頭髪までプレインオールドになってしまえｗ
80 ：デフォルトの名無しさん：04/11/10 02:54:56
82 ：デフォルトの名無しさん：04/11/10 02:59:40
83 ：デフォルトの名無しさん：04/11/10 03:01:03
84 ：デフォルトの名無しさん：04/11/10 03:04:18
Plain Old = 平凡な
PORH = 平凡なRod Hair
…普通じゃん。PORH!! ぽー！ ぽー！！
PORH = 平凡なRod Hair
…普通じゃん。PORH!! ぽー！ ぽー！！
ｼｮﾎﾞｰﾝ(´・ω・｀) ( ´・ω) ( ´・) ( ) (・´ ) (ω・´ ) (｀・ω・´)ｼｬｷｰﾝ
86 ：デフォルトの名無しさん：04/11/10 03:19:45
MOJOなんてのもあるぞ。
ttp://blog.goo.ne.jp/ikkoan/e/faee35340ce18875ead57930d40698e0
> "Mojo"の最初の"o"はどっから湧いて出たんだ!と突っ込みたくなりますが
禿同。
ttp://blog.goo.ne.jp/ikkoan/e/faee35340ce18875ead57930d40698e0
> "Mojo"の最初の"o"はどっから湧いて出たんだ!と突っ込みたくなりますが
禿同。
87 ：デフォルトの名無しさん：04/11/10 09:52:20
早速話がそれてきてるわけですが。
とりあえず何を語ればいいのかがよく分からない。
とりあえず何を語ればいいのかがよく分からない。
88 ： ◆TDNdW1Xcyo ：04/11/10 10:33:40
54さん>トリップつけました。失礼しました。
別にはずかしことを書いているわけじゃないので，
あえて匿名にする必要はないかなと思っています。
むしろ皆さん非常にすぐれた開発者の方だと思いますので，
リアルでお会いして話を聞きたいぐらいです。
ちょっとテストの話から離れてしまいましたが，
僕の本業はテストなのでその筋から単体テストが
容易になるDIに興味を持ちました。
#AOPはビジネスロジックの開発者が自分で実装しようとすると逆にテストがし
#にくくなるので，本当に必要な場合のみアーキテクチャチームが実装し，
#ビジネスロジックの開発者が利用するというのが現実的かと。
で，一応会社には単体テストの基準として，メソッドレベルで分岐網羅とか
あるわけですが，依存関係の強い設計をするとこれが有名無実化されてしま
って，本来適切に分離できていれば，単体(かつ自動テスト対象)で検出でき
たバグが結合テスト，システムテスト以降に持ち越されて発見，テスターも
開発者も疲労困憊という悪夢になります。これじゃあ，全然OOのメリットを
生かせてないじゃん，でもなんか解決策はあるはず，で出会ったのがDIとい
うわけです。
別にはずかしことを書いているわけじゃないので，
あえて匿名にする必要はないかなと思っています。
むしろ皆さん非常にすぐれた開発者の方だと思いますので，
リアルでお会いして話を聞きたいぐらいです。
ちょっとテストの話から離れてしまいましたが，
僕の本業はテストなのでその筋から単体テストが
容易になるDIに興味を持ちました。
#AOPはビジネスロジックの開発者が自分で実装しようとすると逆にテストがし
#にくくなるので，本当に必要な場合のみアーキテクチャチームが実装し，
#ビジネスロジックの開発者が利用するというのが現実的かと。
で，一応会社には単体テストの基準として，メソッドレベルで分岐網羅とか
あるわけですが，依存関係の強い設計をするとこれが有名無実化されてしま
って，本来適切に分離できていれば，単体(かつ自動テスト対象)で検出でき
たバグが結合テスト，システムテスト以降に持ち越されて発見，テスターも
開発者も疲労困憊という悪夢になります。これじゃあ，全然OOのメリットを
生かせてないじゃん，でもなんか解決策はあるはず，で出会ったのがDIとい
うわけです。
89 ：太田＠会社 ◆TDNdW1Xcyo ：04/11/10 10:35:47
失礼しました。つけ方間違えました。
90 ：デフォルトの名無しさん：04/11/10 12:40:38
まだDIもJUnitも使ってないのでアレですが、
単体で網羅されてないことと設計段階の依存性がそれほど
関係あるとは思えないです。たしかにsetXXみたいなメソッドは
DIのobjectが読み込めた時点で正常動作しているので
JUnitでの項目は減らせるのかもしれませんが。
単体試験の項目はちゃんとレビューされてますか？項目漏れは
レビューアーの責任ですよね。って釈迦に説法かな。
自動テスト対象の項目はどうやってレビューされているか、
今後の導入の参考までに伺いたいです。
単体で網羅されてないことと設計段階の依存性がそれほど
関係あるとは思えないです。たしかにsetXXみたいなメソッドは
DIのobjectが読み込めた時点で正常動作しているので
JUnitでの項目は減らせるのかもしれませんが。
単体試験の項目はちゃんとレビューされてますか？項目漏れは
レビューアーの責任ですよね。って釈迦に説法かな。
自動テスト対象の項目はどうやってレビューされているか、
今後の導入の参考までに伺いたいです。
91 ：デフォルトの名無しさん：04/11/10 13:31:09
>>90
少し話がずれてると思う。
A->B->Cという依存関係のあるクラスが3つあるとする。
もし依存関係が強いとCの単体テストはできるが
BとCは単体では動かすこともできない
よって単体テストで網羅できるのはクラス数で数えると
わずか1/3にしかならない。
90はCができてからBを、BができてからAをテストするのかも
しれないが、それは単体テストではなく結合テストだし、
A・B・Cの担当者が違う場合にだれが責任持ってテストするのか？
DIで依存性を排除できればそれぞれ担当者が単体テストを
実施できて網羅率を上げることができる。
少し話がずれてると思う。
A->B->Cという依存関係のあるクラスが3つあるとする。
もし依存関係が強いとCの単体テストはできるが
BとCは単体では動かすこともできない
よって単体テストで網羅できるのはクラス数で数えると
わずか1/3にしかならない。
90はCができてからBを、BができてからAをテストするのかも
しれないが、それは単体テストではなく結合テストだし、
A・B・Cの担当者が違う場合にだれが責任持ってテストするのか？
DIで依存性を排除できればそれぞれ担当者が単体テストを
実施できて網羅率を上げることができる。
92 ：デフォルトの名無しさん：04/11/10 14:05:22
単体テスト・結合テストの粒度が違う人たちが議論してるように見えるのは俺だけ？
93 ：太田＠会社 ◆TDNdW1Xcyo ：04/11/10 15:10:08
DIによる依存性の分離と単体テストとの関係は90さんが既におっしゃって
いますが，私が直面したのは息の長い製品で欠陥が発生したときの原因追求
に必要な時間です。依存関係が高い場合のボトムアップのテストだと，切り
分けが非常に難しいのです。テストの分離による保守性の高さという観点も
有効かなと。
あと，私がいる会社は非常にレビューを重視(インスペクション専門の組織が
あり過度といってよい)する組織ですが，逆にそれがあだとなって，ツールを
使ったり，自動化したり，テスト容易性を高めたりということが遅れています。
レビューって結局実際に動作させているわけではないので，僕はあまりレビュー
を重視するのは考えものかなと思います。
いますが，私が直面したのは息の長い製品で欠陥が発生したときの原因追求
に必要な時間です。依存関係が高い場合のボトムアップのテストだと，切り
分けが非常に難しいのです。テストの分離による保守性の高さという観点も
有効かなと。
あと，私がいる会社は非常にレビューを重視(インスペクション専門の組織が
あり過度といってよい)する組織ですが，逆にそれがあだとなって，ツールを
使ったり，自動化したり，テスト容易性を高めたりということが遅れています。
レビューって結局実際に動作させているわけではないので，僕はあまりレビュー
を重視するのは考えものかなと思います。
94 ：デフォルトの名無しさん：04/11/10 18:52:41
>依存性の分離と単体テストとの関係は90さんが
91だよね。なるほど、言いたいことはよくわかりました。でも単体で網羅すべき
基準がやっぱり違うようですね。
>息の長い製品で欠陥が発生したときの原因追求に必要な時間
太田さんはRUP推進派とのことでしたよね？なら理想はちゃんとOOして
クラスの責任分担が明確になっていれば、それが一番工数の削減に
繋がるけど、実際は現場の人間のスキルによってそうもいかんから
DIはいいんじゃないかってことですかね。
ちゃんとOOすることとDIを使うことを別の次元とは思ってないですよ。念のため。
ちゃんとOOした中でもDIという手法があると捉えています。
レビューしないでスキルの低い技術者が作ったものがそのまま放置されるのは
いただけないですよね。レビューアがスキルの高い人のやり方をスキルの低い人に
伝えていくことができればいいんですけどねえ。レビューによって詳細な進捗もわかるし。
専門の組織があるのは微妙ですね。レビューはプロジェクトリーダーがやって、
リーダーは自分の範囲内の仕様は把握していて、突発的な欠員がでても
代わりの人にちゃんと引き継げるくらいの近さがいいと思ってます。
太田さんとこは大きな会社っぽいので組織変更は難しいでしょうけど。
91だよね。なるほど、言いたいことはよくわかりました。でも単体で網羅すべき
基準がやっぱり違うようですね。
>息の長い製品で欠陥が発生したときの原因追求に必要な時間
太田さんはRUP推進派とのことでしたよね？なら理想はちゃんとOOして
クラスの責任分担が明確になっていれば、それが一番工数の削減に
繋がるけど、実際は現場の人間のスキルによってそうもいかんから
DIはいいんじゃないかってことですかね。
ちゃんとOOすることとDIを使うことを別の次元とは思ってないですよ。念のため。
ちゃんとOOした中でもDIという手法があると捉えています。
レビューしないでスキルの低い技術者が作ったものがそのまま放置されるのは
いただけないですよね。レビューアがスキルの高い人のやり方をスキルの低い人に
伝えていくことができればいいんですけどねえ。レビューによって詳細な進捗もわかるし。
専門の組織があるのは微妙ですね。レビューはプロジェクトリーダーがやって、
リーダーは自分の範囲内の仕様は把握していて、突発的な欠員がでても
代わりの人にちゃんと引き継げるくらいの近さがいいと思ってます。
太田さんとこは大きな会社っぽいので組織変更は難しいでしょうけど。
95 ：デフォルトの名無しさん：04/11/10 19:18:17
いい年こいて、昼間っから会社で2chかよ…
……窓際？
……窓際？
96 ：デフォルトの名無しさん：04/11/10 19:28:49
>>95
仕事の出来ない同僚？(ﾜﾗ
仕事の出来ない同僚？(ﾜﾗ
97 ：デフォルトの名無しさん：04/11/10 20:56:18
>>95
なんか嫌なことでもあったのか？
なんか嫌なことでもあったのか？
98 ：デフォルトの名無しさん：04/11/10 21:03:21
PHPのDIコンテナってありますか？
99 ：デフォルトの名無しさん：04/11/10 21:12:59
IT戦略部に通報しますた。
100 ：デフォルトの名無しさん：04/11/10 23:31:16
DIやろうとするとやたらとinterfaceが多くなってしまうような気がするんですが
そんなことない？
コンテナに管理任せるクラスって何を基準に決めるの？
そんなことない？
コンテナに管理任せるクラスって何を基準に決めるの？
101 ：デフォルトの名無しさん：04/11/11 00:19:17
>>100
DIやろうとしなくてもやたらとinterfaceが多くなるよ。
DIやろうとしなくてもやたらとinterfaceが多くなるよ。
102 ：デフォルトの名無しさん：04/11/11 00:52:04
91の主張はマクロな視点だとその通りなんだけど、
実際クラス間に依存があるテストを行う場合、どちらかのテストを先にするしかなくなるんだよね。
すべてのクラスにDI適用させるのは無駄だし
実際クラス間に依存があるテストを行う場合、どちらかのテストを先にするしかなくなるんだよね。
すべてのクラスにDI適用させるのは無駄だし
103 ：デフォルトの名無しさん：04/11/11 01:00:52
俺はOOすることとDIすることは全く別次元
(相補的ではあるが依存でも排他でもない)
だと思うんだが、認識間違ってるのかな？
>100
interface は別に増えてもかまわないのでは。
増えることでどんなメリットとデメリットが出るかが重要なのであって。
>102
91氏は依存性がある場合はA→B→Cの順にやる、
って明言してると思いますが。
なんか1氏の思惑通りにはスレが進んでない気がするよ。
(相補的ではあるが依存でも排他でもない)
だと思うんだが、認識間違ってるのかな？
>100
interface は別に増えてもかまわないのでは。
増えることでどんなメリットとデメリットが出るかが重要なのであって。
>102
91氏は依存性がある場合はA→B→Cの順にやる、
って明言してると思いますが。
なんか1氏の思惑通りにはスレが進んでない気がするよ。
104 ：デフォルトの名無しさん：04/11/11 01:04:36
DBのWebフロントエンドだと、結果的にすべてのクラスにDI適用させることになったりして。
で、そういうアプリケーションだと、せいぜい継承くらい知っておけば、OOの知識というのもほとんど必要なかったり。
細切れの独立したクラスをDIで結びつけるわけで。
で、そういうアプリケーションだと、せいぜい継承くらい知っておけば、OOの知識というのもほとんど必要なかったり。
細切れの独立したクラスをDIで結びつけるわけで。
105 ：デフォルトの名無しさん：04/11/11 01:09:14
>>103
> 俺はOOすることとDIすることは全く別次元
> (相補的ではあるが依存でも排他でもない)
> だと思うんだが、認識間違ってるのかな？
DIはOOの上に成り立ってると思うが。
OOする、っていうのがなんのことなのかよくわからんけど。
> なんか1氏の思惑通りにはスレが進んでない気がするよ。
荒れてないし、いいんでないの？
> 俺はOOすることとDIすることは全く別次元
> (相補的ではあるが依存でも排他でもない)
> だと思うんだが、認識間違ってるのかな？
DIはOOの上に成り立ってると思うが。
OOする、っていうのがなんのことなのかよくわからんけど。
> なんか1氏の思惑通りにはスレが進んでない気がするよ。
荒れてないし、いいんでないの？
106 ：デフォルトの名無しさん：04/11/11 01:25:39
107 ：デフォルトの名無しさん：04/11/11 01:27:32
結局DIも適用させる範囲絞らないと効率悪くなるから
トレードオフなんだよね
トレードオフなんだよね
108 ：デフォルトの名無しさん：04/11/11 01:51:55
>106
＞順番逆になる
そうですね。うっかりしてました。
＞独立してテストするって言ってる
？ DIで依存性を排除できれば、では？
ところでDIって一言でいった場合、どういう意味なんでしょうか。
相関するモジュール群の結合を疎にし、コードベースではなく
コンフィグレーション(XMLファイルがありがち)によって結び付ける、
程度の意味だと思ってたんでOOの上とは違うよな、と思ってしまうんですが。
＞順番逆になる
そうですね。うっかりしてました。
＞独立してテストするって言ってる
？ DIで依存性を排除できれば、では？
ところでDIって一言でいった場合、どういう意味なんでしょうか。
相関するモジュール群の結合を疎にし、コードベースではなく
コンフィグレーション(XMLファイルがありがち)によって結び付ける、
程度の意味だと思ってたんでOOの上とは違うよな、と思ってしまうんですが。
109 ：デフォルトの名無しさん：04/11/11 01:54:30
クラスとクラスの関連が強いんであっても、そのクラスを取り替えることがなかったり、オブジェクトを一つずつしか生成しないんだったら、あまりDIの意味はないね。
業務アプリみたいに、似たようなクラスと別の似たようなクラスをいろいろな組み合わせで関連させるものだとDIのやりがいがあると思う。
業務アプリみたいに、似たようなクラスと別の似たようなクラスをいろいろな組み合わせで関連させるものだとDIのやりがいがあると思う。
110 ：デフォルトの名無しさん：04/11/11 01:57:30
>>108
オブジェクトとオブジェクトを結びつけるものだと思うので、OOありきかと。
OOじゃない技術の上でDIするためには、結局OOじゃない技術の上でOOみたいなことをしてないとDIできないんじゃないかと。
オブジェクトとオブジェクトを結びつけるものだと思うので、OOありきかと。
OOじゃない技術の上でDIするためには、結局OOじゃない技術の上でOOみたいなことをしてないとDIできないんじゃないかと。
111 ：デフォルトの名無しさん：04/11/11 02:46:44
>>108
コードベースじゃないとは限らないよ。Picoの例があるし
コードベースじゃないとは限らないよ。Picoの例があるし
112 ：太田＠会社 ◆TDNdW1Xcyo ：04/11/11 11:26:10
うん，窓際かも・・・
113 ：デフォルトの名無しさん：04/11/11 13:20:59
>>109
そうなんだよ。
だから、eclipseを見習おうといいたい。
extension point をアプリ側で定義する。
変更箇所が多そうなところを見つけてうまく定義すると素晴らしいアプリケーションになる。
ポリモーフィズムがここで大いに生きる。
DIで凡庸的にオブジェクトの定義の仕方云々っていっても、そんなのたいした意味ないわけ。
それならorg.eclipse.core.runtimeやosgiフレームワークのほうが偉いと思うよ。
そうなんだよ。
だから、eclipseを見習おうといいたい。
extension point をアプリ側で定義する。
変更箇所が多そうなところを見つけてうまく定義すると素晴らしいアプリケーションになる。
ポリモーフィズムがここで大いに生きる。
DIで凡庸的にオブジェクトの定義の仕方云々っていっても、そんなのたいした意味ないわけ。
それならorg.eclipse.core.runtimeやosgiフレームワークのほうが偉いと思うよ。
114 ：デフォルトの名無しさん：04/11/11 13:27:01
>>113
>だから、eclipseを見習おうといいたい。
>extension point をアプリ側で定義する。
>変更箇所が多そうなところを見つけてうまく定義すると素晴らしいアプリケーションになる。
具体例を提示されたことで、なんか目の前が開けてきました。
>だから、eclipseを見習おうといいたい。
>extension point をアプリ側で定義する。
>変更箇所が多そうなところを見つけてうまく定義すると素晴らしいアプリケーションになる。
具体例を提示されたことで、なんか目の前が開けてきました。
115 ：デフォルトの名無しさん：04/11/11 13:28:21
まあ、extension pointっていっても、そんなもん無くたってプラグイン機構は作れるんだが
ここで人間の感性が反映されるわけ。コードの表現力が。
DIが悲しいのは、苦労して導入したところで、手間の割に表現力に乏しいところだと思うんだよ。
それと、DIを導入することで、初心者にも仕事をまかせられるとかいう意見あるけど、
これはどうも、いまいち。あやしい。
そんなことやる暇あれば仲良くなるためにどうすればいいか、考えたほうがいいなと。
ここで人間の感性が反映されるわけ。コードの表現力が。
DIが悲しいのは、苦労して導入したところで、手間の割に表現力に乏しいところだと思うんだよ。
それと、DIを導入することで、初心者にも仕事をまかせられるとかいう意見あるけど、
これはどうも、いまいち。あやしい。
そんなことやる暇あれば仲良くなるためにどうすればいいか、考えたほうがいいなと。
116 ：デフォルトの名無しさん：04/11/11 13:33:50
eclipseの設計思想は、googleで
"the eclipse house rules"
を検索されたい。
なぜこんな素晴らしい設計指針がマッチする文章がPDF一枚なのかは謎だが、
結局地道にこれを実践することがいいアプリを作る唯一の方法なのだと漏れは結論する
"the eclipse house rules"
を検索されたい。
なぜこんな素晴らしい設計指針がマッチする文章がPDF一枚なのかは謎だが、
結局地道にこれを実践することがいいアプリを作る唯一の方法なのだと漏れは結論する
117 ：デフォルトの名無しさん：04/11/11 15:48:40
DIだけだとそうかもしれんが、DI+AOPだと業務アプリには欠かせない。
デスクトップツールやライブラリ自体にはDIは不要だと思われる。つまりeclipse。
springやseasarにしても、その周辺ライブラリはDI使ってないものが多いし。
デスクトップツールやライブラリ自体にはDIは不要だと思われる。つまりeclipse。
springやseasarにしても、その周辺ライブラリはDI使ってないものが多いし。
118 ：デフォルトの名無しさん：04/11/11 15:49:28
△周辺ライブラリ
○周辺ライブラリ自体
○周辺ライブラリ自体
119 ：デフォルトの名無しさん：04/11/11 15:50:46
いや、適応範囲の問題ではなく、設計のコンセプトの問題でしょう。
120 ：デフォルトの名無しさん：04/11/11 16:11:41
>>119
そうとは言い難い。
DIはどちらかというと、多層化のアプローチで複数機能があるとき、升目状の設計になるわけだけど、それぞれの升ごとの独立性を高めるのにDIが有効になる。
それぞれの升目の中ではあまりDIは有効じゃなくて通常のOOアプローチになるんだけど、あまりクラスの関連が複雑になることもない。
逆に、デスクトップツールの場合は、それぞれのオブジェクトの依存性がもともと大きいので、DIで依存性の注入どころじゃない。
例えば、MapとEntryとIteratorをDIつかって独立性を高くってできないような感じ。
そうとは言い難い。
DIはどちらかというと、多層化のアプローチで複数機能があるとき、升目状の設計になるわけだけど、それぞれの升ごとの独立性を高めるのにDIが有効になる。
それぞれの升目の中ではあまりDIは有効じゃなくて通常のOOアプローチになるんだけど、あまりクラスの関連が複雑になることもない。
逆に、デスクトップツールの場合は、それぞれのオブジェクトの依存性がもともと大きいので、DIで依存性の注入どころじゃない。
例えば、MapとEntryとIteratorをDIつかって独立性を高くってできないような感じ。
121 ：デフォルトの名無しさん：04/11/11 17:48:29
>>115
>DIが悲しいのは、苦労して導入したところで、手間の割に表現力に乏しいところだと思うんだよ。
DIの導入に苦労？ どんな？
表現力ほどの手間もかからないと思うが？
Eclipseのプラグインは見事だと思うけど業務アプリには
それこそ手間の割にメリットがないと思う。
>extension point をアプリ側で定義する。
それがうまくいくくらい業務要件の未来が予測できる？
ツールのように使い手により様々にカスタマイズするのとは
コンテキストが違いすぎて正直参考にならんと思う。
>DIが悲しいのは、苦労して導入したところで、手間の割に表現力に乏しいところだと思うんだよ。
DIの導入に苦労？ どんな？
表現力ほどの手間もかからないと思うが？
Eclipseのプラグインは見事だと思うけど業務アプリには
それこそ手間の割にメリットがないと思う。
>extension point をアプリ側で定義する。
それがうまくいくくらい業務要件の未来が予測できる？
ツールのように使い手により様々にカスタマイズするのとは
コンテキストが違いすぎて正直参考にならんと思う。
122 ：デフォルトの名無しさん：04/11/11 17:52:58
というか、DIがめんどくさいとか言ってる人は、DI使ったことないだけじゃないかと。
123 ：デフォルトの名無しさん：04/11/11 17:58:43
俺は使った事ないんですど、確かに雑誌の記事など読むと
設定ファイルとかめんどうくさそうに思えます。
設定ファイルとかめんどうくさそうに思えます。
124 ：デフォルトの名無しさん：04/11/11 18:17:13
「BOYがGIRLに・・・」だけの場合だと、確かにめんどくさい。
でもある程度実用的な業務アプリだと、簡単にそのコストは回収できる。
ただ、現実的には、DIコンテナの価値は、その周辺ライブラリにあると思う。
Webでデータベース使うなら、しのごの言わずにSpringかSeasar使うべき。
また、そういった周辺ライブラリが作りやすいのもDIコンテナの特徴。
だから今後も周辺ライブラリは増えていくと思われ。
それと、業務で作った機能がなぜかライブラリとして独立した形になっているのもDIコンテナ使った場合の特徴。
でもある程度実用的な業務アプリだと、簡単にそのコストは回収できる。
ただ、現実的には、DIコンテナの価値は、その周辺ライブラリにあると思う。
Webでデータベース使うなら、しのごの言わずにSpringかSeasar使うべき。
また、そういった周辺ライブラリが作りやすいのもDIコンテナの特徴。
だから今後も周辺ライブラリは増えていくと思われ。
それと、業務で作った機能がなぜかライブラリとして独立した形になっているのもDIコンテナ使った場合の特徴。
SpringとSeasarでは、今のところSpringの方が導入が楽。
Seasarは、現時点では周辺ライブラリの充実度やドキュメントの整備など今一歩のところがある。
ただ、のびしろとしてはSeasarの方があるので、S2JSFとSeasar自体のブラッシュアップ、ドキュメントの整備、英語圏へのプロモーションが進めば大ブレイクするかもね。
今は中の人が盛り上がってるだけだけど、このままのモチベーションで開発が続けば１年半後くらいがみものかも。
Seasarは、現時点では周辺ライブラリの充実度やドキュメントの整備など今一歩のところがある。
ただ、のびしろとしてはSeasarの方があるので、S2JSFとSeasar自体のブラッシュアップ、ドキュメントの整備、英語圏へのプロモーションが進めば大ブレイクするかもね。
今は中の人が盛り上がってるだけだけど、このままのモチベーションで開発が続けば１年半後くらいがみものかも。
そういう意味では、情報集約サイトとして機能してないホームページをどうにかして欲しいんだけど、S2JSFとセミナー準備で手一杯のようだ。
年があけたころから機能していくんじゃないかと、外野から見て思う。
年があけたころから機能していくんじゃないかと、外野から見て思う。
127 ：デフォルトの名無しさん：04/11/11 18:49:04
>>123
テキストエディタで設定ファイルを書くのは確かに面倒。特にSpring。
そこでEclipseプラグインの出番。SpringやS2にはすでにある。
S2のKijimunaというEclipseプラグインは設定ファイルのエディタを提供してくれる。
XMLの要素や属性の補完だけではなく、クラス名やプロパティ名も補完してくれるから
面倒さはほとんど感じない。
テキストエディタで設定ファイルを書くのは確かに面倒。特にSpring。
そこでEclipseプラグインの出番。SpringやS2にはすでにある。
S2のKijimunaというEclipseプラグインは設定ファイルのエディタを提供してくれる。
XMLの要素や属性の補完だけではなく、クラス名やプロパティ名も補完してくれるから
面倒さはほとんど感じない。
SpringはAOPの定義がクソめんどいね。
技術的にはSeasarの方がかなりいいと思う。
ただ、現状スウィートスポットがSpringより狭い印象がある。けど、時間の問題。
技術的にはSeasarの方がかなりいいと思う。
ただ、現状スウィートスポットがSpringより狭い印象がある。けど、時間の問題。
129 ：デフォルトの名無しさん：04/11/11 19:00:22
>>125
Seasarに足りない周辺ライブラリって？
Springの方が充実してるのは確かだと思うけど，
差があるのはJDOとかiBATISとかVelocityとかSpring MVCとか、
なくても困らないようなマイナーなものばっかりじゃない？
そのためにSpringとは思わないけど。
Seasarに足りない周辺ライブラリって？
Springの方が充実してるのは確かだと思うけど，
差があるのはJDOとかiBATISとかVelocityとかSpring MVCとか、
なくても困らないようなマイナーなものばっかりじゃない？
そのためにSpringとは思わないけど。
130 ：デフォルトの名無しさん：04/11/11 19:16:33
>>129
そりゃ、iBatis使ってない人にはなくて困らないだろうけど。
そりゃ、iBatis使ってない人にはなくて困らないだろうけど。
131 ：デフォルトの名無しさん：04/11/11 19:23:13
iBatis使ってない人には、iBatis+SpringよりもS2Daoでいいだろうけどね。
132 ：デフォルトの名無しさん：04/11/11 19:26:20
そんなにiBATISユーザって多いのか。そっちのほうがビックリする。
133 ：デフォルトの名無しさん：04/11/11 19:28:35
>>130
スマソ
意図としては、すでにiBATISなどを使っているところに
DIコンテナを導入するという状況ではなくて、これから新たに
開発する際にDIコンテナとしてSpringかS2のどちらにするかの
判断材料となるほど影響力のあるプロダクトのサポートに違いが
あるのか聞きたいということなので許してほしい。
スマソ
意図としては、すでにiBATISなどを使っているところに
DIコンテナを導入するという状況ではなくて、これから新たに
開発する際にDIコンテナとしてSpringかS2のどちらにするかの
判断材料となるほど影響力のあるプロダクトのサポートに違いが
あるのか聞きたいということなので許してほしい。
>>132
たぶん、多くはないんだろうけど、それなりに開発をやってると、なにか一つマイナーなライブラリを使ってたりして、Springだと検索するとみつかる感じ。
その代表がiBATISってことで。
>>133
しがらみなく新たに開発だと、そこまで影響力のあるライブラリの違いは確かにないと思う。
Hibernate2対応とかそれぞれのライブラリをみると、むしろSeasarの方に軍配があがるとも思うし。
S2DaoがiBATIS自体を補完すると思うので、新たにiBATIS対応する必要もない気もする。
だから、若干スウィートスポットが狭いと感じるのも時間の問題だと。
たぶん、多くはないんだろうけど、それなりに開発をやってると、なにか一つマイナーなライブラリを使ってたりして、Springだと検索するとみつかる感じ。
その代表がiBATISってことで。
>>133
しがらみなく新たに開発だと、そこまで影響力のあるライブラリの違いは確かにないと思う。
Hibernate2対応とかそれぞれのライブラリをみると、むしろSeasarの方に軍配があがるとも思うし。
S2DaoがiBATIS自体を補完すると思うので、新たにiBATIS対応する必要もない気もする。
だから、若干スウィートスポットが狭いと感じるのも時間の問題だと。
135 ：デフォルトの名無しさん：04/11/11 20:11:48
>>124
>それと、業務で作った機能がなぜかライブラリとして独立した形になっている
もう、そんな幻想だれが信じるんだよ。
ひとつでいいから実例見せてくれ。
> ただ、現実的には、DIコンテナの価値は、その周辺ライブラリ
ツールに頼る必要のないところでなんでそんなにツールマンセーになれるのか不思議だよ。
そんなにツールのこと学ばなくても、シンプルに設計することを知らなきゃ意味ないし、
シンプルに設計することはツールは必要ない。
>それと、業務で作った機能がなぜかライブラリとして独立した形になっている
もう、そんな幻想だれが信じるんだよ。
ひとつでいいから実例見せてくれ。
> ただ、現実的には、DIコンテナの価値は、その周辺ライブラリ
ツールに頼る必要のないところでなんでそんなにツールマンセーになれるのか不思議だよ。
そんなにツールのこと学ばなくても、シンプルに設計することを知らなきゃ意味ないし、
シンプルに設計することはツールは必要ない。
>>135
実例としては、DIコンテナの周辺ライブラリ。
DIコンテナって、周辺ライブラリがたくさんあるけど、それは、簡単にライブラリ化できるから。
公式じゃなくてもSpringXXXとかS2Xxxとかいっぱいある。
DIコンテナは周辺ライブラリあってナンボだと思ってて、DIのみ語ってめんどくさそうとか言ってもしかたないと思ってるから。
で、周辺ライブラリがそろってるDIコンテナはSpringとSeasarになるかと。
もちろん、DIはDIでとても有意義なものだと思うけど。
比較的あたらしいスレでこんなこというのもなんだけど、現実的には「DIってどうよ？」という段階はすでに過ぎてると思う。
> ツールに頼る必要のないところで
だって、便利だし。
あと、SpringとかSeasarって、使っててもそんなに依存するものじゃないから、Spring+Hibernate+StrutsでやってるものをSpringからSeasarに乗り換えるのも、そこまで苦ではない。
> シンプルに設計することはツールは必要ない。
知識も必要だし、ツールも必要だと思う。
もちろん、デザインパターンってなに？という人だけが集まってDIを活かせるとは思わない。
DIでのシンプルな設計を学ぶには、DIコンテナ使う必要はあると思う。
実例としては、DIコンテナの周辺ライブラリ。
DIコンテナって、周辺ライブラリがたくさんあるけど、それは、簡単にライブラリ化できるから。
公式じゃなくてもSpringXXXとかS2Xxxとかいっぱいある。
DIコンテナは周辺ライブラリあってナンボだと思ってて、DIのみ語ってめんどくさそうとか言ってもしかたないと思ってるから。
で、周辺ライブラリがそろってるDIコンテナはSpringとSeasarになるかと。
もちろん、DIはDIでとても有意義なものだと思うけど。
比較的あたらしいスレでこんなこというのもなんだけど、現実的には「DIってどうよ？」という段階はすでに過ぎてると思う。
> ツールに頼る必要のないところで
だって、便利だし。
あと、SpringとかSeasarって、使っててもそんなに依存するものじゃないから、Spring+Hibernate+StrutsでやってるものをSpringからSeasarに乗り換えるのも、そこまで苦ではない。
> シンプルに設計することはツールは必要ない。
知識も必要だし、ツールも必要だと思う。
もちろん、デザインパターンってなに？という人だけが集まってDIを活かせるとは思わない。
DIでのシンプルな設計を学ぶには、DIコンテナ使う必要はあると思う。
誤解のないように補足しておくと、Springでやってるプロジェクトを途中からSeasarに切り替えるのはもちろん作業時間てきに無駄。
ではなくて、前のプロジェクトをSpringでやってて、次のプロジェクトはSeasarでっていうときに、前のプロジェクトの成果物の再利用に苦労はそれほどないってこと。
ではなくて、前のプロジェクトをSpringでやってて、次のプロジェクトはSeasarでっていうときに、前のプロジェクトの成果物の再利用に苦労はそれほどないってこと。
ぶっちゃけ言えば、Web+DBの業務アプリで、プログラム自体の設計に頭を使ってもしかたないと思う今日この頃。
139 ：デフォルトの名無しさん：04/11/11 20:55:48
>>134
> たぶん、多くはないんだろうけど、それなりに開発をやってると、なにか一つマイナーなライブラリを使ってたりして、Springだと検索するとみつかる感じ。
> その代表がiBATISってことで。
ああ、なるほどね。納得した。
> たぶん、多くはないんだろうけど、それなりに開発をやってると、なにか一つマイナーなライブラリを使ってたりして、Springだと検索するとみつかる感じ。
> その代表がiBATISってことで。
ああ、なるほどね。納得した。
140 ：デフォルトの名無しさん：04/11/11 21:00:58
>>135
> もう、そんな幻想だれが信じるんだよ。
信じなくてもいいよ。出てきたばかりのものに実績とか言われてもな。
オブジェクト指向だって何10年かかってようやく今の認知度だ。
> そんなにツールのこと学ばなくても、シンプルに設計することを知らなきゃ意味ないし、
> シンプルに設計することはツールは必要ない。
考え方とツールが別というのはわかるけど、ツールがないのに考え方ばかり
論じてたって形あるものにはならんと思うよ。
> もう、そんな幻想だれが信じるんだよ。
信じなくてもいいよ。出てきたばかりのものに実績とか言われてもな。
オブジェクト指向だって何10年かかってようやく今の認知度だ。
> そんなにツールのこと学ばなくても、シンプルに設計することを知らなきゃ意味ないし、
> シンプルに設計することはツールは必要ない。
考え方とツールが別というのはわかるけど、ツールがないのに考え方ばかり
論じてたって形あるものにはならんと思うよ。
141 ：デフォルトの名無しさん：04/11/11 21:01:30
>>138
俺も同意する。
俺も同意する。
142 ：デフォルトの名無しさん：04/11/11 21:11:40
なあ>>135よ、オマエさんはきっと出来る奴なんだろうな。
ところでな、オマエさんのその考えとかを同僚とかはすぐに理解してくれるかい？
もしそうなら恵まれた職場にいるし、だったらDIなんてものはオマエさんには不要だ。
こんなところでつまらない連中を相手にしてるのは勿体無いと思う。
しかしな、オマエさんが周囲の奴を見て使えねえ連中ばっかりだと思うなら
DIはひょっとするとオマエさんを楽にさせてくれるかも知れないよ。
なあ>>135よ、オマエさんのはオマエさん並みに出来る奴ばっかりか？
ところでな、オマエさんのその考えとかを同僚とかはすぐに理解してくれるかい？
もしそうなら恵まれた職場にいるし、だったらDIなんてものはオマエさんには不要だ。
こんなところでつまらない連中を相手にしてるのは勿体無いと思う。
しかしな、オマエさんが周囲の奴を見て使えねえ連中ばっかりだと思うなら
DIはひょっとするとオマエさんを楽にさせてくれるかも知れないよ。
なあ>>135よ、オマエさんのはオマエさん並みに出来る奴ばっかりか？
143 ：デフォルトの名無しさん：04/11/11 21:12:49
144 ：デフォルトの名無しさん：04/11/11 21:20:41
DBを使用しないWEBアプリでDIコンテナを使うメリットってありますか？
自宅PCにWEBブラウザでアクセスして、２ちゃんブラウザのログを更新したり
閲覧したりしたいだけなんだけど・・・・・・・
こういう用途でも使えるものなんでしょうか？＞DIコンテナ
自宅PCにWEBブラウザでアクセスして、２ちゃんブラウザのログを更新したり
閲覧したりしたいだけなんだけど・・・・・・・
こういう用途でも使えるものなんでしょうか？＞DIコンテナ
145 ：デフォルトの名無しさん：04/11/11 21:43:45
単機能のアプリケーションだとあまりメリット感じれないかもね。
自分なら、とりあえずDIコンテナ使うけど。すでにある程度慣れてるから。
自分なら、とりあえずDIコンテナ使うけど。すでにある程度慣れてるから。
146 ：デフォルトの名無しさん：04/11/11 22:08:44
自分なら、とりあえずEJB使うけど。すでにある程度慣れてるから。
147 ：デフォルトの名無しさん：04/11/11 22:11:58
>>144
その程度だたらperlとかrubyとかの出番じゃない？
その程度だたらperlとかrubyとかの出番じゃない？
148 ：デフォルトの名無しさん：04/11/11 22:17:12
>>144
そのアプリってログはどうするのかな。自分で保持しつづけるの？
もしそうなら、仮にDBを使わなくてもストレージ管理が必要になるよね。
テキストファイルなんかでもさ。それがちょうどORMツールみたいな
位置付けになるから、DIは有効だよ。
テキストファイル管理コンポーネントを自作するとしてもPOJOで済むしね。
でももしログを持ちつづけるならDBを使ったほうが楽だと思うよ。
インストールが面倒ならPure JavaのDBでもいいんじゃないかな。
もし単なる串を作りたいならどうだろうね。漏れならDI使うと思うけど
もっと別の方法でもいいかも知れないね。串を作ったことがないから
よくわからない。ごめん。
>>146はすごいね。尊敬するよ。
そのアプリってログはどうするのかな。自分で保持しつづけるの？
もしそうなら、仮にDBを使わなくてもストレージ管理が必要になるよね。
テキストファイルなんかでもさ。それがちょうどORMツールみたいな
位置付けになるから、DIは有効だよ。
テキストファイル管理コンポーネントを自作するとしてもPOJOで済むしね。
でももしログを持ちつづけるならDBを使ったほうが楽だと思うよ。
インストールが面倒ならPure JavaのDBでもいいんじゃないかな。
もし単なる串を作りたいならどうだろうね。漏れならDI使うと思うけど
もっと別の方法でもいいかも知れないね。串を作ったことがないから
よくわからない。ごめん。
>>146はすごいね。尊敬するよ。
149 ：デフォルトの名無しさん：04/11/11 22:18:12
150 ：デフォルトの名無しさん：04/11/11 22:42:52
>>142
> 出来る奴ばっかりか？
うるせー。漏れが出来ようが出来まいが回りがどうだろうが
DIは何の解決にもならないだろう。当たり前の話だ。
繰り返すが、DIに依存するアプリを作るのはリスクです。
依存は少ないほうがよい。使うライブラリは必要最小限のほうがいいでしょ？
> 出来る奴ばっかりか？
うるせー。漏れが出来ようが出来まいが回りがどうだろうが
DIは何の解決にもならないだろう。当たり前の話だ。
繰り返すが、DIに依存するアプリを作るのはリスクです。
依存は少ないほうがよい。使うライブラリは必要最小限のほうがいいでしょ？
151 ：デフォルトの名無しさん：04/11/11 22:43:01
>>149
俺は>>136と同じく
> DIコンテナは周辺ライブラリあってナンボだと思ってて、
と思っているので、PerlやRubyのDIはまだまだこれからの段階だと思う。
ttp://ruby.jamisbuck.org/rails-injected.html
あと、DIに関する文章はコンテナそのものの使い方を紹介してあるものが多いが
S2Struts(Spring+StrutsでもNanoWar Strutsでもお好きに)とかのことを紹介した方が
DIの魅力を感じとりやすいと思う。
俺は>>136と同じく
> DIコンテナは周辺ライブラリあってナンボだと思ってて、
と思っているので、PerlやRubyのDIはまだまだこれからの段階だと思う。
ttp://ruby.jamisbuck.org/rails-injected.html
あと、DIに関する文章はコンテナそのものの使い方を紹介してあるものが多いが
S2Struts(Spring+StrutsでもNanoWar Strutsでもお好きに)とかのことを紹介した方が
DIの魅力を感じとりやすいと思う。
152 ：デフォルトの名無しさん：04/11/11 22:46:03
>>150
この俺様がクマー
この俺様がクマー
153 ：デフォルトの名無しさん：04/11/11 22:54:13
154 ：デフォルトの名無しさん：04/11/11 22:54:53
>>150
よくわからんな。藻舞は言語標準のAPIしか使っちゃ駄目だと
いいたいわけか？ Jakarta-commonsも使わないか？
そもそも開発者の腕に依存するのとツールに依存するのでは
前者のほうがリスクが高いと思うんだがどうよ。
藻舞の腕に依存するほうが恐いんだよ。なまじ優秀であるほどな。
代わりがきかんだろうが。
よくわからんな。藻舞は言語標準のAPIしか使っちゃ駄目だと
いいたいわけか？ Jakarta-commonsも使わないか？
そもそも開発者の腕に依存するのとツールに依存するのでは
前者のほうがリスクが高いと思うんだがどうよ。
藻舞の腕に依存するほうが恐いんだよ。なまじ優秀であるほどな。
代わりがきかんだろうが。
155 ：デフォルトの名無しさん：04/11/11 22:55:20
∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ > DIに依存するアプリを作るのはリスクです。
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
156 ：デフォルトの名無しさん：04/11/11 23:04:17
DI使っててもこちらからコンテナのクラスを直接利用しなければ大丈夫でしょ。
157 ：デフォルトの名無しさん：04/11/11 23:06:38
なあ>>150さんよ、気に障ったなら悪かった。でもなあ、
＞DIは何の解決にもならないだろう。当たり前の話だ。
というけど本当かなあ。何かは解決してるんじゃないかい？
EJBだって今でこそ大袈裟とか言われているけどさ、
透過的なトランザクションとかとても大きなテーマを
解決したからここまできたんだと思うんだよ。
DIも何かを解決してくれるんじゃないのかなあ。
>>150さんよ、オマエさんから見るとDIってのは
本当にまったく何もないものなのかなあ。
＞DIは何の解決にもならないだろう。当たり前の話だ。
というけど本当かなあ。何かは解決してるんじゃないかい？
EJBだって今でこそ大袈裟とか言われているけどさ、
透過的なトランザクションとかとても大きなテーマを
解決したからここまできたんだと思うんだよ。
DIも何かを解決してくれるんじゃないのかなあ。
>>150さんよ、オマエさんから見るとDIってのは
本当にまったく何もないものなのかなあ。
158 ：デフォルトの名無しさん：04/11/11 23:37:28
>>147
最初はCGIで書いてたんですが、自宅PC－出先間の暗号化とか、２ちゃんブラウザに近い機能の
追加(透明あぼ～んとかログ検索とか)を考えると、このままCGIとして書いていっていいのかな？と
もっと上手い方法があるんじゃないかと巡回してたら、ここをみつけたという次第です。
>>148
自宅PCではOpenJaneDoe(２ちゃんブラウザ)を使ってるんですが、これを会社に持ち込む事はで
きないんで、会社ではWEBブラウザを使って２ちゃんを読んでます。
でも、これだと会社で読んだ内容が２ちゃんブラウザのログには反映されず、非常に不便です。
そこで、これをどうにかできないかな？というのが出発点なんで、ログは２ちゃんブラウザのログそ
のもの(２ちゃんブラウザから読めないと意味がないので)をガリガリ更新する予定です。
とりあえず、この様な用途にも使う事はできる、そしてメリットも(大小の違いはある様だけれど)ある
という感触を得たんで頑張ってみます。
最初はCGIで書いてたんですが、自宅PC－出先間の暗号化とか、２ちゃんブラウザに近い機能の
追加(透明あぼ～んとかログ検索とか)を考えると、このままCGIとして書いていっていいのかな？と
もっと上手い方法があるんじゃないかと巡回してたら、ここをみつけたという次第です。
>>148
自宅PCではOpenJaneDoe(２ちゃんブラウザ)を使ってるんですが、これを会社に持ち込む事はで
きないんで、会社ではWEBブラウザを使って２ちゃんを読んでます。
でも、これだと会社で読んだ内容が２ちゃんブラウザのログには反映されず、非常に不便です。
そこで、これをどうにかできないかな？というのが出発点なんで、ログは２ちゃんブラウザのログそ
のもの(２ちゃんブラウザから読めないと意味がないので)をガリガリ更新する予定です。
とりあえず、この様な用途にも使う事はできる、そしてメリットも(大小の違いはある様だけれど)ある
という感触を得たんで頑張ってみます。
159 ：デフォルトの名無しさん：04/11/11 23:50:54
160 ：デフォルトの名無しさん：04/11/11 23:56:56
DIコンテナの周辺ライブラリに依存することに危惧を持ってるみたいだね。
たしかに、S2DaoとかS2JSFとかSpringMVCとか、大がかりなものだとそういう危惧はあるかもしれんけど。
HibernateとかStrutsとかの対応だと+αだし、そもそものHibernateやStrutsへの依存度が減るから、問題ないと思うんだけどね。
DIだけだと、依存度もなにも、単なるクラス作るだけだからあまり問題ないし。
たしかに、S2DaoとかS2JSFとかSpringMVCとか、大がかりなものだとそういう危惧はあるかもしれんけど。
HibernateとかStrutsとかの対応だと+αだし、そもそものHibernateやStrutsへの依存度が減るから、問題ないと思うんだけどね。
DIだけだと、依存度もなにも、単なるクラス作るだけだからあまり問題ないし。
161 ：デフォルトの名無しさん：04/11/11 23:57:46
>>158
会社が2chを読んじゃいけないと決めてるんだから、抜け道作って読むのはやめなされ。
会社が2chを読んじゃいけないと決めてるんだから、抜け道作って読むのはやめなされ。
162 ：デフォルトの名無しさん：04/11/12 00:31:44
163 ：デフォルトの名無しさん：04/11/12 01:00:38
しかし、そこまでして会社から2chをみるかと・・・
164 ：デフォルトの名無しさん：04/11/12 01:15:07
このスレは一見盛り上がってるように見えるが、
厨が暴れる+まともな人間が折伏するという構図で
レスがついているだけだ。
厨が暴れる+まともな人間が折伏するという構図で
レスがついているだけだ。
165 ：デフォルトの名無しさん：04/11/12 01:18:40
>>164
2chだからね。
2chだからね。
166 ：デフォルトの名無しさん：04/11/12 01:21:12
>>150
そんなに既存のDIコンテナに依存するのが嫌だったら、
自分で作ればいい。
setter injectionだけサポートするような簡単なやつだったら
数日で作れるよ。
# 作れないくらいスキルが低いんだったらこのスレにもう来るな。
AOPとか、このスレの上のほうに出てた副次的なメリットは
享受できなけどね。
そんなに既存のDIコンテナに依存するのが嫌だったら、
自分で作ればいい。
setter injectionだけサポートするような簡単なやつだったら
数日で作れるよ。
# 作れないくらいスキルが低いんだったらこのスレにもう来るな。
AOPとか、このスレの上のほうに出てた副次的なメリットは
享受できなけどね。
167 ：デフォルトの名無しさん：04/11/12 01:22:40
そういうのを盛り上がってるというんだよ。
まともな議論やら正確な情報で淡々と流れるスレなんて盛り上がってるって言わない。
まともな議論やら正確な情報で淡々と流れるスレなんて盛り上がってるって言わない。
168 ：デフォルトの名無しさん：04/11/12 01:31:54
169 ：デフォルトの名無しさん：04/11/12 01:35:57
170 ：デフォルトの名無しさん：04/11/12 01:43:26
スレと関係ないんだけどさ、俺「釣り」とか「釣り師」っていうのは、
釣り師 ↓ .
／| ←竿
○ ／ |
. （Vヽ／ |
＜＞ |
ﾞ'ﾞ":"''"''':'';;':,':;.:.,.,＿_|＿＿＿＿＿＿＿＿＿
|
餌（疑似餌）→.§ >ﾟ++< ～
の組み合わせだと思ってたんだけど、
最近自称釣り師がダイレクトで自分の本音を攻撃されて「釣れた！」とか
言ってるの多いよね。
これは、どっちかというと、
,～～～～～～ 、
|＼ （ 釣れたよ～・・・）
| ＼ ｀～～～v～～～´
し ＼
ﾞ'ﾞ":"''"''':'';;':,':;.:.,., ヽ○ノ
~~~~~|~~~~~~~￣￣￣￣￣￣￣
ト>ﾟ++<
ノ）
かと思うんだけど、どうよ？
釣り師 ↓ .
／| ←竿
○ ／ |
. （Vヽ／ |
＜＞ |
ﾞ'ﾞ":"''"''':'';;':,':;.:.,.,＿_|＿＿＿＿＿＿＿＿＿
|
餌（疑似餌）→.§ >ﾟ++< ～
の組み合わせだと思ってたんだけど、
最近自称釣り師がダイレクトで自分の本音を攻撃されて「釣れた！」とか
言ってるの多いよね。
これは、どっちかというと、
,～～～～～～ 、
|＼ （ 釣れたよ～・・・）
| ＼ ｀～～～v～～～´
し ＼
ﾞ'ﾞ":"''"''':'';;':,':;.:.,., ヽ○ノ
~~~~~|~~~~~~~￣￣￣￣￣￣￣
ト>ﾟ++<
ノ）
かと思うんだけど、どうよ？
171 ：デフォルトの名無しさん：04/11/12 01:45:49
>>170
,～～～～～～ 、
|＼ （ 釣れたよ～・・・）
| ＼ ｀～～～v～～～´
し ＼
ﾞ'ﾞ":"''"''':'';;':,':;.:.,., ヽ○ノ
~~~~~|~~~~~~~￣￣￣￣￣￣￣
ト>ﾟ++<
ノ） ←>>150
,～～～～～～ 、
|＼ （ 釣れたよ～・・・）
| ＼ ｀～～～v～～～´
し ＼
ﾞ'ﾞ":"''"''':'';;':,':;.:.,., ヽ○ノ
~~~~~|~~~~~~~￣￣￣￣￣￣￣
ト>ﾟ++<
ノ） ←>>150
172 ：デフォルトの名無しさん：04/11/12 02:43:23
クラス図で書いてくれ
173 ：デフォルトの名無しさん：04/11/12 04:53:49
___________________
|<<interface>>|
| ネタ |
￣￣↑￣￣￣
________|_____________ ____________
|釣りラー >>150|◇--|釣りリー|
￣￣￣￣￣￣￣ ￣￣￣￣
|<<interface>>|
| ネタ |
￣￣↑￣￣￣
________|_____________ ____________
|釣りラー >>150|◇--|釣りリー|
￣￣￣￣￣￣￣ ￣￣￣￣
174 ：デフォルトの名無しさん：04/11/13 03:24:09
175 ：デフォルトの名無しさん：04/11/13 04:24:57
176 ：デフォルトの名無しさん：04/11/13 09:14:33
>>175
そんなこというと何もいえなくなってしまうではないか。窒息死する。
DIは普通にOOPするのと何が違うのかってところで、
何も使わないのと何も変わらない。変わらないなら使わないほうがいい、っていう
この考えの人を納得させる意見と、自己満足のdiブロガーには物凄い開きがあるわけ。
納得させるためにはどうするか。
もうね、ネット上でどうこうやってもダメよ。実社会でdiについて話して、diでビジネスをやる。
これしかない。
そんなこというと何もいえなくなってしまうではないか。窒息死する。
DIは普通にOOPするのと何が違うのかってところで、
何も使わないのと何も変わらない。変わらないなら使わないほうがいい、っていう
この考えの人を納得させる意見と、自己満足のdiブロガーには物凄い開きがあるわけ。
納得させるためにはどうするか。
もうね、ネット上でどうこうやってもダメよ。実社会でdiについて話して、diでビジネスをやる。
これしかない。
いや、まぁ漏れはdiは嫌いで普通のOOPで仕事するけど。
178 ：デフォルトの名無しさん：04/11/13 09:42:47
DIを推す人達のマインドは「OOPしたい」よりも「COPしたい」にあるのだと思う。
179 ：デフォルトの名無しさん：04/11/13 09:45:09
>>174
Fowlerマンセー君かな。とりあえずDIコンテナのコード読みなよ。
>>175
2chだからしかたない。会社でダメなやつと言われてる連中のｽｸﾂ。
>>176
DIで仕事してますが何か？
>>177
何だ単なるアンチか。
Fowlerマンセー君かな。とりあえずDIコンテナのコード読みなよ。
>>175
2chだからしかたない。会社でダメなやつと言われてる連中のｽｸﾂ。
>>176
DIで仕事してますが何か？
>>177
何だ単なるアンチか。
180 ：デフォルトの名無しさん：04/11/13 10:01:30
181 ：デフォルトの名無しさん：04/11/13 10:33:02
結論としては、やっぱ構造化プログラミングが一番だね。でFA?
182 ：デフォルトの名無しさん：04/11/13 12:19:21
>>121
> Eclipseのプラグインは見事だと思うけど業務アプリには
> それこそ手間の割にメリットがないと思う。
これが無いならそもそもなんでわざわざdiを導入しなきゃならないのか
コンポーネント化するってことは取り外しが簡単だからだろ？
それをしたなくなきゃプログラミング言語の機能を使って普通にＯＯＰするのだ。
> Eclipseのプラグインは見事だと思うけど業務アプリには
> それこそ手間の割にメリットがないと思う。
これが無いならそもそもなんでわざわざdiを導入しなきゃならないのか
コンポーネント化するってことは取り外しが簡単だからだろ？
それをしたなくなきゃプログラミング言語の機能を使って普通にＯＯＰするのだ。
183 ：デフォルトの名無しさん：04/11/13 12:39:37
>>182
Eclipseだとプラグイン横断的な機能はどうやって作るの？
Eclipseだとプラグイン横断的な機能はどうやって作るの？
184 ：デフォルトの名無しさん：04/11/13 12:46:53
AspectJ
185 ：デフォルトの名無しさん：04/11/13 12:48:15
>>182
Eclipseプラグインで業務アプリ作るのとDI使って業務アプリ作るのとだとどっちが
簡単かってことじゃないのかな。
>>182はEclipseプラグインを作れるからそっちのほうが簡単だっていうんだろうけど
普通はプラグインなんて使うだけのﾔｼのほうが圧倒的に多いよね。
でもそんな奴でも業務アプリの開発はしないといけないわけだ。そこで別の仕組みが欲しいんだが
その有力候補としてDIが注目されてるだけだよ。
>>182の作ったプラグインとか見せて欲しいな。何かすごく勉強になりそうだから。
皮肉じゃなくてすごく実力あるんだろうなと思う。
Eclipseプラグインで業務アプリ作るのとDI使って業務アプリ作るのとだとどっちが
簡単かってことじゃないのかな。
>>182はEclipseプラグインを作れるからそっちのほうが簡単だっていうんだろうけど
普通はプラグインなんて使うだけのﾔｼのほうが圧倒的に多いよね。
でもそんな奴でも業務アプリの開発はしないといけないわけだ。そこで別の仕組みが欲しいんだが
その有力候補としてDIが注目されてるだけだよ。
>>182の作ったプラグインとか見せて欲しいな。何かすごく勉強になりそうだから。
皮肉じゃなくてすごく実力あるんだろうなと思う。
186 ：デフォルトの名無しさん：04/11/13 12:50:58
eclipseプラグインはスレ違い。
187 ：デフォルトの名無しさん：04/11/13 13:02:58
1. ソースコードへの修正を加えずに実装を切り替えることができる。
2. (修正なしで)下位レイヤの実装を必要とせずに単体テストを通せる。
3. Mockを使った下位レイヤの異常をシミュレートしやすくなる。
DIで嬉しいのってこんなもんでしょ？
確かにDBやコンテナを使わずに単体テストが実施できるのは嬉しいけど
それってMockの功績だし。
2. (修正なしで)下位レイヤの実装を必要とせずに単体テストを通せる。
3. Mockを使った下位レイヤの異常をシミュレートしやすくなる。
DIで嬉しいのってこんなもんでしょ？
確かにDBやコンテナを使わずに単体テストが実施できるのは嬉しいけど
それってMockの功績だし。
188 ：デフォルトの名無しさん：04/11/13 13:05:28
>>185
>別の仕組み
「仕組み」とは何なのか
モジュール化、依存性を少なくして簡潔なシステムにするための仕組みであるなら、
それは普通にＯＯＰするのと何が違うのか。
そこがどうにも弱いんだな。
ソフトウェアをパーツ化して取り外し可能にすることが目的、そういう仕組みが欲しいなら、
アプリケーション側でその拡張方法を定義するのが礼儀だと思う。
だからそういう機能がお好みなら、そのときはEclipseを見習おう。
>別の仕組み
「仕組み」とは何なのか
モジュール化、依存性を少なくして簡潔なシステムにするための仕組みであるなら、
それは普通にＯＯＰするのと何が違うのか。
そこがどうにも弱いんだな。
ソフトウェアをパーツ化して取り外し可能にすることが目的、そういう仕組みが欲しいなら、
アプリケーション側でその拡張方法を定義するのが礼儀だと思う。
だからそういう機能がお好みなら、そのときはEclipseを見習おう。
189 ：デフォルトの名無しさん：04/11/13 14:11:07
なんでプラグインアーキテクチャを持ち出してDIコンテナに反論
した気になってるのかね。支離滅裂。
むしろDIコンテナはプラグインアーキテクチャを推進するものだと
思うんだが。
とりあえず↓でも読んどけ。
ttp://blog.goo.ne.jp/ikkoan/e/bfe6fda9790199a2b0c15dbbb6c3ea24
ttp://blog.goo.ne.jp/ikkoan/e/8cb0ff2efb68831771f3b3c4b47728a0
> 1. ゴールを実行するプラグインが既にロードされているかチェックする
>
> 2. ロードされていなかった場合、ローカルのリポジトリにプラグインの
> jarがあるかチェックする
>
> 3. ローカルのリポジトリにプラグインのJarが無い場合、
> リモートリポジトリからダウンロードする
>
> 4. プラグイン用に新しいClassWorldsのClassRealmを作って、
> プラグイン自体のjarと依存するjarを追加する
> それはともかく、面白いのは上記手順のうち2, 3, 4はMaven2自体でなく
> Maven2が採用しているコンテナであるplexusがやってくれているという
> ことです。Mavenは「このプラグインはまだロードしてないから適当に
> ロードしといてね」とお願いするだけで、その後の面倒な
> 処理は全部plexusが引き受けてくれます。
した気になってるのかね。支離滅裂。
むしろDIコンテナはプラグインアーキテクチャを推進するものだと
思うんだが。
とりあえず↓でも読んどけ。
ttp://blog.goo.ne.jp/ikkoan/e/bfe6fda9790199a2b0c15dbbb6c3ea24
ttp://blog.goo.ne.jp/ikkoan/e/8cb0ff2efb68831771f3b3c4b47728a0
> 1. ゴールを実行するプラグインが既にロードされているかチェックする
>
> 2. ロードされていなかった場合、ローカルのリポジトリにプラグインの
> jarがあるかチェックする
>
> 3. ローカルのリポジトリにプラグインのJarが無い場合、
> リモートリポジトリからダウンロードする
>
> 4. プラグイン用に新しいClassWorldsのClassRealmを作って、
> プラグイン自体のjarと依存するjarを追加する
> それはともかく、面白いのは上記手順のうち2, 3, 4はMaven2自体でなく
> Maven2が採用しているコンテナであるplexusがやってくれているという
> ことです。Mavenは「このプラグインはまだロードしてないから適当に
> ロードしといてね」とお願いするだけで、その後の面倒な
> 処理は全部plexusが引き受けてくれます。
190 ：デフォルトの名無しさん：04/11/13 14:24:37
Eclipseのプラグインてそれだけでひとつの製品レベルの大きさだやなと思ったりする。
漏れは頭が悪いからやっぱりプラグインにはSOAだよとでも逝ってみる。
漏れは頭が悪いからやっぱりプラグインにはSOAだよとでも逝ってみる。
191 ：デフォルトの名無しさん：04/11/13 14:25:22
コピペうざい。
192 ：デフォルトの名無しさん：04/11/13 17:16:23
>なんでプラグインアーキテクチャを持ち出してDIコンテナに反論
>した気になってるのかね。
そういうところがdiのメリットだと思う人がいそうだったから。
コンポーネント化がメリットだって言うんでしょ？
それをやるにもdiは中途半端でＯＯＰやるのと大差ないってことを言いたかった。
そのblog読んだけど、もしJavaでサーバサイド業務アプリが作りたくて
プラグイン機構欲しい場合は、plexusはイイかもしれませんな。
（詳細は知らんので断言できないけど。）
>した気になってるのかね。
そういうところがdiのメリットだと思う人がいそうだったから。
コンポーネント化がメリットだって言うんでしょ？
それをやるにもdiは中途半端でＯＯＰやるのと大差ないってことを言いたかった。
そのblog読んだけど、もしJavaでサーバサイド業務アプリが作りたくて
プラグイン機構欲しい場合は、plexusはイイかもしれませんな。
（詳細は知らんので断言できないけど。）
193 ：デフォルトの名無しさん：04/11/13 17:20:35
> 1. ソースコードへの修正を加えずに実装を切り替えることができる。
これだが、いい加減、XML自体がソースコードだということに気づけ。
XMLはコンパイルが不要とか言うなら最初からスクリプト言語使えばいい。
これだが、いい加減、XML自体がソースコードだということに気づけ。
XMLはコンパイルが不要とか言うなら最初からスクリプト言語使えばいい。
194 ：デフォルトの名無しさん：04/11/13 17:33:01
つまり、文意をくみとらず、言葉尻だけを捕らえていると、こういう反論ができる、ということですね。
195 ：デフォルトの名無しさん：04/11/13 17:54:43
>>194の文章がヘタレなだけな罠
196 ：デフォルトの名無しさん：04/11/13 17:55:39
> XML自体がソースコード
それはその通り
実装の切り替えをjavaコードからXMLに移しているだけの話。
なんでもかんでも仕様と実装に分けてしまうのは可読性を落とすだけだが
適切な箇所で使うのなら、なんら問題ないかと
それはその通り
実装の切り替えをjavaコードからXMLに移しているだけの話。
なんでもかんでも仕様と実装に分けてしまうのは可読性を落とすだけだが
適切な箇所で使うのなら、なんら問題ないかと
197 ：デフォルトの名無しさん：04/11/13 17:57:24
文章に関してはみんなヘタレのような希ガス
198 ：デフォルトの名無しさん：04/11/13 18:28:42
スクリプト言語だって、ちょっと規模が大きくなれば
設定として切り出せる部分はどんどん外に追い出すもんだと思ってるんだが、
193氏はなんでもかんでもソースに書きたい人なの？
設定として切り出せる部分はどんどん外に追い出すもんだと思ってるんだが、
193氏はなんでもかんでもソースに書きたい人なの？
199 ：デフォルトの名無しさん：04/11/13 18:37:57
ソース厨ﾊｹｰｿ
200 ：デフォルトの名無しさん：04/11/13 18:53:19
201 ：デフォルトの名無しさん：04/11/13 18:58:52
Groovyなんて使い物になるのだろうか？
202 ：デフォルトの名無しさん：04/11/13 19:02:39
いや、単なる初期化用スクリプトだから。XMLじゃなくてGroovyで初期化コードを書くためのもの。
何らかの理由で、ループやら条件分岐やらの制御構造を使いたいとき用。
何らかの理由で、ループやら条件分岐やらの制御構造を使いたいとき用。
203 ：デフォルトの名無しさん：04/11/13 19:16:33
Groovyが使い物にならない理由はなんだろうか?
実行効率? 保守性? 仕様・実装が安定でないから?
実行効率? 保守性? 仕様・実装が安定でないから?
204 ：デフォルトの名無しさん：04/11/13 20:19:58
遅杉。一度使ってみると判る。
205 ：デフォルトの名無しさん：04/11/13 20:43:36
>>203
初期化用スクリプトに使う範囲では遅いことはあまり問題にならないと思うが、
仕様・実装が安定でない段階で開発が実質上止っているのが困る。
CVSリポジトリのgroovy-coreにもう一ヶ月も何もコミットされてないじゃん。
最も後発のスクリプト言語なのに最も開発がアクティブではない状況で、将来性を感じろと
言われても厳しい。
jstrachanの関心がActiveなんちゃらからGroovyに戻ってきたら、その時は考え直す。
初期化用スクリプトに使う範囲では遅いことはあまり問題にならないと思うが、
仕様・実装が安定でない段階で開発が実質上止っているのが困る。
CVSリポジトリのgroovy-coreにもう一ヶ月も何もコミットされてないじゃん。
最も後発のスクリプト言語なのに最も開発がアクティブではない状況で、将来性を感じろと
言われても厳しい。
jstrachanの関心がActiveなんちゃらからGroovyに戻ってきたら、その時は考え直す。
206 ：デフォルトの名無しさん：04/11/13 21:04:39
>>202
制御構造使いたいときって、あるものなの？
制御構造使いたいときって、あるものなの？
207 ：デフォルトの名無しさん：04/11/13 21:26:25
>>192
plexusが良くて他のDIコンテナだと何がいかんのか？
plexusが良くて他のDIコンテナだと何がいかんのか？
208 ：デフォルトの名無しさん：04/11/13 23:01:10
>> 198
> 設定として切り出せる部分はどんどん外に追い出すもんだと思ってるんだが、
切り出し可能な部分はっていう意味か？
仕組みさえ用意すれば、現在の依存性注入に加え、繰り返し条件、条件分岐、
フィールドの型まで設定ファイルに追い出せる。実現できれば、ほとんどの
問題は解決じゃないか。
198 氏はなんでも XML に書きたい人なの？
> 設定として切り出せる部分はどんどん外に追い出すもんだと思ってるんだが、
切り出し可能な部分はっていう意味か？
仕組みさえ用意すれば、現在の依存性注入に加え、繰り返し条件、条件分岐、
フィールドの型まで設定ファイルに追い出せる。実現できれば、ほとんどの
問題は解決じゃないか。
198 氏はなんでも XML に書きたい人なの？
209 ：デフォルトの名無しさん：04/11/13 23:28:09
>208
有意なレベルであればなんでもかんでも外出ししたいですよ。
ただ208さんの考えるレベルまで外出しする気は当然ないです。
それをするとXMLファイルそのものがスクリプトに変化して、
開発も保守もしんどくなるだけの話。
つか、なんで極論にばかり持って行こうとするのかが分かりません。
DI意識すると各モジュールの担当する機能の範囲が明確になって
設計する人も製造する人も作業分担がはっきりして、
一人当たりの覚えなきゃいけないことも減って、
みんな幸せになってそれでいいじゃんって感じですが。
俺は最終的に楽をしたいだけです。
有意なレベルであればなんでもかんでも外出ししたいですよ。
ただ208さんの考えるレベルまで外出しする気は当然ないです。
それをするとXMLファイルそのものがスクリプトに変化して、
開発も保守もしんどくなるだけの話。
つか、なんで極論にばかり持って行こうとするのかが分かりません。
DI意識すると各モジュールの担当する機能の範囲が明確になって
設計する人も製造する人も作業分担がはっきりして、
一人当たりの覚えなきゃいけないことも減って、
みんな幸せになってそれでいいじゃんって感じですが。
俺は最終的に楽をしたいだけです。
210 ：デフォルトの名無しさん：04/11/13 23:32:16
あと208氏の挙げた例を満たす場合は、
システム全体の設定ファイルで
ロジッククラスを切り替え可能なようにして、
あとは当該ロジッククラスが
自身専用の設定ファイルを読み込むことで対応するのでは。
汎用の設定ファイル一つで解決する必要なんてどこにもないし。
システム全体の設定ファイルで
ロジッククラスを切り替え可能なようにして、
あとは当該ロジッククラスが
自身専用の設定ファイルを読み込むことで対応するのでは。
汎用の設定ファイル一つで解決する必要なんてどこにもないし。
211 ：デフォルトの名無しさん：04/11/14 09:56:37
> 有意なレベルであればなんでもかんでも外出ししたい
どこまで外だしって、まぁ、ケースバイケースんだよね。
シンプルにするには、中で解決したほうがいい場合もあるだろうし。いうまでもなく。
> 設計する人も製造する人も作業分担がはっきりして、
> 一人当たりの覚えなきゃいけないことも減って
使おうが使うまいが同じだよ
分担もなにも、皆で同じ苦労をするのがソフトウェア開発なのだ。
どこまで外だしって、まぁ、ケースバイケースんだよね。
シンプルにするには、中で解決したほうがいい場合もあるだろうし。いうまでもなく。
> 設計する人も製造する人も作業分担がはっきりして、
> 一人当たりの覚えなきゃいけないことも減って
使おうが使うまいが同じだよ
分担もなにも、皆で同じ苦労をするのがソフトウェア開発なのだ。
212 ：デフォルトの名無しさん：04/11/14 12:23:19
>>211
> > 設計する人も製造する人も作業分担がはっきりして、
> > 一人当たりの覚えなきゃいけないことも減って
>
> 使おうが使うまいが同じだよ
> 分担もなにも、皆で同じ苦労をするのがソフトウェア開発なのだ。
「アジャイルと規律」でも読んで出直して来い。
> > 設計する人も製造する人も作業分担がはっきりして、
> > 一人当たりの覚えなきゃいけないことも減って
>
> 使おうが使うまいが同じだよ
> 分担もなにも、皆で同じ苦労をするのがソフトウェア開発なのだ。
「アジャイルと規律」でも読んで出直して来い。
213 ：デフォルトの名無しさん：04/11/14 13:05:47
>>212
内容は悪くないな。だが、色々なプロセスや手法を解説しているものの、著者らが実際に
どこまで理解できているかがはなはだ疑問の解説がある。
例えば CMM の部分はかなり間違った解釈（要件が安定していないと適用は難しいとか
重量で融通が利かない風な解説）が多い上に、実際にあまり著者らが実戦経験がないと
ハッキリ分かってしまう部分がある。著者の一人はビッグネームで、もう一人は CMMI の
策定メンバーとあるが、名前や肩書きを鵜呑みにするのは危険だな。
お前のように。
内容は悪くないな。だが、色々なプロセスや手法を解説しているものの、著者らが実際に
どこまで理解できているかがはなはだ疑問の解説がある。
例えば CMM の部分はかなり間違った解釈（要件が安定していないと適用は難しいとか
重量で融通が利かない風な解説）が多い上に、実際にあまり著者らが実戦経験がないと
ハッキリ分かってしまう部分がある。著者の一人はビッグネームで、もう一人は CMMI の
策定メンバーとあるが、名前や肩書きを鵜呑みにするのは危険だな。
お前のように。
214 ：デフォルトの名無しさん：04/11/14 13:39:28
>>213の元ネタ(Amazon書評)をコピペ。
> レビュアー： さすらいのスナフキン (プロフィールを見る) 九州福岡 Japan
> 本書の内容は悪くないと思います。しかし、色々なプロセスや手法を解説しているものの、
> 著者達自身が実際にどこまで理解できているかがはなはだ疑問の解説があることが残念。
> 特にCMMの部分はかなり間違った解釈（要件が安定していないと適用は難しいとか重量で
> 融通が利かない風な解説）が多い上に、実際にあまり著者自身が実戦経験がないと
> ハッキリ分かってしまう部分がある。著者の一人はビッグネームであり、もう一人は
> CMMIの策定メンバーとあるが、名前や肩書きを鵜呑みにするのは危険であるという
> 証明になるかもしれない。
> これからプロセスや手法及びプロジェクト管理を学ぼうと思う人は、
> あくまで１つの本として参考にすることが必要だ。
ほぼそのまんまだね。
悲惨な風景だ。
> レビュアー： さすらいのスナフキン (プロフィールを見る) 九州福岡 Japan
> 本書の内容は悪くないと思います。しかし、色々なプロセスや手法を解説しているものの、
> 著者達自身が実際にどこまで理解できているかがはなはだ疑問の解説があることが残念。
> 特にCMMの部分はかなり間違った解釈（要件が安定していないと適用は難しいとか重量で
> 融通が利かない風な解説）が多い上に、実際にあまり著者自身が実戦経験がないと
> ハッキリ分かってしまう部分がある。著者の一人はビッグネームであり、もう一人は
> CMMIの策定メンバーとあるが、名前や肩書きを鵜呑みにするのは危険であるという
> 証明になるかもしれない。
> これからプロセスや手法及びプロジェクト管理を学ぼうと思う人は、
> あくまで１つの本として参考にすることが必要だ。
ほぼそのまんまだね。
悲惨な風景だ。
215 ：デフォルトの名無しさん：04/11/14 14:01:56
>>213はスナフキン
216 ：デフォルトの名無しさん：04/11/14 14:06:01
さあ 盛
り
上
が
っ
て
参
り
ま
す
た
り
上
が
っ
て
参
り
ま
す
た
217 ：デフォルトの名無しさん：04/11/14 14:26:27
確か山本昌邦氏が言ってたんだけどさ。
最近のサッカーやってる大学生はバイタルエリアが何たらとか
やたら戦術的なことを聞きたがるんだが、実際にプレーさせて
みると基本中の基本インステップキックひとつまともに蹴れない
なんてケースが多いらしい。
以上、このスレの口先DIイラネー厨を見て思い出した話。
最近のサッカーやってる大学生はバイタルエリアが何たらとか
やたら戦術的なことを聞きたがるんだが、実際にプレーさせて
みると基本中の基本インステップキックひとつまともに蹴れない
なんてケースが多いらしい。
以上、このスレの口先DIイラネー厨を見て思い出した話。
218 ：デフォルトの名無しさん：04/11/14 14:34:06
S2とSpring、
どっちがいいの？
どっちがいいの？
219 ：デフォルトの名無しさん：04/11/14 14:51:01
220 ：デフォルトの名無しさん：04/11/14 15:33:08
>>182
> Eclipseのプラグインは見事だと思うけど業務アプリには
> それこそ手間の割にメリットがないと思う。
>
>これが無いならそもそもなんでわざわざdiを導入しなきゃならないのか
極論好きだな。
DIさえ使わないのは右すぎ。
Eclipseプラグイン的なのは左すぎ。
DIコンテナ使うのが中庸。
ってだけなんだけど。
当然コンテキストに依存するけどね。
漏れの場合は数人～数十人でWebアプリ作る場合を想定してる。
> Eclipseのプラグインは見事だと思うけど業務アプリには
> それこそ手間の割にメリットがないと思う。
>
>これが無いならそもそもなんでわざわざdiを導入しなきゃならないのか
極論好きだな。
DIさえ使わないのは右すぎ。
Eclipseプラグイン的なのは左すぎ。
DIコンテナ使うのが中庸。
ってだけなんだけど。
当然コンテキストに依存するけどね。
漏れの場合は数人～数十人でWebアプリ作る場合を想定してる。
221 ：デフォルトの名無しさん：04/11/14 16:51:30
パクリ>>213の謝罪まだー?
222 ：デフォルトの名無しさん：04/11/14 16:57:41
223 ：デフォルトの名無しさん：04/11/14 17:08:16
224 ：デフォルトの名無しさん：04/11/14 17:33:00
>>218
定義ファイルが強力でシンプルに書けるのはS2
国際的に普及しているのはSpring
S2のライブラリで気に入ったものがあって、足りないものがなければS2
JetSpeedとか、S2が対応してないもの使うならSpring
今後もしばらく、Hibernateなんかの各ライブラリはSpring対応しかしないことが多いと思うから、S2のほうはS2の中の人ががんばって対応する必要がある。
純粋に技術的なところで比べれば、S2の方が定義ファイルが書きやすくていいけど、実際問題、大差ない。
どっちでもいいから、やりやすそうなのを使えばいい。
定義ファイルが強力でシンプルに書けるのはS2
国際的に普及しているのはSpring
S2のライブラリで気に入ったものがあって、足りないものがなければS2
JetSpeedとか、S2が対応してないもの使うならSpring
今後もしばらく、Hibernateなんかの各ライブラリはSpring対応しかしないことが多いと思うから、S2のほうはS2の中の人ががんばって対応する必要がある。
純粋に技術的なところで比べれば、S2の方が定義ファイルが書きやすくていいけど、実際問題、大差ない。
どっちでもいいから、やりやすそうなのを使えばいい。
225 ：デフォルトの名無しさん：04/11/14 17:52:08
確か山本昌邦氏が言ってたんだけどさ。
最近のサッカーやってる大学生はバイタルエリアが何たらとか
やたら戦術的なことを聞きたがるんだが、実際にプレーさせて
みると基本中の基本インステップキックひとつまともに蹴れない
なんてケースが多いらしい。
以上、このスレの口先DIマンセー厨を見て思い出した話。
最近のサッカーやってる大学生はバイタルエリアが何たらとか
やたら戦術的なことを聞きたがるんだが、実際にプレーさせて
みると基本中の基本インステップキックひとつまともに蹴れない
なんてケースが多いらしい。
以上、このスレの口先DIマンセー厨を見て思い出した話。
226 ：デフォルトの名無しさん：04/11/14 18:02:17
こぴぺうざ
227 ：デフォルトの名無しさん：04/11/14 19:08:22
>224
俺も Spring の定義ファイルはどうにかならんもんかと思った。
けど現実に Spring の方が人気あるように見えたので
そっち採用になりますた。Ruby と Perl & Python もそうだけど
プロジェクトリーダーが日本語使うのやめて
英語圏向けのリリースを一義にせん限り
ジリ貧は免れないような気がします。
初めに Spring 使うこと決めてしまったので
S2 に関してはあまり調べてなかったり。
俺も Spring の定義ファイルはどうにかならんもんかと思った。
けど現実に Spring の方が人気あるように見えたので
そっち採用になりますた。Ruby と Perl & Python もそうだけど
プロジェクトリーダーが日本語使うのやめて
英語圏向けのリリースを一義にせん限り
ジリ貧は免れないような気がします。
初めに Spring 使うこと決めてしまったので
S2 に関してはあまり調べてなかったり。
228 ：デフォルトの名無しさん：04/11/14 19:21:29
229 ：デフォルトの名無しさん：04/11/14 19:22:31
現実的には、どこかでS2はSpringに歩み寄らないといけないんじゃないかと思う。
230 ：デフォルトの名無しさん：04/11/14 19:47:37
ということにしたいんですね？
231 ：デフォルトの名無しさん：04/11/14 20:08:42
誰かDIコンテナを使ったアプリケーション一つでも見せてくれないかしら。
そうでもしないと、それがDI使わなかった場合と比べてどうなのかわかんないし、
説明しようも無いと思う。
そうでもしないと、それがDI使わなかった場合と比べてどうなのかわかんないし、
説明しようも無いと思う。
232 ：デフォルトの名無しさん：04/11/14 20:57:35
めちゃくちゃ応用力のないやつだな・・・
233 ：デフォルトの名無しさん：04/11/14 21:01:07
DIコンテナをちょっとも使わずに言ってるのなら、話にならんからまず使えというしかないし、使っていってるのなら、もうどうしようもない。
234 ：デフォルトの名無しさん：04/11/14 21:11:07
（スレがどうでもよくなってきました）
235 ：デフォルトの名無しさん：04/11/14 21:26:07
AOP?
ああ、ログとコミット/ロールバックを埋め込むしか能が無い、
そのくせ名前だけはご立派なアレか。
ああ、ログとコミット/ロールバックを埋め込むしか能が無い、
そのくせ名前だけはご立派なアレか。
236 ：デフォルトの名無しさん：04/11/14 21:43:24
と、だれかが実装して動くようになったメソッドにログとトランザクションのコードを書き加えるくらいしか能がない>>235はいいました。
237 ：デフォルトの名無しさん：04/11/14 21:54:45
238 ：デフォルトの名無しさん：04/11/14 22:04:33
>>236はまずは改行を覚えようぜ。
239 ：デフォルトの名無しさん：04/11/14 22:29:20
色々と覚えることあるから大変だなあ…
240 ：デフォルトの名無しさん：04/11/14 22:37:23
文の途中で改行することとか・・・。
241 ：デフォルトの名無しさん：04/11/14 22:38:58
テレビに出てるオタク、キモい・・・
カラオケでアニメ熱唱とか、そのなかでチャットで会話するやつらとか。
カラオケでアニメ熱唱とか、そのなかでチャットで会話するやつらとか。
242 ：デフォルトの名無しさん：04/11/14 23:28:45
>>241
DIと関係あるのか？
DIと関係あるのか？
243 ：デフォルトの名無しさん：04/11/14 23:43:19
>>242
まー、しいて言えばｷﾓいとこかな。DI 廚と同じく。
まー、しいて言えばｷﾓいとこかな。DI 廚と同じく。
244 ：デフォルトの名無しさん：04/11/14 23:49:10
245 ：デフォルトの名無しさん：04/11/14 23:51:54
ここは隔離スレとして機能すればいいと思ったけど
うまくいってないみたいね
ｷﾁｶﾞｲの温床になってる
うまくいってないみたいね
ｷﾁｶﾞｲの温床になってる
246 ：デフォルトの名無しさん：04/11/14 23:53:54
アンチDI初心者君絶滅の日まであと少し
247 ：デフォルトの名無しさん：04/11/15 00:04:53
>>245
> ｷﾁｶﾞｲの温床になってる
こんな奴のことかな。
・DIコンテナ使ったことないらしい。
・それどころかJUnitすら使ってないらしい。
そのくせどこで聞きかじったのかそれとなくXPっぽいことを言う。
・脈絡もなくプラグインアーキテクチャを称揚する。
でも何がコアで何がプラグインなのか全く意味不明。
プラグインアーキテクチャのコストとTPOについても
全く考慮してない模様。
・反論されると論点を撹乱して逃げ、しばらくするとまた同じことを
言い出す。もしくは「みんなそうじゃん」と矛先の分散を試みる。
・Amazonの書評を語尾だけ変えてパクる。(w
・どうしようもなくなると教えて君に一時的に変身する。
同一人物な気がするんだが。
> ｷﾁｶﾞｲの温床になってる
こんな奴のことかな。
・DIコンテナ使ったことないらしい。
・それどころかJUnitすら使ってないらしい。
そのくせどこで聞きかじったのかそれとなくXPっぽいことを言う。
・脈絡もなくプラグインアーキテクチャを称揚する。
でも何がコアで何がプラグインなのか全く意味不明。
プラグインアーキテクチャのコストとTPOについても
全く考慮してない模様。
・反論されると論点を撹乱して逃げ、しばらくするとまた同じことを
言い出す。もしくは「みんなそうじゃん」と矛先の分散を試みる。
・Amazonの書評を語尾だけ変えてパクる。(w
・どうしようもなくなると教えて君に一時的に変身する。
同一人物な気がするんだが。
248 ：デフォルトの名無しさん：04/11/15 00:09:38
249 ：デフォルトの名無しさん：04/11/15 00:15:47
>>248どうした？
250 ：デフォルトの名無しさん：04/11/15 00:19:09
ファウラーたんも言ってる通り、ある程度の規模にならないとメリット見えないよ。
それまではServiceLocatorでいいんじゃね
それまではServiceLocatorでいいんじゃね
251 ：デフォルトの名無しさん：04/11/15 00:23:57
252 ：デフォルトの名無しさん：04/11/15 00:35:12
253 ：デフォルトの名無しさん：04/11/15 00:36:09
まだ「コンポーネントの再利用」なんて夢を見てる香具師がいるのか…。
254 ：デフォルトの名無しさん：04/11/15 00:40:23
255 ：デフォルトの名無しさん：04/11/15 00:47:12
>>254
以下の通り大いに関係があると書いてあるんだが。
意見を述べるのは自由だが、出典を偽装するのはやめろ。
> ところが、MovieLister が知らない人達の作るアプリケーション向け
> コンポーネントだとすると、話は違ってくる。私にはコンポーネント
> 利用者の使うであろう Service Locator の API はわからない。
> 利用者各々の間で互換性のない Service Locator を利用するかもしれない。
> こういった事態に対しては、隔離されたインタフェースを利用することで
> やり過ごすこともできるだろう。利用者たちがそれぞれ、私のインタフェースを
> 彼らのロケータに合わせるべくアダプタを書くこともできるけれど、
> どうしたって結局私は、自分の作成したインタフェースをルックアップする、
> 最初のロケータについては知る必要があるのだ。それに、アダプタが
> 使われはじめると「コンポーネントはロケータと直接つながっている」
> というシンプルさが失われてしまう。
>
> その点、Dependency Injection では、コンポーネントはコンテナに
> 依存しなくなる。だがしかし、一旦設定が完了してしまうと、
> それ以上のサービスをコンテナから取得できなくなってしまう。
> Dependency Injection は Service Locator の代替案として有効である。
> アプリケーションクラスを構築するにあたっては、両者ともだいたい
> 同じようなものだが、私は Service Locator のほうが少し優勢だと思う。
> こちらのほうが振る舞いが素直だからだ。しかしながら、構築したクラスが
> 複数のアプリケーションで利用されるのであれば、 Dependency Injection の
> ほうがより良い選択肢となる。
以下の通り大いに関係があると書いてあるんだが。
意見を述べるのは自由だが、出典を偽装するのはやめろ。
> ところが、MovieLister が知らない人達の作るアプリケーション向け
> コンポーネントだとすると、話は違ってくる。私にはコンポーネント
> 利用者の使うであろう Service Locator の API はわからない。
> 利用者各々の間で互換性のない Service Locator を利用するかもしれない。
> こういった事態に対しては、隔離されたインタフェースを利用することで
> やり過ごすこともできるだろう。利用者たちがそれぞれ、私のインタフェースを
> 彼らのロケータに合わせるべくアダプタを書くこともできるけれど、
> どうしたって結局私は、自分の作成したインタフェースをルックアップする、
> 最初のロケータについては知る必要があるのだ。それに、アダプタが
> 使われはじめると「コンポーネントはロケータと直接つながっている」
> というシンプルさが失われてしまう。
>
> その点、Dependency Injection では、コンポーネントはコンテナに
> 依存しなくなる。だがしかし、一旦設定が完了してしまうと、
> それ以上のサービスをコンテナから取得できなくなってしまう。
> Dependency Injection は Service Locator の代替案として有効である。
> アプリケーションクラスを構築するにあたっては、両者ともだいたい
> 同じようなものだが、私は Service Locator のほうが少し優勢だと思う。
> こちらのほうが振る舞いが素直だからだ。しかしながら、構築したクラスが
> 複数のアプリケーションで利用されるのであれば、 Dependency Injection の
> ほうがより良い選択肢となる。
256 ：デフォルトの名無しさん：04/11/15 00:48:52
>>253
夢を見てるのは君で、俺は現実に見てる。
夢を見てるのは君で、俺は現実に見てる。
257 ：デフォルトの名無しさん：04/11/15 00:50:44
258 ：デフォルトの名無しさん：04/11/15 00:53:03
259 ：デフォルトの名無しさん：04/11/15 00:53:07
>>24を間に受けるのはちょっと厳しい。
260 ：デフォルトの名無しさん：04/11/15 00:54:37
そりゃ、やらなきゃわからんだろうって。あいだに受けてもしかたないし。
261 ：デフォルトの名無しさん：04/11/15 00:57:37
262 ：デフォルトの名無しさん：04/11/15 01:00:40
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
263 ：デフォルトの名無しさん：04/11/15 01:02:05
マに受けられて「システムの一部分がなぜかどこでも使えるようになってたりする」の部分に幻想抱かれてもこまるけどね。
264 ：デフォルトの名無しさん：04/11/15 01:04:01
マ！
265 ：デフォルトの名無しさん：04/11/15 01:07:39
そろそろ「アンチDI厨は放置」の流れでいいんじゃないの?
脊髄反射レスしかできないみたいだし。
脊髄反射レスしかできないみたいだし。
266 ：デフォルトの名無しさん：04/11/15 01:09:24
>>264
年がばれます。
年がばれます。
267 ：デフォルトの名無しさん：04/11/15 01:10:48
そうすると話題ないよ？
「マに受ける」のマとは何か？プログラマのマとはどう違うのか、という議論くらいしか。
「マに受ける」のマとは何か？プログラマのマとはどう違うのか、という議論くらいしか。
268 ：デフォルトの名無しさん：04/11/15 01:11:41
>>266
え、歳がばれるようなネタがひそんでるの？
え、歳がばれるようなネタがひそんでるの？
269 ：デフォルトの名無しさん：04/11/15 01:16:33
マ゛！
270 ：デフォルトの名無しさん：04/11/15 01:18:25
暗き天に マ女は怒り狂う
この日○終わり 悲しいかな
この日○終わり 悲しいかな
271 ：デフォルトの名無しさん：04/11/15 01:26:19
>>267
めっきりネタスレだからなー。
めっきりネタスレだからなー。
272 ：デフォルトの名無しさん：04/11/15 02:04:16
>>268
マといえば当然アレだろうが。
マといえば当然アレだろうが。
273 ：デフォルトの名無しさん：04/11/15 02:57:52
>269が正しい発音です。
274 ：デフォルトの名無しさん：04/11/15 07:46:33
DI否定派はおそらくDIを何かわけのわからない凄い恐いものと考えてしまっている
と思うんだよね。
実はそんなたいしたものでもなくて、依存関係を整理するためのものに過ぎなくて、
それも使い方を知っていれば便利に使えるよっていうだけなんだけど。
クラスローディングの構造が複雑なプラットフォームなら、こういうものはありがたいんだよ。
（スクリプト言語プラットフォームなら、そんなにありがたみは無いかも）
と思うんだよね。
実はそんなたいしたものでもなくて、依存関係を整理するためのものに過ぎなくて、
それも使い方を知っていれば便利に使えるよっていうだけなんだけど。
クラスローディングの構造が複雑なプラットフォームなら、こういうものはありがたいんだよ。
（スクリプト言語プラットフォームなら、そんなにありがたみは無いかも）
275 ：デフォルトの名無しさん：04/11/15 09:16:11
というか、DIで解決すると言ってることについて、ほんとにすべてがそれだけで解決すると言ってるととらえて、そうじゃないから使えないと言ってる気がする。
AOPに関しても同じことを考えてることがうかがいしれる。
AOPに関しても同じことを考えてることがうかがいしれる。
276 ：デフォルトの名無しさん：04/11/15 09:52:43
依存関係を整理する仕組みならそもそも大抵のプログラミング言語にはあって
まずはそれを活用すべきって言う話もあるけど。
まずはそれを活用すべきって言う話もあるけど。
277 ：デフォルトの名無しさん：04/11/15 09:54:38
Javaならパッケージであるとか、ネームスペースを管理するものはあるし。
278 ：デフォルトの名無しさん：04/11/15 10:20:28
はぁ
279 ：デフォルトの名無しさん：04/11/15 10:41:23
うーん。
tp://xlegend.dip.jp/~hamasyou/archives/Engineer-Soul/dependency_injectiondiiocinversion_of_controliaaaiaieiin.php
tp://xlegend.dip.jp/~hamasyou/archives/Engineer-Soul/dependency_injectiondiiocinversion_of_controliaaaiaieiin.php
280 ：デフォルトの名無しさん：04/11/15 11:12:00
結局、DIを使うことと普通にＯＯＰするのと何が違うのさ
誰か教えてくれ
誰か教えてくれ
281 ：デフォルトの名無しさん：04/11/15 11:24:04
複数のクラスのオブジェクトから利用されるオブジェクトを一元管理できる。
282 ：デフォルトの名無しさん：04/11/15 11:28:58
MinDI: Minimalist Dependency Injection
ttp://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/120297
ttp://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/120297
283 ：デフォルトの名無しさん：04/11/15 12:17:00
>>280は放置でお願いします。
284 ：デフォルトの名無しさん：04/11/15 13:32:26
285 ：デフォルトの名無しさん：04/11/15 13:56:58
277はただの誤爆か、非常に筋違いか、まあ一目見てDIのこととは関係ないことがわかるんだけど、276ってなんなの？
パッケージのことを「依存関係を整理する仕組み」といってるの？
パッケージのことを「依存関係を整理する仕組み」といってるの？
286 ：デフォルトの名無しさん：04/11/15 13:57:53
287 ：デフォルトの名無しさん：04/11/15 13:59:09
そうだな>>290の発言は酷すぎる。放置でよろしく！
288 ：デフォルトの名無しさん：04/11/15 14:27:43
ネタスレの作り方の見本のような進行だな。
289 ：デフォルトの名無しさん：04/11/15 14:58:55
さあチキンレースのはじまりでつ！
290 ：デフォルトの名無しさん：04/11/15 15:11:23
ひがさんがハゲたら、Seasarも世界的に認められると思います。
あ、ちゃんと本も出してください。表紙に写真が載ってるやつ。
あ、ちゃんと本も出してください。表紙に写真が載ってるやつ。
291 ：デフォルトの名無しさん：04/11/15 16:25:31
>>290もう少しひねれYO…ヾ(´д｀)ﾉ゜
292 ：デフォルトの名無しさん：04/11/15 21:45:21
もう大抵の釣り発言は出尽くした気がするよ。
293 ：デフォルトの名無しさん：04/11/15 22:45:06
紳助寄りの芸人がまたそろって被害者の人格攻撃して傷口をえぐっている。
（被害者の人格攻撃でもしない限り加害者の行為をどうやっても正当化できない時点で、加害者が間違っているという
ことなんだけど。そこを無理に擁護しようとするから被害者を叩くことになる。
もしここで誰かに「あんたの言ってることはおかしい」と突っ込まれたら、「正しくある」ためにはさらに被害者を中傷し「悪者」
にせざるを得なくなり、加害者を守るために被害者を貶め続ける、という理不尽無限ループにはまっていくことになる。
どこから見ても正しくない犠牲者非難の一丁上がりだ）
「不愉快にさせることを言ったんだから殴られても当然だろ」という意見も見たが、思わずそんなことをほざいてる人を監禁
して鉄拳制裁を加え唾を吐きたくなったです。「殴られた自分に問題があった」とすんなり諦められるもんなのかね。
記者会見で紳助自ら「勝手に感情的になった（キレた）」ことを認め、自分の暴力に正当性がなかったことも認めているのに、
しつこく被害者側の「人格的落ち度」を憶測で言いつのって暴力行為を正当化しようとする人には本当にうんざりする。
（またそれが中立的行動だと勘違いしていたりするからなお最悪）
（被害者の人格攻撃でもしない限り加害者の行為をどうやっても正当化できない時点で、加害者が間違っているという
ことなんだけど。そこを無理に擁護しようとするから被害者を叩くことになる。
もしここで誰かに「あんたの言ってることはおかしい」と突っ込まれたら、「正しくある」ためにはさらに被害者を中傷し「悪者」
にせざるを得なくなり、加害者を守るために被害者を貶め続ける、という理不尽無限ループにはまっていくことになる。
どこから見ても正しくない犠牲者非難の一丁上がりだ）
「不愉快にさせることを言ったんだから殴られても当然だろ」という意見も見たが、思わずそんなことをほざいてる人を監禁
して鉄拳制裁を加え唾を吐きたくなったです。「殴られた自分に問題があった」とすんなり諦められるもんなのかね。
記者会見で紳助自ら「勝手に感情的になった（キレた）」ことを認め、自分の暴力に正当性がなかったことも認めているのに、
しつこく被害者側の「人格的落ち度」を憶測で言いつのって暴力行為を正当化しようとする人には本当にうんざりする。
（またそれが中立的行動だと勘違いしていたりするからなお最悪）
294 ：デフォルトの名無しさん：04/11/15 23:14:31
Dross Injectionか・・・・・・・・まぁ、DIではあるな＞293
295 ：デフォルトの名無しさん：04/11/15 23:35:51
>>280
ソースが実装に依存しなくなること。
Interface interface = new Impl();
このようなコードをソース中に書いてしまうと、Interfaceの実装を切り替えることが困難になってしまう。
実装の切り替えを行いたいという要件がなければこのままで何も問題ないが
適切な箇所で実装の切り替えを可能にしておくと、テストの時とか何かと嬉しい。
不要な人には不要だろうけどね。
ソースが実装に依存しなくなること。
Interface interface = new Impl();
このようなコードをソース中に書いてしまうと、Interfaceの実装を切り替えることが困難になってしまう。
実装の切り替えを行いたいという要件がなければこのままで何も問題ないが
適切な箇所で実装の切り替えを可能にしておくと、テストの時とか何かと嬉しい。
不要な人には不要だろうけどね。
296 ：デフォルトの名無しさん：04/11/15 23:48:33
297 ：デフォルトの名無しさん：04/11/16 00:09:20
>>295
それはそうなんだけどさ。そういうメリット一式は>>1のリンク先に既出なんだよね。
んで支離滅裂アンチDI厨は一切メリットが理解できないらしい。たぶん層分割とか
TDDとかちゃんと考えて設計したことがないんだろうね。
それはそうなんだけどさ。そういうメリット一式は>>1のリンク先に既出なんだよね。
んで支離滅裂アンチDI厨は一切メリットが理解できないらしい。たぶん層分割とか
TDDとかちゃんと考えて設計したことがないんだろうね。
298 ：デフォルトの名無しさん：04/11/16 00:11:10
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
299 ：デフォルトの名無しさん：04/11/16 00:18:35
そういう無駄な物言いをするから、無駄に荒れるんじゃないかと思うんだが
無駄追認は情報量ないし荒れる元になるしで百害あって一利なし。
無駄追認は情報量ないし荒れる元になるしで百害あって一利なし。
300 ：デフォルトの名無しさん：04/11/16 00:27:47
ヒマがつぶれていいんじゃない？
有意義な流れになると、ヒマじゃない時間がつぶれて困る。
有意義な流れになると、ヒマじゃない時間がつぶれて困る。
301 ：デフォルトの名無しさん：04/11/16 00:31:40
ノイズをスルーできない馬鹿が一人いるせいで、スレが荒れてる。
302 ：デフォルトの名無しさん：04/11/16 00:33:07
Lethal Injection
303 ：デフォルトの名無しさん：04/11/16 00:40:49
>>301
つまり、301のことですね？
つまり、301のことですね？
304 ：デフォルトの名無しさん：04/11/16 00:42:50
>>301
とりあえず無闇にageるな。ノイズが混じる。
とりあえず無闇にageるな。ノイズが混じる。
305 ：デフォルトの名無しさん：04/11/16 02:24:48
>>279
それみたけど、DIだけを考えたら確かに無闇に適用すべきじゃない、というのはごもっとも。
でも今のDIコンテナはAOPと組み合わされて強力になったわけで、
そのあたりを過小評価してないだろうか、と思った。
DBのトランザクション制御が必要なアプリケーション（ほとんど全てのアプリケーションだが）
ならDIコンテナを使って恩恵にあずかれるだろうから、
むやみやたらに使ってもいいんでないかいと思ってる。
漏れ最早DI原理主義者ですから（ｗ
まあ、本気でむやみやたらに使ったらあかんけど。それは当然。
ある程度アーキテクチャはきめとかないとな。くーすとかでいいと思うけど。
それみたけど、DIだけを考えたら確かに無闇に適用すべきじゃない、というのはごもっとも。
でも今のDIコンテナはAOPと組み合わされて強力になったわけで、
そのあたりを過小評価してないだろうか、と思った。
DBのトランザクション制御が必要なアプリケーション（ほとんど全てのアプリケーションだが）
ならDIコンテナを使って恩恵にあずかれるだろうから、
むやみやたらに使ってもいいんでないかいと思ってる。
漏れ最早DI原理主義者ですから（ｗ
まあ、本気でむやみやたらに使ったらあかんけど。それは当然。
ある程度アーキテクチャはきめとかないとな。くーすとかでいいと思うけど。
306 ：デフォルトの名無しさん：04/11/16 02:45:27
>>305
よかった、放置かと思ったよ・・・。
よかった、放置かと思ったよ・・・。
307 ：デフォルトの名無しさん：04/11/16 03:12:28
従来コードによって手続き的に実現されていた依存関係が、XMLを用いた
宣言的な記述を行うことによって、ともすればコードに埋没してしまいそ
うな関係の意図を明確にし、さらにデータ駆動にすることによってコード
を書き換えることなく関係を取り替えることを容易にする…という理解で
よいでしょうか。
全く使ったことないけど。
宣言的な記述を行うことによって、ともすればコードに埋没してしまいそ
うな関係の意図を明確にし、さらにデータ駆動にすることによってコード
を書き換えることなく関係を取り替えることを容易にする…という理解で
よいでしょうか。
全く使ったことないけど。
308 ：デフォルトの名無しさん：04/11/16 03:23:44
>>279の文章は使ってみた実感としての問題点を書いているのではなくて、
脳内でシミュレーションした際に感じた恐れを書いているだけな気がするな。
DIを使ったところで恐れているほど関係が見えなくなることはないよ、少なくともJavaでは。
「インターフェースを相手にコードを書く」ことに慣れているか否かの問題で
あるような気もする。
脳内でシミュレーションした際に感じた恐れを書いているだけな気がするな。
DIを使ったところで恐れているほど関係が見えなくなることはないよ、少なくともJavaでは。
「インターフェースを相手にコードを書く」ことに慣れているか否かの問題で
あるような気もする。
309 ：デフォルトの名無しさん：04/11/16 03:53:37
>>305
> ある程度アーキテクチャはきめとかないとな。くーすとかでいいと思うけど。
くーすはアーキテクチャなのか開発プロセスなのか。
開発プロセスのスコープ外のマネジメントレイヤがあるのは
しごく当たり前のことだが、くーすのマネジメント等閑視は
もはや開発プロセスではないという感じ。
以上スレ違いスマソ。
あっちでやると擁護厨が極めてうざいので。
> ある程度アーキテクチャはきめとかないとな。くーすとかでいいと思うけど。
くーすはアーキテクチャなのか開発プロセスなのか。
開発プロセスのスコープ外のマネジメントレイヤがあるのは
しごく当たり前のことだが、くーすのマネジメント等閑視は
もはや開発プロセスではないという感じ。
以上スレ違いスマソ。
あっちでやると擁護厨が極めてうざいので。
310 ：デフォルトの名無しさん：04/11/16 03:59:03
中の人はいっしょ
311 ：デフォルトの名無しさん：04/11/16 04:00:29
アーキテクチャと開発プロセスはどちらかにしか属することができないようなものなの？
312 ：デフォルトの名無しさん：04/11/16 07:57:00
擁護厨にアンチ厨か。厨だらけだな。
313 ：デフォルトの名無しさん：04/11/16 08:34:49
>>295
漏れは
fooFactory = Application.getFooFactory();
~~
FooInterface foo = fooFactory.create();
のほうが好みだ。
漏れの経験からすると、実装を切り替えたいシーンってそんなに無いし、
切り替え必要なら↑のようなシンプルな解決法があるしね。
しちがってDI要らず。
漏れは
fooFactory = Application.getFooFactory();
~~
FooInterface foo = fooFactory.create();
のほうが好みだ。
漏れの経験からすると、実装を切り替えたいシーンってそんなに無いし、
切り替え必要なら↑のようなシンプルな解決法があるしね。
しちがってDI要らず。
314 ：デフォルトの名無しさん：04/11/16 09:09:56
>>312
認定厨だね。
認定厨だね。
315 ：デフォルトの名無しさん：04/11/16 09:10:58
>>313
いいねぇ、いちいちファクトリ作る工賃まで請求できて。
いいねぇ、いちいちファクトリ作る工賃まで請求できて。
316 ：デフォルトの名無しさん：04/11/16 09:12:47
317 ：デフォルトの名無しさん：04/11/16 09:20:57
318 ：デフォルトの名無しさん：04/11/16 09:37:15
>>317
FooInterface foo = new FooImpl();
と
FooInterface foo = fooFactory.create();
と
FooInterface foo = container.get("foo");
を比較してるだろ。
その時点で間違い。
FooInterface foo = new FooImpl();
と
FooInterface foo = fooFactory.create();
と
FooInterface foo = container.get("foo");
を比較してるだろ。
その時点で間違い。
319 ：デフォルトの名無しさん：04/11/16 10:01:31
>>313の例だと、DIコンテナをただのファクトリーとしか
認識してないと思われてしまいます。
まあ>>295の例示がそんな感じなので
この場合しょうがないかもしれませんが。
DI不要論へ話をもって行きたいなら
fooが他のクラスとの依存関連がある場合を考えて
依存先のクラスを誰が生成して誰が関連付けるか
DI要らずのシンプルな解決法を教えて欲しいところです。
認識してないと思われてしまいます。
まあ>>295の例示がそんな感じなので
この場合しょうがないかもしれませんが。
DI不要論へ話をもって行きたいなら
fooが他のクラスとの依存関連がある場合を考えて
依存先のクラスを誰が生成して誰が関連付けるか
DI要らずのシンプルな解決法を教えて欲しいところです。
320 ：デフォルトの名無しさん：04/11/16 10:34:30
ほんの数行の決まりきったクラスを
interface ごとにわざわざ作るんですか？
ソース自動生成とかで？
まさか手で書くとは思いたくも無いけど。
DI排除してまで無駄に手間をかけるメリットってなんだろう。
interface ごとにわざわざ作るんですか？
ソース自動生成とかで？
まさか手で書くとは思いたくも無いけど。
DI排除してまで無駄に手間をかけるメリットってなんだろう。
321 ：デフォルトの名無しさん：04/11/16 11:00:23
>>317
いいねぇ、ほんの数行の決まりきったクラスを、それもDI使えば不要になるクラスを書く工賃がもらえて。
なんか、関数ポインタのポインタとか駆使して、OO言語を不要といってるようなむなしさを感じる。
いいねぇ、ほんの数行の決まりきったクラスを、それもDI使えば不要になるクラスを書く工賃がもらえて。
なんか、関数ポインタのポインタとか駆使して、OO言語を不要といってるようなむなしさを感じる。
322 ：デフォルトの名無しさん：04/11/16 12:19:27
323 ：デフォルトの名無しさん：04/11/16 12:40:39
ていどひくい
324 ：デフォルトの名無しさん：04/11/16 13:14:21
325 ：デフォルトの名無しさん：04/11/16 13:22:12
326 ：デフォルトの名無しさん：04/11/16 14:10:01
依存関係があるクラスを「書く」のはプログラムする以外にないだろうけど、
複数の依存関係にあるオブジェクトを、setほげほげしたり、コンストラクタで
引き渡したりして、きちんとまとめたうえで返してくれるファクトリをちまちま
書くのは邪魔臭いと思うけど。
AOPを抜きにして「ちょっと便利なファクトリ」としてDIを使うだけでも、利点は
あると思う。
ああ、あとべつにService Locatorが退化だとも思わんけどね...
言ってみればDIコンテナがService Locatorみたいなもんだし。
複数の依存関係にあるオブジェクトを、setほげほげしたり、コンストラクタで
引き渡したりして、きちんとまとめたうえで返してくれるファクトリをちまちま
書くのは邪魔臭いと思うけど。
AOPを抜きにして「ちょっと便利なファクトリ」としてDIを使うだけでも、利点は
あると思う。
ああ、あとべつにService Locatorが退化だとも思わんけどね...
言ってみればDIコンテナがService Locatorみたいなもんだし。
327 ：デフォルトの名無しさん：04/11/16 14:24:52
俺様ロケータにコンパイル時依存してる状況が退化だと言ってるのだと思われ。
328 ：デフォルトの名無しさん：04/11/16 14:34:06
あ、なるほど＞コンパイル時依存
329 ：デフォルトの名無しさん：04/11/16 19:33:01
330 ：デフォルトの名無しさん：04/11/16 22:44:03
なぁ>>329よ…もしかして、DIを信仰してない香具師が、皆同一人物に見えてる？
331 ：デフォルトの名無しさん：04/11/16 23:19:25
DI・DIコンテナを、はっきり分けて議論した方がいいな
332 ：デフォルトの名無しさん：04/11/16 23:33:36
XML がソースそのものだと言ったが、もうひとつ。
DI 廚 = マップ廚
分かるか？実行時解決ﾏﾝｾｰ！？
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。
なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ？
DI 廚 = マップ廚
分かるか？実行時解決ﾏﾝｾｰ！？
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。
なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ？
333 ：デフォルトの名無しさん：04/11/16 23:42:44
334 ：デフォルトの名無しさん：04/11/17 00:04:29
XML がソースそのものだと言ったが、もうひとつ。
DI 廚 = マップ廚
分かるか？実行時解決ﾏﾝｾｰ！？
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。
なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ？
DI 廚 = マップ廚
分かるか？実行時解決ﾏﾝｾｰ！？
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。
なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ？
335 ：デフォルトの名無しさん：04/11/17 00:04:42
336 ：デフォルトの名無しさん：04/11/17 00:06:28
>>334
勝手にコピペすんな。
勝手にコピペすんな。
337 ：デフォルトの名無しさん：04/11/17 00:06:38
338 ：デフォルトの名無しさん：04/11/17 00:07:42
XML がソースそのものだと言ったが、もうひとつ。
DI 廚 = マップ廚
分かるか？実行時解決ﾏﾝｾｰ！？
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。
なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ？
DI 廚 = マップ廚
分かるか？実行時解決ﾏﾝｾｰ！？
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。
なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ？
339 ：デフォルトの名無しさん：04/11/17 00:11:38
>>334
問題提起になってない。くだらん。
問題提起になってない。くだらん。
340 ：デフォルトの名無しさん：04/11/17 00:13:09
341 ：デフォルトの名無しさん：04/11/17 00:16:53
>>332
> どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
> 生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
> 実行時なんたらって言いたいだけちゃうんかと。
AOPとか、O/Rマッピングの定型的な処理とかでバイトコード生成を使うと
何が犠牲になるのか説明してくれないか。
> どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
> 生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
> 実行時なんたらって言いたいだけちゃうんかと。
AOPとか、O/Rマッピングの定型的な処理とかでバイトコード生成を使うと
何が犠牲になるのか説明してくれないか。
342 ：デフォルトの名無しさん：04/11/17 00:30:57
343 ：デフォルトの名無しさん：04/11/17 00:34:05
実行時解決のリスクについて言いたかっただけでは？
344 ：デフォルトの名無しさん：04/11/17 01:04:44
↓ここのseasar株上昇ってところ
tp://d.hatena.ne.jp/zwfk/20041116
これ読んだだけでも良さが判るじゃん。
リスクうんぬん、お釣りがくるんとちゃいまっか。
tp://d.hatena.ne.jp/zwfk/20041116
これ読んだだけでも良さが判るじゃん。
リスクうんぬん、お釣りがくるんとちゃいまっか。
345 ：デフォルトの名無しさん：04/11/17 01:19:05
なんで Spring スレにまで 332 をコピペしたのだろう。
346 ：デフォルトの名無しさん：04/11/17 01:33:13
>>345
コピペだと気づかずレスしてしまったorz
コピペだと気づかずレスしてしまったorz
347 ：デフォルトの名無しさん：04/11/17 01:34:27
>>332
何が犠牲になってるのか、解説キボンヌ
何が犠牲になってるのか、解説キボンヌ
348 ：デフォルトの名無しさん：04/11/17 01:47:34
349 ：デフォルトの名無しさん：04/11/17 01:58:31
>>348
くだらんもん流行らすなよ・・・それじゃ、ただの荒らしじゃねぇか。
くだらんもん流行らすなよ・・・それじゃ、ただの荒らしじゃねぇか。
350 ：デフォルトの名無しさん：04/11/17 02:01:29
DI は実装の注入を含蓄してると思うのは俺だけですか？
DI+IIって、頭痛+頭がガンガンする、くらいにくどい気がするのは俺だけですか？
>332って>208の後半部と同じこと言ってる気がするのは俺だけですか？
>214に対する回答ってどこに書いてあったか、誰かご存知ないですか？
DI+IIって、頭痛+頭がガンガンする、くらいにくどい気がするのは俺だけですか？
>332って>208の後半部と同じこと言ってる気がするのは俺だけですか？
>214に対する回答ってどこに書いてあったか、誰かご存知ないですか？
351 ：デフォルトの名無しさん：04/11/17 02:25:48
>>348
既にこのスレが荒らされてるし（ｗ
既にこのスレが荒らされてるし（ｗ
352 ：デフォルトの名無しさん：04/11/17 02:26:39
>>350
だからもはやネタスレだってば
だからもはやネタスレだってば
353 ：デフォルトの名無しさん：04/11/17 02:28:56
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
354 ：デフォルトの名無しさん：04/11/17 02:30:47
アーキテクチャの変化についていけない人が、そんな自分を正当化するスレです。
355 ：デフォルトの名無しさん：04/11/17 02:32:28
ひとりの人格が崩壊していくのをリアルタイムで見ている気分だ。
この先こいつが死んだりしたときに非公開の日記にこのスレのことが
書かれてたりすると、果たして冷静でいられるのだろうかと思ったりする。
…ま、そうなっても同情しないけどな。
この先こいつが死んだりしたときに非公開の日記にこのスレのことが
書かれてたりすると、果たして冷静でいられるのだろうかと思ったりする。
…ま、そうなっても同情しないけどな。
356 ：デフォルトの名無しさん：04/11/17 02:34:38
357 ：デフォルトの名無しさん：04/11/17 02:36:09
>>355
禿藁 && 禿胴
禿藁 && 禿胴
358 ：デフォルトの名無しさん：04/11/17 02:40:57
ファクトリ作るのと変わらんって言ってるけど、そこから先の差がでかいんだよね。
ORマッピングとかも、データ取ってくるだけならDbUtilsと大差ないけど、そこから先の差がでかい。
ORマッピングとかも、データ取ってくるだけならDbUtilsと大差ないけど、そこから先の差がでかい。
359 ：デフォルトの名無しさん：04/11/17 02:42:50
>>358
ネタスレにつきマジレス不要(w
ネタスレにつきマジレス不要(w
360 ：デフォルトの名無しさん：04/11/17 02:45:07
そこから先の差がでかいって言ってるけど、ファクトリ作るのと変わらないんだよね。
ORマッピングとかも、そこから先の差がでかいって言ってるけど、DbUtilsやらMapへの流し込みと大差ない。
ORマッピングとかも、そこから先の差がでかいって言ってるけど、DbUtilsやらMapへの流し込みと大差ない。
361 ：デフォルトの名無しさん：04/11/17 02:49:11
362 ：デフォルトの名無しさん：04/11/17 02:49:18
363 ：デフォルトの名無しさん：04/11/17 02:50:12
ゴキブリみたいだな
364 ：デフォルトの名無しさん：04/11/17 02:51:38
ゾンビ、ゾンバー、ゾンビスト！
365 ：デフォルトの名無しさん：04/11/17 02:57:50
DIのことをマンセーしてるやつって、中途半端なWebサイトのおもてが
わはよく知ってるつもりになってるみたいだけど、単なるフロントエンドと
かばかりやってると、複雑なロジックに対応できない。身のほどを知ってもっとおお
らかにやればいいのに、鬼の首とったように得意になるのが理解でき
ん
わはよく知ってるつもりになってるみたいだけど、単なるフロントエンドと
かばかりやってると、複雑なロジックに対応できない。身のほどを知ってもっとおお
らかにやればいいのに、鬼の首とったように得意になるのが理解でき
ん
366 ：デフォルトの名無しさん：04/11/17 02:59:12
367 ：デフォルトの名無しさん：04/11/17 03:01:35
368 ：デフォルトの名無しさん：04/11/17 03:01:48
369 ：デフォルトの名無しさん：04/11/17 03:02:16
DIの
わは
かば
らか
ん
わは
かば
らか
ん
370 ：デフォルトの名無しさん：04/11/17 03:03:12
371 ：デフォルトの名無しさん：04/11/17 03:03:58
>>369
もうちょっと頑張ろうね。立て読みは本文が皮肉になってないと面白くないよ
もうちょっと頑張ろうね。立て読みは本文が皮肉になってないと面白くないよ
372 ：デフォルトの名無しさん：04/11/17 03:04:52
>>371
3レスつれたら上等。
3レスつれたら上等。
373 ：デフォルトの名無しさん：04/11/17 03:06:11
374 ：デフォルトの名無しさん：04/11/17 03:07:25
キミらネタに反応しすぎ。
375 ：デフォルトの名無しさん：04/11/17 03:08:32
ついに360=362は369のようなしょぼいネタに走ってしまったのか？？
376 ：デフォルトの名無しさん：04/11/17 03:09:27
377 ：デフォルトの名無しさん：04/11/17 03:10:01
378 ：デフォルトの名無しさん：04/11/17 03:10:43
ΣΣ(ﾟдﾟｌｌｌ) ﾊﾞﾚﾀﾖ
さらに =>>358だったりして。
さらに =>>358だったりして。
379 ：デフォルトの名無しさん：04/11/17 03:12:34
で、本物の厨は今頃回線切って首吊って本物のゾンビになってると。
380 ：デフォルトの名無しさん：04/11/17 03:12:35
さあ 盛
り
上
が
っ
て
参
り
ま
す
た
………………微妙にな。
り
上
が
っ
て
参
り
ま
す
た
………………微妙にな。
381 ：デフォルトの名無しさん：04/11/17 03:14:48
382 ：デフォルトの名無しさん：04/11/17 03:16:53
微妙だな。
383 ：デフォルトの名無しさん：04/11/17 03:17:09
384 ：デフォルトの名無しさん：04/11/17 03:20:12
キミら、早く寝なさい。
こんなとこで遊んでるヒマがあったらドキュメント書きなさい。
こんなとこで遊んでるヒマがあったらドキュメント書きなさい。
385 ：デフォルトの名無しさん：04/11/17 03:20:58
>>383
そんなに邪険にしないでください。
ネタスレなのにネタを投下する人がいないと閑古鳥でつ。
体を張って笑いを作ってくれている>>332ﾀｿはいい人でつ。
でもそろそろ>>213のオチをつけてくれると嬉しいでつ。
そんなに邪険にしないでください。
ネタスレなのにネタを投下する人がいないと閑古鳥でつ。
体を張って笑いを作ってくれている>>332ﾀｿはいい人でつ。
でもそろそろ>>213のオチをつけてくれると嬉しいでつ。
386 ：デフォルトの名無しさん：04/11/17 03:23:55
>>384
ドキュメントを書くのは馬鹿です。漏れはマスをかきます。
>>332は、DI + II（Implementation Injection）コンテナを書くそうです。
早く書いてください。ガマンできません。
ドキュメントを書くのは馬鹿です。漏れはマスをかきます。
>>332は、DI + II（Implementation Injection）コンテナを書くそうです。
早く書いてください。ガマンできません。
387 ：デフォルトの名無しさん：04/11/17 03:24:29
388 ：デフォルトの名無しさん：04/11/17 03:26:45
あれもこれも同じ人が書いていると信じたい。
まさかこんなに厨がいっぱいいるなんて決して信じたくない。
まさかこんなに厨がいっぱいいるなんて決して信じたくない。
389 ：デフォルトの名無しさん：04/11/17 03:29:15
>>386ちょっと下品ですね
390 ：デフォルトの名無しさん：04/11/17 03:30:06
えっと、このスレは>>1-387までオレの自作自演ですがなにか(・∀・)
391 ：デフォルトの名無しさん：04/11/17 03:30:49
392 ：デフォルトの名無しさん：04/11/17 03:31:58
このスレはすべて外部からインジェクションされてますが、なにか？
393 ：デフォルトの名無しさん：04/11/17 03:32:34
394 ：デフォルトの名無しさん：04/11/17 03:40:57
>>391
ひがたんのうんこと言ってたのは別の人でつ。
うんこと言ってる人に粘着してみたでつ。
でもあっちのスレにはネ申が降臨したでつ。
文体に敏感な>>391はきっとひがたんをうんこといったやつでつ。
同じ人が同じ文体で書くと思っているのがウブでつね（藁
でつなんて普通にみんな2chなら書くでつよ。ﾌﾟﾌﾟﾌﾟ
次は何に粘着する気だ？バーカｗ
ひがたんのうんこと言ってたのは別の人でつ。
うんこと言ってる人に粘着してみたでつ。
でもあっちのスレにはネ申が降臨したでつ。
文体に敏感な>>391はきっとひがたんをうんこといったやつでつ。
同じ人が同じ文体で書くと思っているのがウブでつね（藁
でつなんて普通にみんな2chなら書くでつよ。ﾌﾟﾌﾟﾌﾟ
次は何に粘着する気だ？バーカｗ
395 ：デフォルトの名無しさん：04/11/17 03:43:46
殺伐としてますね
396 ：デフォルトの名無しさん：04/11/17 03:45:27
それがいいんじゃねえか。女子供はすっこんでろ。
397 ：デフォルトの名無しさん：04/11/17 03:45:29
「バーカ」ってひさびさに見たな...
398 ：デフォルトの名無しさん：04/11/17 03:45:45
399 ：デフォルトの名無しさん：04/11/17 03:46:32
バーカバーカ！
お前の母ちゃんデベソ！
お前の母ちゃんデベソ！
400 ：デフォルトの名無しさん：04/11/17 03:46:53
>>396
女子供ですが、チンコのサイズはオトナです。
女子供ですが、チンコのサイズはオトナです。
401 ：デフォルトの名無しさん：04/11/17 03:48:20
いい加減寝ろよお前ら。微妙に期待してしまって寝れないじゃないか（ｗ
402 ：デフォルトの名無しさん：04/11/17 03:49:23
>>400
使えないチンコはサイズ無関係にコドモです。チンカス洗えよ。
使えないチンコはサイズ無関係にコドモです。チンカス洗えよ。
403 ：デフォルトの名無しさん：04/11/17 03:49:27
404 ：デフォルトの名無しさん：04/11/17 03:50:08
>>402
むくと痛いです(；_；)
むくと痛いです(；_；)
405 ：デフォルトの名無しさん：04/11/17 03:50:23
内容は悪くないな
406 ：デフォルトの名無しさん：04/11/17 03:52:16
407 ：デフォルトの名無しさん：04/11/17 03:53:25
408 ：デフォルトの名無しさん：04/11/17 03:53:57
今夜は寝かさないぜ！
おやすみなさい
おやすみなさい
409 ：デフォルトの名無しさん：04/11/17 03:57:57
今このスレに何人いるんだ？
点呼だ点呼！
いち！
次！！
点呼だ点呼！
いち！
次！！
410 ：デフォルトの名無しさん：04/11/17 04:00:59
２！
誰もいないようだな。俺も寝るぞ。じゃあな。
誰もいないようだな。俺も寝るぞ。じゃあな。
411 ：デフォルトの名無しさん：04/11/17 04:02:22
412 ：デフォルトの名無しさん：04/11/17 04:06:34
353あたりから4人でやってるね。４さまですた。
413 ：デフォルトの名無しさん：04/11/17 04:07:58
そのうちひとりは>>213かな？
とりあえず５だ。おやすみ。
とりあえず５だ。おやすみ。
414 ：デフォルトの名無しさん：04/11/17 04:12:36
俺もいるぞ。６な。寝る。
415 ：デフォルトの名無しさん：04/11/17 04:26:22
なんか厨の中には「ものすごく難しい議論をしてる」(実際は差ほどじゃないんだけどね…)
ってのを荒らすのが好きなのいるみたいね。
ってのを荒らすのが好きなのいるみたいね。
416 ：デフォルトの名無しさん：04/11/17 04:28:04
頭のいいやつってくだらないことに夢中になってバカだなぁ、そんなもん必要ないのに。的。
417 ：デフォルトの名無しさん：04/11/17 04:30:02
差ほど
418 ：デフォルトの名無しさん：04/11/17 08:10:29
中身のないスレだな ７だ。
419 ：デフォルトの名無しさん：04/11/17 08:44:44
420 ：デフォルトの名無しさん：04/11/17 09:40:47
DIは夜中にレスが100進むくらいの人気と関心のある、
ナウでホットなトピックなんですよ！
と言えば上司も分かってくれる。
ナウでホットなトピックなんですよ！
と言えば上司も分かってくれる。
421 ：デフォルトの名無しさん：04/11/17 20:01:30
>>XML自体がソースコードだということに気づけ。
そこでTigerですよ。
と知ったかしてみる。
そこでTigerですよ。
と知ったかしてみる。
422 ：デフォルトの名無しさん：04/11/17 20:02:14
ナウなヤングがフィーバーしてるスレはここですか？
423 ：デフォルトの名無しさん：04/11/17 21:16:54
>>421
そこでCocoon2ですよ、ってのは？
そこでCocoon2ですよ、ってのは？
424 ：デフォルトの名無しさん：04/11/18 01:21:55
>>423
XSP自体がソースコードだと言うことに気づけ、と大喝されるよ、きっと。ﾊｧﾊｧ。
XSP自体がソースコードだと言うことに気づけ、と大喝されるよ、きっと。ﾊｧﾊｧ。
425 ：デフォルトの名無しさん：04/11/18 01:26:57
S2スレからコピペ。
> 563 名前：デフォルトの名無しさん 本日のレス 投稿日：04/11/18 00:06:17
> ＤＩはある意味ではハシカみたいなもんじゃないかと思います。
>
> 思い起こせば、Javaを覚えたてのころは継承を乱用し、
> GoF本を読めば(作ってるシステムにとって)意味のないクラスを量産し、
> 作ってる本人はご満悦ですが、保守する人とかどうしてるんだろう、
> と思う今日このごろなコードもかつては作ってしまった気もします。
>
> ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。
>
> 新しい設計技法、言語、ツールを知ると使いたくなるというのは
> 技術者の真っ当な感情だと思いますが、下手に使うとまわりが被害をこうむりますかも。
> あと、伝染性がある上に発病期間までに時間があったりすることも。
> ちゃんとテストして(使ってみて)、これは行けると踏んでから、
> まずはリスクの少ない部分から適用していきましょうと(予防接種)。
>
> 生産性と品質に対して何の寄与もしないどころか、
> 足を引っ張るだけのフレームワークにハメられた僕は
> 別な何かが見える様になったと思います。
> 563 名前：デフォルトの名無しさん 本日のレス 投稿日：04/11/18 00:06:17
> ＤＩはある意味ではハシカみたいなもんじゃないかと思います。
>
> 思い起こせば、Javaを覚えたてのころは継承を乱用し、
> GoF本を読めば(作ってるシステムにとって)意味のないクラスを量産し、
> 作ってる本人はご満悦ですが、保守する人とかどうしてるんだろう、
> と思う今日このごろなコードもかつては作ってしまった気もします。
>
> ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。
>
> 新しい設計技法、言語、ツールを知ると使いたくなるというのは
> 技術者の真っ当な感情だと思いますが、下手に使うとまわりが被害をこうむりますかも。
> あと、伝染性がある上に発病期間までに時間があったりすることも。
> ちゃんとテストして(使ってみて)、これは行けると踏んでから、
> まずはリスクの少ない部分から適用していきましょうと(予防接種)。
>
> 生産性と品質に対して何の寄与もしないどころか、
> 足を引っ張るだけのフレームワークにハメられた僕は
> 別な何かが見える様になったと思います。
426 ：デフォルトの名無しさん：04/11/18 01:31:48
>>425の論法
・継承やDPの乱用はよくない。
・継承やDPは導入期に大いにもてはやされた。
・よって導入期に大いにもてはやされているDIの乱用はよくない。
ただの一般論かよボケが。
で、DIの乱用ってのが具体的にどういう層への適用なのかが
全く提示されていないわけだが。
・継承やDPの乱用はよくない。
・継承やDPは導入期に大いにもてはやされた。
・よって導入期に大いにもてはやされているDIの乱用はよくない。
ただの一般論かよボケが。
で、DIの乱用ってのが具体的にどういう層への適用なのかが
全く提示されていないわけだが。
427 ：デフォルトの名無しさん：04/11/18 01:35:32
428 ：デフォルトの名無しさん：04/11/18 01:38:48
さあ今夜もはじまりました！
429 ：デフォルトの名無しさん：04/11/18 01:41:17
430 ：デフォルトの名無しさん：04/11/18 01:42:47
>>429
回線も吊るのかよ！
回線も吊るのかよ！
431 ：デフォルトの名無しさん：04/11/18 01:44:23
ネタスレの流れになってきたな。
みんな今日は早く寝ろよ。
みんな今日は早く寝ろよ。
432 ：デフォルトの名無しさん：04/11/18 01:45:43
オマエモナー（ ´∀｀）
433 ：デフォルトの名無しさん：04/11/18 01:47:24
別スレからのコピペにせよ、何となく425に説得されてしまった漏れ。
434 ：デフォルトの名無しさん：04/11/18 01:48:32
Spring スレには投下なしかよ、、、
DI関連だとS2スレの方が賑やかっぽい？
DI関連だとS2スレの方が賑やかっぽい？
435 ：デフォルトの名無しさん：04/11/18 01:50:58
425はSpringがDIだと知らない悪寒
436 ：デフォルトの名無しさん：04/11/18 01:52:16
437 ：デフォルトの名無しさん：04/11/18 01:56:40
ネタスレには人が集まるもんさ。
438 ：デフォルトの名無しさん：04/11/18 01:59:52
425はS2スレのこぴぺ
S2スレのははてなのこぴぺ
でもはてなで話題になってるのはDIじゃない
1行目のDIは元記事ではデザインパターン
S2スレのははてなのこぴぺ
でもはてなで話題になってるのはDIじゃない
1行目のDIは元記事ではデザインパターン
439 ：デフォルトの名無しさん：04/11/18 02:07:17
>433
見かけ上の階層は7階層くらいあるものの
n層とn+1層の境目が混沌としてて、
n層のクラスがn+1層のサービスを利用する為に
n+1層のインスタンスを生成するんだけど
その際に自分(n層のインスタンス)を渡し、
n+1層のメソッド内でn層のサービスを呼び出すのが当たり前のように行われ、
ためしにシーケンス図描かせるとアミダクジのようにメッセージが
右へ左へ往復する素敵なフレームワークを体験すると
425を見ても動じなくなります。
見かけ上の階層は7階層くらいあるものの
n層とn+1層の境目が混沌としてて、
n層のクラスがn+1層のサービスを利用する為に
n+1層のインスタンスを生成するんだけど
その際に自分(n層のインスタンス)を渡し、
n+1層のメソッド内でn層のサービスを呼び出すのが当たり前のように行われ、
ためしにシーケンス図描かせるとアミダクジのようにメッセージが
右へ左へ往復する素敵なフレームワークを体験すると
425を見ても動じなくなります。
440 ：デフォルトの名無しさん：04/11/18 02:12:23
ネタスレはある意味ではハシカみたいなもんじゃないかと思います。
思い起こせば、2chを覚えたてのころはageを乱用し、
スレ立てを知れば(見ている板にとって)意味のないスレを量産し、
カキコしている本人はご満悦ですが、ROMする人とかどうしてるんだろう、
と思う今日このごろなレスもかつては書いてしまった気もします。
ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。
新しい粘着対象、2ch語、AAを知るとカキコしたくなるというのは
ネラーの真っ当な感情だと思いますが、下手に書き込むとまわりが被害をこうむりますかも。
あと、伝染性がある上に発病期間までに時間があったりすることも。
ちゃんとテストして(スレの空気を読んで)、これは行けると踏んでから、
まずはリスクの少ないカキコからレスしていきましょうと(予防接種)。
スレの流れとネタに対して何の寄与もしないどころか、
足を引っ張るだけの>>332に釣られちゃった僕は
別な何かが見える様になったと思います。
思い起こせば、2chを覚えたてのころはageを乱用し、
スレ立てを知れば(見ている板にとって)意味のないスレを量産し、
カキコしている本人はご満悦ですが、ROMする人とかどうしてるんだろう、
と思う今日このごろなレスもかつては書いてしまった気もします。
ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。
新しい粘着対象、2ch語、AAを知るとカキコしたくなるというのは
ネラーの真っ当な感情だと思いますが、下手に書き込むとまわりが被害をこうむりますかも。
あと、伝染性がある上に発病期間までに時間があったりすることも。
ちゃんとテストして(スレの空気を読んで)、これは行けると踏んでから、
まずはリスクの少ないカキコからレスしていきましょうと(予防接種)。
スレの流れとネタに対して何の寄与もしないどころか、
足を引っ張るだけの>>332に釣られちゃった僕は
別な何かが見える様になったと思います。
441 ：デフォルトの名無しさん：04/11/18 02:15:22
元ネタ
http://d.hatena.ne.jp/taichitaichi/20041116#p1
しみじみ読んじゃったよ。うーむ。
俺も今、中学男みたいに頭のなかタップンタップンで
抗体が出来てないんだろうなあ。
http://d.hatena.ne.jp/taichitaichi/20041116#p1
しみじみ読んじゃったよ。うーむ。
俺も今、中学男みたいに頭のなかタップンタップンで
抗体が出来てないんだろうなあ。
442 ：デフォルトの名無しさん：04/11/18 02:21:15
443 ：デフォルトの名無しさん：04/11/18 02:23:10
1の思惑をはるかに飛び越えて立派なネタスレになった。
思えば dependncy な時点でネタスレ化は必定だった。
思えば dependncy な時点でネタスレ化は必定だった。
444 ：デフォルトの名無しさん：04/11/18 02:35:15
445 ：デフォルトの名無しさん：04/11/18 02:36:46
>>444
とりあえず今夜も呼んどくか。
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
とりあえず今夜も呼んどくか。
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
446 ：デフォルトの名無しさん：04/11/18 02:37:49
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
447 ：デフォルトの名無しさん：04/11/18 02:38:09
448 ：デフォルトの名無しさん：04/11/18 02:42:07
>>213-214のコンボは何度見ても壮観だな。
449 ：デフォルトの名無しさん：04/11/18 02:51:10
ttp://www.bandai.co.jp/item/images/1/2/4543112222404000.jpg
DI は既存コンテナをうまく流用するとして、
II はこんな感じでやってみようと思う。
DI は既存コンテナをうまく流用するとして、
II はこんな感じでやってみようと思う。
450 ：デフォルトの名無しさん：04/11/18 02:52:39
オブジェクト指向が必要ないんなら、DIも必要ないじゃねぇか。
451 ：デフォルトの名無しさん：04/11/18 02:53:59
剛の者かネタか。
誰かつついて確認しる!
誰かつついて確認しる!
452 ：デフォルトの名無しさん：04/11/18 02:56:08
>>451
そんなことしたら、また寝れなくなるだろ。
そんなことしたら、また寝れなくなるだろ。
453 ：デフォルトの名無しさん：04/11/18 03:00:33
>>449
ザクIIかよ！
ザクIIかよ！
454 ：デフォルトの名無しさん：04/11/18 03:01:33
>>450
オブジェクト指向が必要なら、DIも必要じゃねぇか。
オブジェクト指向が必要なら、DIも必要じゃねぇか。
455 ：デフォルトの名無しさん：04/11/18 03:04:49
はっきり言って、業務アプリは、関数だけあれば作れます。間違い無い。
継承すらイラナイかもしれない。と思う今日この頃。
DIなんて不要。間違い無い。
せいぜい流行語大賞。間違い無い。
継承すらイラナイかもしれない。と思う今日この頃。
DIなんて不要。間違い無い。
せいぜい流行語大賞。間違い無い。
456 ：デフォルトの名無しさん：04/11/18 03:05:05
akon氏がくーすのことを「21世紀の手続き型」とか言ってたような。
良い意味で悪い大人だな。
良い意味で悪い大人だな。
457 ：デフォルトの名無しさん：04/11/18 03:05:29
>454
そんなことを書くとピュアOO厨が現れるぞ。
ちょっと期待してるんだがな。
そんなことを書くとピュアOO厨が現れるぞ。
ちょっと期待してるんだがな。
458 ：デフォルトの名無しさん：04/11/18 03:08:11
>>455
間違い無いは流行語大賞にノミネートされませんでしたから！残念！！
間違い無いは流行語大賞にノミネートされませんでしたから！残念！！
459 ：デフォルトの名無しさん：04/11/18 03:10:05
まあそういう話なら、業務アプリはマクロアセンブラさえあれば作れるんじゃないか？
460 ：デフォルトの名無しさん：04/11/18 03:10:32
むしろ、業務アプリなど必要ない。
461 ：デフォルトの名無しさん：04/11/18 03:11:37
むしろ、お前が必要ない。
462 ：デフォルトの名無しさん：04/11/18 03:12:20
オレは必要。オレさえいれば、DIなど不要。
463 ：デフォルトの名無しさん：04/11/18 03:13:08
やしろ、化粧など必要ない。
464 ：デフォルトの名無しさん：04/11/18 03:13:57
アレは必要。アレさえいれば、ﾃﾞﾋﾞなど不要。
465 ：デフォルトの名無しさん：04/11/18 03:14:07
DIがあるのでお前は不要。
466 ：デフォルトの名無しさん：04/11/18 03:15:15
たしろ、盗撮など必要…
467 ：デフォルトの名無しさん：04/11/18 03:19:47
トランザクションをちまちま書くことで工数が稼げるんです。
業務システムにはDIは不要です。
お偉いさんはそこがわかっとらんのです。
業務システムにはDIは不要です。
お偉いさんはそこがわかっとらんのです。
468 ：デフォルトの名無しさん：04/11/18 03:21:03
ネタとしていまいちだな。寝るよ。
469 ：デフォルトの名無しさん：04/11/18 03:21:46
言葉遊びだからな。
おやすみ。
おやすみ。
470 ：デフォルトの名無しさん：04/11/18 12:29:00
オッス！ オラ悟空！！
なんかこのスレの>>332から邪悪なでっけえ気を感じて来てみたんだけどよ。
・・・う・・あ・・・な、なんて気だ!!
今のオラじゃ、とてもかないそうにねぇ!!!
２０倍界王拳でも全然相手になりそうにねぇ!!!
でもよ、こんなにヤバイ状況だってのにオラ、ワクワクしてきたぞ!!!
この世にこんなつえぇ奴がまだ居たなんてよ!!
おっと、感激してる場合じゃねぇな。
なんとか>>332をやっつけねぇとな!!
こうなったら超特大の元気玉に賭けるしかねぇ!!!
みんなの元気をオラにわけてくれ
なんかこのスレの>>332から邪悪なでっけえ気を感じて来てみたんだけどよ。
・・・う・・あ・・・な、なんて気だ!!
今のオラじゃ、とてもかないそうにねぇ!!!
２０倍界王拳でも全然相手になりそうにねぇ!!!
でもよ、こんなにヤバイ状況だってのにオラ、ワクワクしてきたぞ!!!
この世にこんなつえぇ奴がまだ居たなんてよ!!
おっと、感激してる場合じゃねぇな。
なんとか>>332をやっつけねぇとな!!
こうなったら超特大の元気玉に賭けるしかねぇ!!!
みんなの元気をオラにわけてくれ
471 ：デフォルトの名無しさん：04/11/18 12:44:12
やだよ、ただでさえ元気ないのに
472 ：デフォルトの名無しさん：04/11/18 15:43:16
つ[无気]
473 ：デフォルトの名無しさん：04/11/18 18:21:30
DIなんて飾りですよ。
お偉いさんにはそれがわからんのです。
お偉いさんにはそれがわからんのです。
474 ：デフォルトの名無しさん：04/11/18 18:43:38
はっきりいう、気に入らんな（せりふのタイミング間違えた）
475 ：デフォルトの名無しさん：04/11/18 20:39:50
なんなら赤く塗りましょうか？
476 ：デフォルトの名無しさん：04/11/18 20:50:09
DIの勉強しようと思ってるんだけど、何がお勧め？
Seasar2かSpring かと思ってるんだけど、日本語の情報が多いのはSeasar2かな？
Seasar2でDIの勉強して問題ないですよね。
Seasar2かSpring かと思ってるんだけど、日本語の情報が多いのはSeasar2かな？
Seasar2でDIの勉強して問題ないですよね。
477 ：デフォルトの名無しさん：04/11/18 21:08:27
活字の情報はSpringの方が多いな。
ネットの情報だと、どっちも同じくらいじゃないの？
ネットの情報だと、どっちも同じくらいじゃないの？
478 ：デフォルトの名無しさん：04/11/18 21:14:57
漏れはS2派だが、まずはSpring触ることをお薦めする。
ある程度DIを理解したところで、他のDIコンテナにも触れてみるといいんじゃないかな。
ある程度DIを理解したところで、他のDIコンテナにも触れてみるといいんじゃないかな。
479 ：デフォルトの名無しさん：04/11/18 21:24:13
>>478
オレはSpring派っていうか、とりあえず今はSpring使っててSeasar2は使ってないんだが、その理由が気になる。
オレはSpring派っていうか、とりあえず今はSpring使っててSeasar2は使ってないんだが、その理由が気になる。
480 ：デフォルトの名無しさん：04/11/18 21:38:21
やっぱりDIの出発点だと思うから＜Spring
Springは一つの基準だと思うしJ2EEサーバが出始めた頃のWebLogicみたいなもんだと思ってる。
Springは一つの基準だと思うしJ2EEサーバが出始めた頃のWebLogicみたいなもんだと思ってる。
481 ：デフォルトの名無しさん：04/11/18 21:52:43
それはSpringから始める理由にはならんと思うなぁ。
482 ：デフォルトの名無しさん：04/11/18 22:00:19
勉強する目的が重要でしょ。
それによって勉強法が変ってくるだろうし。
それによって勉強法が変ってくるだろうし。
483 ：デフォルトの名無しさん：04/11/18 22:01:18
S2は、Rubyみたいな臭いがするのが不安なんだよね…。
国産、既存のものの焼き直し、国内でしか使われていない、という辺りが特に。
国産、既存のものの焼き直し、国内でしか使われていない、という辺りが特に。
484 ：デフォルトの名無しさん：04/11/18 22:01:25
>>479
S2から始めるとそれで満足してSpringに触る機会がなくなる。
Springから始めるとAOPの面倒さや不自然さに辟易し、
FactoryBeanなどSpringのAPIを使わないとできないことに悩まされて
S2もやってみようというモチベーションになる。
だから両方やりたいならSpringが先。
S2から始めるとそれで満足してSpringに触る機会がなくなる。
Springから始めるとAOPの面倒さや不自然さに辟易し、
FactoryBeanなどSpringのAPIを使わないとできないことに悩まされて
S2もやってみようというモチベーションになる。
だから両方やりたいならSpringが先。
Springからやってみます
みなさま㌧ｸｽｺ
みなさま㌧ｸｽｺ
486 ：デフォルトの名無しさん：04/11/18 22:12:11
そんな理由だったらわざわざ苦労して面倒なほうを触る必要も無いと思うんだけどね。
487 ：デフォルトの名無しさん：04/11/18 22:14:22
488 ：デフォルトの名無しさん：04/11/18 22:20:21
489 ：デフォルトの名無しさん：04/11/18 22:39:09
とりあえず今夜も呼んどくか。
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
490 ：デフォルトの名無しさん：04/11/18 22:53:12
>>488
デンパを発してないからなぁ
デンパを発してないからなぁ
491 ：デフォルトの名無しさん：04/11/18 22:59:04
S2の優位点って設定の容易さだけなのかな。
だとしたらSpringに仕様改善提案するなり
設定のフロントエンドだけ差し替えたりって対応も
ありだと思うんだが。
だとしたらSpringに仕様改善提案するなり
設定のフロントエンドだけ差し替えたりって対応も
ありだと思うんだが。
492 ：デフォルトの名無しさん：04/11/18 23:33:01
493 ：デフォルトの名無しさん：04/11/19 00:34:26
494 ：デフォルトの名無しさん：04/11/19 00:42:06
たしかにRubyはすでに海外でもメジャーになりつつあるね。英語本の翻訳本が存在するくらいだし。
日本が一番活発なコミュニティなんだろうけど、Groovyが出た時でも「Rubyのようなスクリプト言語の
利点を...」って海外でも紹介されてたし。
まあS2がそこまでいけるかどうかは、露出度次第だと思う。
でも今は露出より開発進めることじゃないかな。S2JSFとかS2Flexとか。
日本が一番活発なコミュニティなんだろうけど、Groovyが出た時でも「Rubyのようなスクリプト言語の
利点を...」って海外でも紹介されてたし。
まあS2がそこまでいけるかどうかは、露出度次第だと思う。
でも今は露出より開発進めることじゃないかな。S2JSFとかS2Flexとか。
495 ：デフォルトの名無しさん：04/11/19 01:14:31
大事なのは、酒を飲むことです。
496 ：デフォルトの名無しさん：04/11/19 06:22:35
497 ：デフォルトの名無しさん：04/11/19 16:29:38
面倒なことくらい分かりきってるのに
(<property name="hoge">... よりも <hoge>.. の方が
特殊な性癖の御仁を除けば読みやすいだろう。)
あえて採用してるところからして、永久未来クドいままだろう。
(<property name="hoge">... よりも <hoge>.. の方が
特殊な性癖の御仁を除けば読みやすいだろう。)
あえて採用してるところからして、永久未来クドいままだろう。
498 ：デフォルトの名無しさん：04/11/19 19:02:57
499 ：デフォルトの名無しさん：04/11/19 19:06:34
失礼。問題にしてるのは読みやすさか。だったらコードアシストは関係なかったな。
そういう観点からすると、groovyベースとかが主流になったほうが良いのは確かだね。
そういう観点からすると、groovyベースとかが主流になったほうが良いのは確かだね。
500 ：デフォルトの名無しさん：04/11/19 20:45:56
ということは、Spring用のツールが普及して定義ファイルを見なくてよくなることがあれば、Seasarはアボーンってことか？
もしくは、某通信大手系企業の問題の上司が電通国際以下略に転職して
「オープンソースにコントリビュート以下略」
と言い出したらSeasarあぼーんってことですね。
もしくは、某通信大手系企業の問題の上司が電通国際以下略に転職して
「オープンソースにコントリビュート以下略」
と言い出したらSeasarあぼーんってことですね。
501 ：デフォルトの名無しさん：04/11/19 21:25:34
結論：所詮一時の流行病だった。
502 ：デフォルトの名無しさん：04/11/19 23:04:06
そして、DIが定着してDIという言葉を聞かなくなった頃、DIコンテナベースのフレームワークを使いながらやはりDIって不要だったなと思う501
503 ：デフォルトの名無しさん：04/11/19 23:34:58
そして今日も俺は213ﾀﾝの登場を待つのだった。
504 ：デフォルトの名無しさん：04/11/20 00:50:20
505 ：デフォルトの名無しさん：04/11/20 00:52:53
506 ：デフォルトの名無しさん：04/11/20 00:55:12
507 ：デフォルトの名無しさん：04/11/20 00:56:48
504氏は新しいタイプのネタ？
S2信者を装ってSpring派との分断を謀る策士に違いない。
S2信者を装ってSpring派との分断を謀る策士に違いない。
508 ：デフォルトの名無しさん：04/11/20 01:08:09
>>506
あぁ、つまり、現状で定義ファイルの記述が楽だから過渡的にSeasar使ってるだけで、Springのいい感じのツールが広まったらSpring使えばいいってことね。
あぁ、つまり、現状で定義ファイルの記述が楽だから過渡的にSeasar使ってるだけで、Springのいい感じのツールが広まったらSpring使えばいいってことね。
509 ：デフォルトの名無しさん：04/11/20 01:09:04
510 ：デフォルトの名無しさん：04/11/20 01:10:49
511 ：デフォルトの名無しさん：04/11/20 01:34:15
512 ：デフォルトの名無しさん：04/11/20 01:37:49
とりあえず今夜も呼んどくか。
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
513 ：デフォルトの名無しさん：04/11/20 01:38:56
>>510
こんなんが使えるようになれば、それはそれで鬱陶しくていいかも。
ttp://www.springframework.org/spring-ide/eclipse/BeansGraph.png
こんなんが使えるようになれば、それはそれで鬱陶しくていいかも。
ttp://www.springframework.org/spring-ide/eclipse/BeansGraph.png
514 ：デフォルトの名無しさん：04/11/20 01:39:16
515 ：デフォルトの名無しさん：04/11/20 01:45:29
>>513
アンチDI厨が喜んで叩いてきそうだ
アンチDI厨が喜んで叩いてきそうだ
一応種明かししておくが、513の画面はリードオンリーね。
517 ：デフォルトの名無しさん：04/11/20 12:06:06
仕様書より先にコーディングするＤＱＮのコードを解析する為のものか…。
518 ：デフォルトの名無しさん：04/11/20 12:39:50
>>517
いや、ただSpringのBean定義を表示するだけ。
いや、ただSpringのBean定義を表示するだけ。
519 ：デフォルトの名無しさん：04/11/20 12:55:22
>>295
>Interface interface = new Impl();
>このようなコードをソース中に書いてしまうと、Interfaceの実装を切り替えることが困難になってしまう。
ちなみにRubyなんかだとImpl.newメソッドをオーバライドして一時的に
別のオブジェクト返せるね
特別なことしなくても、オーバライドによるポリモーフィズムという簡単な概念で解決できるのはシンプルでよいと思うよ。
>Interface interface = new Impl();
>このようなコードをソース中に書いてしまうと、Interfaceの実装を切り替えることが困難になってしまう。
ちなみにRubyなんかだとImpl.newメソッドをオーバライドして一時的に
別のオブジェクト返せるね
特別なことしなくても、オーバライドによるポリモーフィズムという簡単な概念で解決できるのはシンプルでよいと思うよ。
520 ：デフォルトの名無しさん：04/11/20 18:04:53
多態厨のコードは意味も無く複雑で読みづらい罠。
拡張なんか一度もしなかったし。
拡張なんか一度もしなかったし。
521 ：デフォルトの名無しさん：04/11/21 12:19:15
newをオーバーライドできるって、ものすごくコードが信頼できなくなるね。
522 ：デフォルトの名無しさん：04/11/21 15:21:09
> 自分もリーダーの立場になることが多く、
> 要件定義から入り実装ではフレームワーク構築を担当することも多い。
> 同い年や年配の方に、(自分には単純作業にしか思えない)作業を割り振ることも多い。
> いつも、彼らにすまなく思ってしまう。
> 俺は彼らの創造性や向上心を数ヶ月の間そいでしまっているのではないかと。
それは方法論の問題でも何でもない。あなたがリーダーとして未熟なだけ。
単純作業であっても必要な作業であれば、きちんと必要性を説明して動機付けするのがリーダーの役割。
創造性や向上心をそぐのは道具ではなくあなたのリーダーシップの問題。
すまなく思うようなことをそのまま指示してしまっているのはあなた自身。
それを問題だと感じているならば自分で改善しないとね。
> 要件定義から入り実装ではフレームワーク構築を担当することも多い。
> 同い年や年配の方に、(自分には単純作業にしか思えない)作業を割り振ることも多い。
> いつも、彼らにすまなく思ってしまう。
> 俺は彼らの創造性や向上心を数ヶ月の間そいでしまっているのではないかと。
それは方法論の問題でも何でもない。あなたがリーダーとして未熟なだけ。
単純作業であっても必要な作業であれば、きちんと必要性を説明して動機付けするのがリーダーの役割。
創造性や向上心をそぐのは道具ではなくあなたのリーダーシップの問題。
すまなく思うようなことをそのまま指示してしまっているのはあなた自身。
それを問題だと感じているならば自分で改善しないとね。
523 ：デフォルトの名無しさん：04/11/21 15:54:35
>>522
スレ違い。
スレ違い。
524 ：デフォルトの名無しさん：04/11/21 21:30:51
>>523
S2スレでネタやるよりはマシ。次善の策ということで。
S2スレでネタやるよりはマシ。次善の策ということで。
525 ：デフォルトの名無しさん：04/11/21 21:40:05
何が次善の策なのか。
スレ違いうざいんだよ。
スレ違いうざいんだよ。
526 ：デフォルトの名無しさん：04/11/21 21:42:00
あっちが荒れるよりは、こっちが荒れる方がマシって事だろう＞次善の策
どっちも中身の無さでは大差ないけどなｗ
どっちも中身の無さでは大差ないけどなｗ
527 ：デフォルトの名無しさん：04/11/21 21:45:02
あっちでスルーしてればいいだけじゃん。わざわざ別のスレ荒らす理由にはならん。
それとも図星指されて顔真っ赤ですか？
それとも図星指されて顔真っ赤ですか？
528 ：デフォルトの名無しさん：04/11/21 21:45:56
今夜は俺が呼ぼう。
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
529 ：デフォルトの名無しさん：04/11/21 21:47:58
530 ：デフォルトの名無しさん：04/11/21 21:58:28
内容は悪くないな。
531 ：デフォルトの名無しさん：04/11/21 22:17:10
お前のように。
532 ：デフォルトの名無しさん：04/11/21 22:52:47
はなはだ疑問の解説がある。
533 ：デフォルトの名無しさん：04/11/21 23:05:42
策定メンバーとあるが
534 ：デフォルトの名無しさん：04/11/22 10:57:04
535 ：デフォルトの名無しさん：04/11/22 22:42:37
>>528
久々に見にきたらまだそんなネタ引っぱてんのか。
コピペする暇あったら、俺みたいに >>213 や >>332、ひが君うんこ
とか書けよ。殺伐としたｲﾝﾀｰﾈｯﾂは嫌いか w
つーか、おまいら DI 語らんくせにﾈﾀのひとつも書けんのか。
くだらん。うんこスレか禿スレに戻るか。
久々に見にきたらまだそんなネタ引っぱてんのか。
コピペする暇あったら、俺みたいに >>213 や >>332、ひが君うんこ
とか書けよ。殺伐としたｲﾝﾀｰﾈｯﾂは嫌いか w
つーか、おまいら DI 語らんくせにﾈﾀのひとつも書けんのか。
くだらん。うんこスレか禿スレに戻るか。
536 ：デフォルトの名無しさん：04/11/23 00:12:52
537 ：デフォルトの名無しさん：04/11/23 00:36:27
NetBeansはBean定義ファイルからオブジェクト生成コードを自動生成するというおもしろいDIのしくみをもっています。
最古のDIコンテナはDelphiです。
Delphiはフォームデザインをコンポーネント定義ファイルに保存して、Application.createFormとするとコンポーネント定義にしたがったフォームを生成してくれます。
最古のDIコンテナはDelphiです。
Delphiはフォームデザインをコンポーネント定義ファイルに保存して、Application.createFormとするとコンポーネント定義にしたがったフォームを生成してくれます。
538 ：デフォルトの名無しさん：04/11/23 00:53:40
Delphiはデータベースのコネクションなど非視覚部品もコンポーネントとして配置できたり、自分で自由にコンポーネントを作成できたりしたので、まさにDIコンテナです。
VBはそこらへん弱かった。
VBはそこらへん弱かった。
540 ：デフォルトの名無しさん：04/11/23 01:17:20
>>535のように暇じゃないのでコピペする時間も惜しい。だから今夜も俺が予防
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
541 ：デフォルトの名無しさん：04/11/23 01:18:21
542 ：デフォルトの名無しさん：04/11/23 01:23:25
543 ：デフォルトの名無しさん：04/11/23 01:57:36
>>537
どのへんがDependencyのInjectionになってるのかよーわからん。
どのへんがDependencyのInjectionになってるのかよーわからん。
544 ：デフォルトの名無しさん：04/11/23 02:03:39
どっちのこと？
NetBeansも、フォーム定義からフォームとボタンの間に依存性を注入するコードを生成するわけだし。
Delphiは、完全にDIコンテナだよ。
データベースとフォームを関連付けるのに、コードを書く必要はない。
フォーム定義は、ビーン定義になってる。
ただフォームエディタで見た目をいじくれるようになっているからコンポーネントが重いだけ。
DIコンテナの要件にPOxOであることが含まれるなら、DIコンテナではない、という程度。
NetBeansも、フォーム定義からフォームとボタンの間に依存性を注入するコードを生成するわけだし。
Delphiは、完全にDIコンテナだよ。
データベースとフォームを関連付けるのに、コードを書く必要はない。
フォーム定義は、ビーン定義になってる。
ただフォームエディタで見た目をいじくれるようになっているからコンポーネントが重いだけ。
DIコンテナの要件にPOxOであることが含まれるなら、DIコンテナではない、という程度。
545 ：デフォルトの名無しさん：04/11/23 02:27:03
>>541
ｵｻｰﾝは黙ってろ。
ｵｻｰﾝは黙ってろ。
546 ：デフォルトの名無しさん：04/11/23 02:28:55
>>544
えーと。あんた自動なら、なんでも DI か。おめでたいな。
えーと。あんた自動なら、なんでも DI か。おめでたいな。
547 ：デフォルトの名無しさん：04/11/23 02:31:03
548 ：デフォルトの名無しさん：04/11/23 02:33:06
>>544
で、それは type なにになるの？ 新しい type か？
で、それは type なにになるの？ 新しい type か？
549 ：デフォルトの名無しさん：04/11/23 02:37:51
550 ：デフォルトの名無しさん：04/11/23 02:42:06
ここは英単語の前後に半角スペースが多いｲﾝﾀｰﾈｯﾄですね。
551 ：デフォルトの名無しさん：04/11/23 02:45:13
明日以降は↓でよろしく>all
☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
552 ：デフォルトの名無しさん：04/11/23 02:52:22
偽者だと言われて本物と主張しては話にならん。
再三の召喚要請にもかかわらず
214 をなかったことにしてこそ 213 タン。
ステレオタイプなかたりでは DI スレは踊れない。
>550
読みやすくて好きだよ。
再三の召喚要請にもかかわらず
214 をなかったことにしてこそ 213 タン。
ステレオタイプなかたりでは DI スレは踊れない。
>550
読みやすくて好きだよ。
553 ：デフォルトの名無しさん：04/11/23 02:57:46
554 ：デフォルトの名無しさん：04/11/23 02:58:59
555 ：デフォルトの名無しさん：04/11/23 03:00:03
556 ：デフォルトの名無しさん：04/11/23 03:08:30
>>552
あー、召喚要請って、そんなん忙しくて毎日見れるか。
毎日、いろんな各社のプロジェクトまわって、ダメダメ独自ドメインフレーム
ワーク設計の欠陥を指摘してんだよ。最近、AOP や DI を意識して中途半端な
ものを作ろうとしてるアーキテクトが多い。
あー、召喚要請って、そんなん忙しくて毎日見れるか。
毎日、いろんな各社のプロジェクトまわって、ダメダメ独自ドメインフレーム
ワーク設計の欠陥を指摘してんだよ。最近、AOP や DI を意識して中途半端な
ものを作ろうとしてるアーキテクトが多い。
557 ：デフォルトの名無しさん：04/11/23 03:16:35
そんな使い古されたカタカナ使わないよ。
DI+IIくらいにインパクトある言葉を想像する御仁だ、彼は。
DI+IIくらいにインパクトある言葉を想像する御仁だ、彼は。
558 ：デフォルトの名無しさん：04/11/23 03:22:43
やっぱり偽者だね。
559 ：デフォルトの名無しさん：04/11/23 03:31:00
>>557
よく分からんが DI + II がそんなにネタとしてハマったのか？
俺は新しい用語が好きだ。たぶんおまいらもそうなんだろう。
これは Java で言えることかもしれんが、マニアは新しい言葉つけるの好きだな。
ロッドとかファウラーとかね。 マニア受けするんだろな。
俺は会社まわってアーキテクトに説明するときに、極力新しい用語は使わん。
もちろん的確にハマって、かつ、受け入れられやすいものは使うが。
PG がバカじゃなくて、新しい用語使いまくって PG に説明するアーキテクトが
バカなんだ。
よく分からんが DI + II がそんなにネタとしてハマったのか？
俺は新しい用語が好きだ。たぶんおまいらもそうなんだろう。
これは Java で言えることかもしれんが、マニアは新しい言葉つけるの好きだな。
ロッドとかファウラーとかね。 マニア受けするんだろな。
俺は会社まわってアーキテクトに説明するときに、極力新しい用語は使わん。
もちろん的確にハマって、かつ、受け入れられやすいものは使うが。
PG がバカじゃなくて、新しい用語使いまくって PG に説明するアーキテクトが
バカなんだ。
560 ：デフォルトの名無しさん：04/11/23 03:34:24
>>558
んー、煽ってんの？ 俺は仕事でも 2ch でも感情なんかないから。
んー、煽ってんの？ 俺は仕事でも 2ch でも感情なんかないから。
561 ：デフォルトの名無しさん：04/11/23 03:36:55
Netbeansはただのコードジェネレーションだし、Delphiはただのコンポーネントじゃないか？
だいたい定義ファイルから定義を読み込んでオブジェクトを生成するだけなら、はるか昔から
あるだろ。NeXTSTEPなんかどうなるんだよ。
おれは「実行時にもインターフェイスさえ同じなら好きに実装を差し替えられる」ってのはDIの
要件の一つだと思うけど、Netbeansではそれはできんわな。コンパイル前のソースを生成す
るんだから。
まあ、DIだってすんごく新しい発見というわけではなく、発想の転換なんだろうけどね。
だいたい定義ファイルから定義を読み込んでオブジェクトを生成するだけなら、はるか昔から
あるだろ。NeXTSTEPなんかどうなるんだよ。
おれは「実行時にもインターフェイスさえ同じなら好きに実装を差し替えられる」ってのはDIの
要件の一つだと思うけど、Netbeansではそれはできんわな。コンパイル前のソースを生成す
るんだから。
まあ、DIだってすんごく新しい発見というわけではなく、発想の転換なんだろうけどね。
562 ：デフォルトの名無しさん：04/11/23 03:39:58
563 ：デフォルトの名無しさん：04/11/23 03:42:58
>>562
なんだ、調べんのに時間かかったな。
なんだ、調べんのに時間かかったな。
564 ：デフォルトの名無しさん：04/11/23 03:56:33
> Netbeansはただのコードジェネレーションだし、Delphiはただのコンポーネントじゃないか？
それを言うなら、SeasarとかSpringとかをただのXML-Objectマッピングだし、ただのクラスじゃないか、といってしまえる。
で、そういうことがSeasarとかSpringがDIじゃないということにはならないでしょ。
ただのコードジェネレーションがDIじゃないことにはつながらないし、ただのコンポーネントがDIコンテナじゃないことにはつながらないと思う。
NetBeansの場合は、DI「コンテナ」ではないと思うけど。
Delphi(or C++Builder)でコンポーネントを作ったことがある人とかだと、あれはDIだわ、って思ってくれるはず。
フォームエディタの印象しかない人には、その部分はDIとしてはイビツなのでDIじゃないと思うんだろうけど。
インジェクションされるためにはPOxOじゃだめだからね。
でも、名前からオブジェクトをとってこれるし、そのとき関連のあるオブジェクトは勝手に生成して関連付けてくれてるし、やりたきゃコンポーネント定義のXMLファイル手書きできるし、まったくDIコンテナだよ。
それを言うなら、SeasarとかSpringとかをただのXML-Objectマッピングだし、ただのクラスじゃないか、といってしまえる。
で、そういうことがSeasarとかSpringがDIじゃないということにはならないでしょ。
ただのコードジェネレーションがDIじゃないことにはつながらないし、ただのコンポーネントがDIコンテナじゃないことにはつながらないと思う。
NetBeansの場合は、DI「コンテナ」ではないと思うけど。
Delphi(or C++Builder)でコンポーネントを作ったことがある人とかだと、あれはDIだわ、って思ってくれるはず。
フォームエディタの印象しかない人には、その部分はDIとしてはイビツなのでDIじゃないと思うんだろうけど。
インジェクションされるためにはPOxOじゃだめだからね。
でも、名前からオブジェクトをとってこれるし、そのとき関連のあるオブジェクトは勝手に生成して関連付けてくれてるし、やりたきゃコンポーネント定義のXMLファイル手書きできるし、まったくDIコンテナだよ。
565 ：デフォルトの名無しさん：04/11/23 04:02:29
オブジェクトとってくるときに、そのたびごとに生成するか、一個だけオブジェクト用意しておくか、っていうのも選べる。
566 ：デフォルトの名無しさん：04/11/23 04:10:02
>>565はそこまで大それたもんじゃなかった気がする。起動時に変数としてもってるかもってないか、程度。
567 ：デフォルトの名無しさん：04/11/23 04:11:15
>>564
じゃー、俺と彼女はどっちが DI コンテナ？
じゃー、俺と彼女はどっちが DI コンテナ？
568 ：デフォルトの名無しさん：04/11/23 04:12:20
知り合ったきっかけの共通の友達。
つまり合コンの幹事。
つまり合コンの幹事。
569 ：デフォルトの名無しさん：04/11/23 04:17:42
>>568
職業から女の子集めてこれるし、そのとき好みの女の子の隣に勝手に座らせてくれるし、お気に入りの娘がいりゃ呼びたい女の子リクエストできるし、まったくDIコンテナだよ。
職業から女の子集めてこれるし、そのとき好みの女の子の隣に勝手に座らせてくれるし、お気に入りの娘がいりゃ呼びたい女の子リクエストできるし、まったくDIコンテナだよ。
570 ：デフォルトの名無しさん：04/11/23 04:18:56
インジェクションされるためにはPlain Old Japanese Boyじゃだめだ罠
571 ：デフォルトの名無しさん：04/11/23 10:22:52
572 ：デフォルトの名無しさん：04/11/23 10:24:08
573 ：デフォルトの名無しさん：04/11/23 10:25:43
>>549
駄目です。全然お前使えません。
駄目です。全然お前使えません。
574 ：デフォルトの名無しさん：04/11/23 15:57:38
575 ：デフォルトの名無しさん：04/11/23 16:24:00
576 ：デフォルトの名無しさん：04/11/23 18:43:04
>>535
こいつは真性の構ってｸｿだったのか。
こいつは真性の構ってｸｿだったのか。
577 ：デフォルトの名無しさん：04/11/23 19:30:21
久しぶりにスレが深夜に進んだので
もしかしてご本人様だったのかもと思ってみることにした。
しかし踊れなかった。
もしかしてご本人様だったのかもと思ってみることにした。
しかし踊れなかった。
578 ：デフォルトの名無しさん：04/11/23 21:57:26
>>576
そうだな。お前みたいに構うバカがいるからな w
そうだな。お前みたいに構うバカがいるからな w
579 ：デフォルトの名無しさん：04/11/23 22:24:29
580 ：デフォルトの名無しさん：04/11/23 23:13:06
ところで、
．ＮＥＴのＤＩコンテナって使ってる人いる？
いたら使い勝手とか信頼性とかその他について感想を聞かせて欲しいんですけど。
．ＮＥＴのＤＩコンテナって使ってる人いる？
いたら使い勝手とか信頼性とかその他について感想を聞かせて欲しいんですけど。
581 ：デフォルトの名無しさん：04/11/24 01:58:40
このスレはネタスレから普通のスレに戻りました。
3日後くらいにレスつくといいね。>>580
3日後くらいにレスつくといいね。>>580
582 ：デフォルトの名無しさん：04/11/24 05:24:06
>>580
.NETって、MSとか売り物のコンポーネントで間に合う分には、DIってあまり欲しくならないかも。
.NETって、MSとか売り物のコンポーネントで間に合う分には、DIってあまり欲しくならないかも。
583 ：デフォルトの名無しさん：04/11/24 07:02:04
「DelphiがDIコンテナ」ということにすると、.NETフレームワーク自体も重量DIコンテナということができる。
で、.NETではその重さを手軽に使えるツールと豊富なコンポーネントでカバーしてるから、その環境で満足できる分には改めて軽量DIコンテナが必要ないんじゃないかと。
で、.NETではその重さを手軽に使えるツールと豊富なコンポーネントでカバーしてるから、その環境で満足できる分には改めて軽量DIコンテナが必要ないんじゃないかと。
584 ：デフォルトの名無しさん：04/11/24 10:31:25
そもそもCOMが…以下(ry
585 ：デフォルトの名無しさん：04/11/24 13:04:21
586 ：デフォルトの名無しさん：04/11/24 13:22:58
これが燃料として機能するのは Spring スレにおいてではないか？
あのスレ閑散としてるし、投下してもむしろ歓迎されかねないが。
あのスレ閑散としてるし、投下してもむしろ歓迎されかねないが。
587 ：デフォルトの名無しさん：04/11/24 13:36:59
588 ：デフォルトの名無しさん：04/11/24 22:22:59
どうもギター侍ネタが寒くてイライラしてヤなんだが
それはまぁひが氏のせいじゃなくて時代が悪いんだよね。
いろんな意味で Ruby の初期のスタンスと同じ空気を感じる。
ところで method injection とやらは、どんなものなの？
それはまぁひが氏のせいじゃなくて時代が悪いんだよね。
いろんな意味で Ruby の初期のスタンスと同じ空気を感じる。
ところで method injection とやらは、どんなものなの？
589 ：デフォルトの名無しさん：04/11/24 23:13:35
590 ：デフォルトの名無しさん：04/11/24 23:32:38
じゃあ>>588のために呼んでおくか
☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>213ﾀﾝ再登場まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>332ﾀﾝDI + II まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
591 ：デフォルトの名無しさん：04/11/24 23:39:34
>>588
> ところで method injection とやらは、どんなものなの？
調べろボケ。
http://homepage3.nifty.com/seasar/DIContainer.html#MethodInjection
> ところで method injection とやらは、どんなものなの？
調べろボケ。
http://homepage3.nifty.com/seasar/DIContainer.html#MethodInjection
592 ：デフォルトの名無しさん：04/11/24 23:47:08
>>591
すぐに教えるなよ。
空気読んで少し引っ張ってほしかったとは思ったが。
>>588はついでにこっちも嫁。
ttp://www.springframework.org/docs/reference/beans.html#beans-factory-method-injection
すぐに教えるなよ。
空気読んで少し引っ張ってほしかったとは思ったが。
>>588はついでにこっちも嫁。
ttp://www.springframework.org/docs/reference/beans.html#beans-factory-method-injection
593 ：デフォルトの名無しさん：04/11/24 23:48:53
内容は悪くないな。
594 ：デフォルトの名無しさん：04/11/24 23:55:01
>591-591
thx.読む。
thx.読む。
>>592
「んー、煽ってんの？ 俺は仕事でも 2ch でも感情なんかないから。」
「んー、煽ってんの？ 俺は仕事でも 2ch でも感情なんかないから。」
596 ：デフォルトの名無しさん：04/11/24 23:57:17
マニア受けするんだろな。
597 ：デフォルトの名無しさん：04/11/24 23:59:32
お前のように。
598 ：デフォルトの名無しさん：04/11/25 00:01:21
偽者ばっかりだな。
599 ：デフォルトの名無しさん：04/11/25 00:05:57
>>594
大人な反応だな。荒らしてくれると思ったのに。
大人な反応だな。荒らしてくれると思ったのに。
600 ：デフォルトの名無しさん：04/11/25 00:13:10
601 ：デフォルトの名無しさん：04/11/25 00:26:13
>599
俺、普通にS2とSpringの差が気になってるんで。
ネタスレではあるけど普通にDIの話がなされるなら
それはそれで勉強になるので助かる。
流しだけどS2のリンク先文書の該当部分と該当サンプルは読んだ。
Spring の文書は英語なんで午前中にマターリと読んでみる。
Spring で大部分の処理の前に共通処理挟もうとして
IntroductionAdivce と BeforeAdvice で格闘した挙句
思うようにいかなかったことがあったので
正直、かなり興味を抱いている。
俺、普通にS2とSpringの差が気になってるんで。
ネタスレではあるけど普通にDIの話がなされるなら
それはそれで勉強になるので助かる。
流しだけどS2のリンク先文書の該当部分と該当サンプルは読んだ。
Spring の文書は英語なんで午前中にマターリと読んでみる。
Spring で大部分の処理の前に共通処理挟もうとして
IntroductionAdivce と BeforeAdvice で格闘した挙句
思うようにいかなかったことがあったので
正直、かなり興味を抱いている。
602 ：デフォルトの名無しさん：04/12/02 12:17:32
603 ：デフォルトの名無しさん：04/12/02 12:20:41
604 ：デフォルトの名無しさん：04/12/04 23:15:34
「問題の有無」⇔「問題の程度」
話のすり替え
話のすり替え
605 ：デフォルトの名無しさん：04/12/07 23:36:00
ttp://arton.no-ip.info/diary/20041207.html#p01
俺様Service Locator厨の人、呼ばれてるよ。
俺様Service Locator厨の人、呼ばれてるよ。
606 ：デフォルトの名無しさん：04/12/15 01:52:10
おおDIスレよ、しんでしまうとはなさけない
607 ：デフォルトの名無しさん：04/12/27 16:05:32
608 ：デフォルトの名無しさん：05/02/18 23:08:01
バカが征くでDI是非議論出てるね。
609 ：デフォルトの名無しさん：05/03/06 11:58:40
610 ：デフォルトの名無しさん：2005/06/11(土) 14:41:50
Spring等を勉強してみてDIの基本はわかったつもりなんだけど、
重要なのはインターフェイスベースのプログラミングであって、DIを使うことではない気がしてきた
例えばWebアプリなら、StrutsのActionクラスやJSFのManaged Beanを使い捨て用と位置づけて
DIならファイルで定義するようなオブジェクトFactory部分やJTAによるトランザクション定義等をベタに書いてやれば
ビジネスロジック部分やデータアクセス層はインターフェイスベースで作成出来るし、Javaの型チェックも有効になるので
わざわざXML定義するより良い気がするんだけどな
重要なのはインターフェイスベースのプログラミングであって、DIを使うことではない気がしてきた
例えばWebアプリなら、StrutsのActionクラスやJSFのManaged Beanを使い捨て用と位置づけて
DIならファイルで定義するようなオブジェクトFactory部分やJTAによるトランザクション定義等をベタに書いてやれば
ビジネスロジック部分やデータアクセス層はインターフェイスベースで作成出来るし、Javaの型チェックも有効になるので
わざわざXML定義するより良い気がするんだけどな
611 ：デフォルトの名無しさん：2005/06/11(土) 20:12:58
>>610
「重要なのはDIパターンを使うことであって、
DIコンテナを使うことではない気がしてきた」
という話ですね？
>>605のリンク先にDIコンテナの利点が４点書かれています。
> 1.設定が一箇所。ServiceLocatorはロケータ毎に設定が分かれる。
> 2.実装が（基本的に）1つ。ServiceLocatorはロケータ毎に1実装。
> 3.DIコンテナアプローチであればユニットテスト用モックは不要。
> 4.DIコンテナアプローチはプッシュモデルなので自然。
DIパターンは3、4を実現できます。
PicoContainerは2、3、4を実現できます。
SpringやSeasar2は1、2、3、4を実現できます。
1と2のメリットをJavaの型チェックが無効で
コンテナ実装が必要というデメリットと比較して
DIコンテナの採用可否を決める事になります。
ごく小さなソフトならDIパターンを自力実装、
小規模なソフトならPicoContainerを採用、
中規模以上ならSpringやSeasar2を採用、
というのが妥当な判断だと思います。
「重要なのはDIパターンを使うことであって、
DIコンテナを使うことではない気がしてきた」
という話ですね？
>>605のリンク先にDIコンテナの利点が４点書かれています。
> 1.設定が一箇所。ServiceLocatorはロケータ毎に設定が分かれる。
> 2.実装が（基本的に）1つ。ServiceLocatorはロケータ毎に1実装。
> 3.DIコンテナアプローチであればユニットテスト用モックは不要。
> 4.DIコンテナアプローチはプッシュモデルなので自然。
DIパターンは3、4を実現できます。
PicoContainerは2、3、4を実現できます。
SpringやSeasar2は1、2、3、4を実現できます。
1と2のメリットをJavaの型チェックが無効で
コンテナ実装が必要というデメリットと比較して
DIコンテナの採用可否を決める事になります。
ごく小さなソフトならDIパターンを自力実装、
小規模なソフトならPicoContainerを採用、
中規模以上ならSpringやSeasar2を採用、
というのが妥当な判断だと思います。
612 ：デフォルトの名無しさん：2005/06/11(土) 21:41:20
何で聞き返してんの?
613 ：デフォルトの名無しさん：2005/06/11(土) 21:46:23
中規模以下なら、自分で作ったりPicoやらSeasarやら資料が少ないDIコンテナ使うよりは、本屋に書籍が並んでるSpringの方が手軽だと思われ。
614 ：デフォルトの名無しさん：2005/06/11(土) 22:15:00
別にPicoはサイトにある５分間チュートリアルで充分なくらい単純だと思うけど....
615 ：デフォルトの名無しさん：2005/06/11(土) 22:44:42
データアクセス層やらトランザクション管理やら考えれば、現実的には役に立たんでしょ。
616 ：デフォルトの名無しさん：2005/06/11(土) 23:07:01
Picoでそこまでやるならそれこそ１から書き起こしても大して変わらん。
て言うか、普通はやらない。
Picoの利点は単なるファクトリと同等の手軽さでもっと便利ってとこ。
PicoでSpringを置き換えよう等という無謀な事は誰も考えてない。
て言うか、普通はやらない。
Picoの利点は単なるファクトリと同等の手軽さでもっと便利ってとこ。
PicoでSpringを置き換えよう等という無謀な事は誰も考えてない。
617 ：デフォルトの名無しさん：2005/06/11(土) 23:56:33
データアクセスやらトランザクション管理やらはコンテナの機能であって、どちらかというとAOPの領域。
DIパターンとは関係がなかろう。
DIパターンとは関係がなかろう。
618 ：デフォルトの名無しさん：2005/06/12(日) 00:32:11
関係あるよ。AOPはDIで織り込むのが主流だから、関係あるよ。
619 ：デフォルトの名無しさん：2005/06/12(日) 00:41:41
だからお前は知ったかぶって、訳のわかんないレス付けんなって。
620 ：デフォルトの名無しさん：2005/06/12(日) 01:10:12
知らないこと言われたら知ったかぶりだと思うのは悪い癖だよ。
621 ：デフォルトの名無しさん：2005/06/12(日) 01:14:44
ああぁぁあ底抜けのバカだな。
じゃ説明してみろ、その「DIで織り込む」という空前絶後の駄法螺をさぁ
じゃ説明してみろ、その「DIで織り込む」という空前絶後の駄法螺をさぁ
622 ：デフォルトの名無しさん：2005/06/12(日) 01:15:33
ああぁぁあ底抜けのバカだな。
じゃ説明してみろ、その「AOPをDIで織り込む」という空前絶後の駄法螺をさぁ
じゃ説明してみろ、その「AOPをDIで織り込む」という空前絶後の駄法螺をさぁ
623 ：デフォルトの名無しさん：2005/06/12(日) 01:19:38
624 ：デフォルトの名無しさん：2005/06/12(日) 01:27:51
>>621-622
とりあえずもちつけ
とりあえずもちつけ
625 ：デフォルトの名無しさん：2005/06/12(日) 01:36:37
とにかく話題をそらさずちゃんと説明してみろ
その「AOPをDIで織り込む」という空前絶後の駄法螺をさぁ
その「AOPをDIで織り込む」という空前絶後の駄法螺をさぁ
626 ：デフォルトの名無しさん：2005/06/12(日) 01:53:39
いいからもちつけ
627 ：デフォルトの名無しさん：2005/06/12(日) 01:55:21
なんか概念と実装の区別がついてない奴がいるな
628 ：デフォルトの名無しさん：2005/06/12(日) 01:55:25
DIコンテナの大部分が実装的にAOPと「相性がいい」のは事実だし、ほとんどのDIコンテナは
AOP機能を取り込んでるが、両者は全く別々に産まれた概念だろ。DI機能限定のPicoContainerが
ある一方で、DIがなくてもAOPをどんなアプリでも使えるAspectWerkzなんてのもある。
DIとAOPは別の概念。組み合わせると利点は多いが、DIはAOP機能も持ってないといけない、と
考えるとDIパターンとは何か、というところを誤解する可能性大。
AOP機能を取り込んでるが、両者は全く別々に産まれた概念だろ。DI機能限定のPicoContainerが
ある一方で、DIがなくてもAOPをどんなアプリでも使えるAspectWerkzなんてのもある。
DIとAOPは別の概念。組み合わせると利点は多いが、DIはAOP機能も持ってないといけない、と
考えるとDIパターンとは何か、というところを誤解する可能性大。
629 ：デフォルトの名無しさん：2005/06/12(日) 01:58:41
631 ：デフォルトの名無しさん：2005/06/12(日) 02:05:28
>>618は妄想の産物を自信たっぷりに語るハッタリ厨房ｹﾃｰｲ
632 ：デフォルトの名無しさん：2005/06/12(日) 02:05:48
ま、一言で言うと”ゴミ”だな。
633 ：デフォルトの名無しさん：2005/06/12(日) 02:08:13
人間のゴミがなんかｺﾞﾁｬｺﾞﾁｬと言ってる(>>632)けど、デフォで放置。
634 ：610：2005/06/12(日) 02:19:17
>>611
私はServiceLocatorが良いといってるのではないのであしからず
XMLに定義する内容を敢えてActionクラス等にベタ書きすることによって
ビジネスロジック、データアクセス関連にはDIパターンが適用出来るし
トランザクション機能等についても、呼び出し側でJTAを利用すれば
ビジネスロジックやDAO側はAOP機能を使った場合と同等の記述が出来る（AOPの恩恵は受けてないが）
ユニットテストについても、ビジネスロジック以降のクラスはDIコンテナ利用時と同じようにテスト出来るし・・・
最近のプロジェクト（DIコンテナは採用されてない）で、DIパターンを意識して書いてたら
自然とコントローラ系のクラスにそういう定義を集中して書くようになったので
とりあえずDIコンテナ導入の前段階としても有効じゃないかなと思ったし
この呼び出し側のクラスをメンテするのと、XMLファイル定義をメンテするのと
果たしてどちらがメンドくさいだろうかとふと思ったりもしたので、今回書き込んでみました。
私はServiceLocatorが良いといってるのではないのであしからず
XMLに定義する内容を敢えてActionクラス等にベタ書きすることによって
ビジネスロジック、データアクセス関連にはDIパターンが適用出来るし
トランザクション機能等についても、呼び出し側でJTAを利用すれば
ビジネスロジックやDAO側はAOP機能を使った場合と同等の記述が出来る（AOPの恩恵は受けてないが）
ユニットテストについても、ビジネスロジック以降のクラスはDIコンテナ利用時と同じようにテスト出来るし・・・
最近のプロジェクト（DIコンテナは採用されてない）で、DIパターンを意識して書いてたら
自然とコントローラ系のクラスにそういう定義を集中して書くようになったので
とりあえずDIコンテナ導入の前段階としても有効じゃないかなと思ったし
この呼び出し側のクラスをメンテするのと、XMLファイル定義をメンテするのと
果たしてどちらがメンドくさいだろうかとふと思ったりもしたので、今回書き込んでみました。
635 ：デフォルトの名無しさん：2005/06/12(日) 02:21:33
議論が破綻すると、破綻前にロールバックして議論再開か。
便利な機能だな（ｗ
便利な機能だな（ｗ
636 ：デフォルトの名無しさん：2005/06/12(日) 02:30:30
>>635
いや、レス番をpoint cutとし、>>611をjoint pointとする
立派なアスペクト指向ハックなんだよ、>>634は。
そして、この場合のcross cutting concernsは、
「破綻した議論で、自分の誤りを認める事なしに議論を継続する」
というソフィスト共通の課題なんだ。。。
いや、レス番をpoint cutとし、>>611をjoint pointとする
立派なアスペクト指向ハックなんだよ、>>634は。
そして、この場合のcross cutting concernsは、
「破綻した議論で、自分の誤りを認める事なしに議論を継続する」
というソフィスト共通の課題なんだ。。。
637 ：デフォルトの名無しさん：2005/06/12(日) 02:43:37
とにかくもちつけ
638 ：デフォルトの名無しさん：2005/06/12(日) 03:01:58
ﾜﾛﾀ
639 ：デフォルトの名無しさん：2005/06/12(日) 04:15:53
AspectJのような言語仕様にアスペクトを盛り込むものが全然普及しなかった状況みれば、DIでAOPが現実解だとおもうんだけどなぁ。
640 ：デフォルトの名無しさん：2005/06/12(日) 08:59:28
641 ：デフォルトの名無しさん：2005/06/12(日) 09:01:10
642 ：デフォルトの名無しさん：2005/06/12(日) 09:45:51
pico にも AOP の機能はあるよ。(nano-aop とか)
ドキュメントの量を考えれば他使った方がいいと思うけど。
ドキュメントの量を考えれば他使った方がいいと思うけど。
643 ：デフォルトの名無しさん：2005/06/12(日) 15:16:21
644 ：デフォルトの名無しさん：2005/06/13(月) 10:47:20
>>643
信仰の力です。
信仰の力です。
645 ：デフォルトの名無しさん：2005/06/13(月) 22:35:04
つまらん
646 ：デフォルトの名無しさん：2005/06/19(日) 02:47:09
DIパターンなる語の定義に詳しくなくて申し訳ないんだが
611氏の実践したことはDIなんだろうか？
依存性が思いっきりコントローラ系クラスに書かれてるのに
これ以上どんな依存性をどこから注入すると言うのだろう。
ソースファイルのメンテと設定ファイルのメンテに関しては
同一システムを別の設定で使う場合を想定してみれば答えが分かる。
ソースファイルをブランチ分けてバージョン管理するのと
設定ファイルを分けるのとどっちが楽か。
人それぞれかもしれないけど、俺は後者の方が圧倒的に楽に感じた。
611氏の実践したことはDIなんだろうか？
依存性が思いっきりコントローラ系クラスに書かれてるのに
これ以上どんな依存性をどこから注入すると言うのだろう。
ソースファイルのメンテと設定ファイルのメンテに関しては
同一システムを別の設定で使う場合を想定してみれば答えが分かる。
ソースファイルをブランチ分けてバージョン管理するのと
設定ファイルを分けるのとどっちが楽か。
人それぞれかもしれないけど、俺は後者の方が圧倒的に楽に感じた。
647 ：デフォルトの名無しさん：2005/06/19(日) 02:47:58
そして610(634)氏の間違いだったことに今気づいた。
648 ：デフォルトの名無しさん：2005/06/19(日) 22:19:10
Seasar2のひがやすをさんは公演でDIはオープンクローズドを実現するための
強制ギプスのようなものだと言っていたよ
強制ギプスのようなものだと言っていたよ
649 ：デフォルトの名無しさん：2005/06/20(月) 20:12:23
なんでみんな依存しないようにしないようにって言うんですか！
仲よくてもいいじゃない.
そんなに依存性を語るのが好きなの！
依存性を頑張って低くしたソースの再利用率教えてよ.
とかバカな事言ってみる.
仲よくてもいいじゃない.
そんなに依存性を語るのが好きなの！
依存性を頑張って低くしたソースの再利用率教えてよ.
とかバカな事言ってみる.
650 ：デフォルトの名無しさん：2005/06/20(月) 21:42:46
業務アプリの場合、重要なのは、
再利用性というより、移行性だなぁ。
あとテスト容易性とか。
再利用性というより、移行性だなぁ。
あとテスト容易性とか。
651 ：デフォルトの名無しさん：2005/06/20(月) 22:57:41
いや、業務アプリの場合仕様変更にどれだけ強いかということなんじゃないかな
652 ：デフォルトの名無しさん：2005/06/21(火) 00:23:57
人が死なないこと。
これ大事。
これ大事。
653 ：デフォルトの名無しさん：2005/06/21(火) 06:01:27
いや、DI つうか、OOPだろうが AOP だろうが XP だろうが RUP だろうが、
人の生き死にまでは面倒みれませんから。
人の生き死にまでは面倒みれませんから。
654 ：610：2005/06/21(火) 08:07:31
>>646
今はStrutsのActionクラスをコントローラで使うことが多いので
そもそもActionはサーブレットAPIとStruts関連APIの依存性が強いクラスだから
このクラスにはあまり汎用的なことを書かない。
struts-config.xmlを中心に、どのURLからどの処理を呼んでるのか確認をする為にも、
Actionクラスはどんなクラスを利用しているのかわかりやすい方が個人的に良いと思った。
Springの連携機能を使うと、struts-configだけでは何を呼び出してるのかわけわからなくなり
springの設定ファイルと合わせてメンテナンスしなければいけなくなる。そこまでしてActionに依存性注入する必要があるのかな？
ようするにActionを使い捨てにするかしないかという話。
JSFのManagedBeanなら、普通のJavaBeanをコントローラとして利用できるから、JSFが主流になれば自分の見解は変わるだろうけど
あと、warやjarによる運用の場合は、必要以上に設定ファイルに分ける意義があまり見出せない。
当然変更箇所が最小限になるように設定部分は集約する必要があるけど、ソースであるのを避ける必要性をあまり感じない
今はStrutsのActionクラスをコントローラで使うことが多いので
そもそもActionはサーブレットAPIとStruts関連APIの依存性が強いクラスだから
このクラスにはあまり汎用的なことを書かない。
struts-config.xmlを中心に、どのURLからどの処理を呼んでるのか確認をする為にも、
Actionクラスはどんなクラスを利用しているのかわかりやすい方が個人的に良いと思った。
Springの連携機能を使うと、struts-configだけでは何を呼び出してるのかわけわからなくなり
springの設定ファイルと合わせてメンテナンスしなければいけなくなる。そこまでしてActionに依存性注入する必要があるのかな？
ようするにActionを使い捨てにするかしないかという話。
JSFのManagedBeanなら、普通のJavaBeanをコントローラとして利用できるから、JSFが主流になれば自分の見解は変わるだろうけど
あと、warやjarによる運用の場合は、必要以上に設定ファイルに分ける意義があまり見出せない。
当然変更箇所が最小限になるように設定部分は集約する必要があるけど、ソースであるのを避ける必要性をあまり感じない
655 ：デフォルトの名無しさん：2005/06/21(火) 09:29:32
>>653
「これからはOOPだ」という号令のもと、慣れない言語に手を出して、デスマって自殺とか。
「これからはOOPだ」という号令のもと、慣れない言語に手を出して、デスマって自殺とか。
656 ：デフォルトの名無しさん：2005/06/21(火) 10:20:52
仕様変更に強い設計もいいけど
いの一番には
仕様変更があった時に
どこを変更したらいいか凄くわかり易い設計
がいいな。
いの一番には
仕様変更があった時に
どこを変更したらいいか凄くわかり易い設計
がいいな。
657 ：デフォルトの名無しさん：2005/06/21(火) 13:55:05
>>653
学習期間ってのは見逃されがちな問題だよね。
ぶっちゃけ、DIを使う場合って、
1.DI「される」コードだけをコーディング規約に従って作るだけの人。
2.アーキテクチャを設計して、DI「する」コードやコーディング規約を作る人。
に二分化されるような気がする。
「これからは DI だ！」とかいって、1 のレベル（かその手前のレベル）の人しかいないのに、
実プロジェクトで無理やり DI 使わせたら・・・。
学習期間ってのは見逃されがちな問題だよね。
ぶっちゃけ、DIを使う場合って、
1.DI「される」コードだけをコーディング規約に従って作るだけの人。
2.アーキテクチャを設計して、DI「する」コードやコーディング規約を作る人。
に二分化されるような気がする。
「これからは DI だ！」とかいって、1 のレベル（かその手前のレベル）の人しかいないのに、
実プロジェクトで無理やり DI 使わせたら・・・。
658 ：デフォルトの名無しさん：2005/06/21(火) 14:08:56
訳わかんない人が多いプロジェクトが、見栄と体面で導入するようなもんじゃないだろ。
それが自然な流れだと感じられる人が多ければ、皆勉強して意見合わせできるだろうし。
それが自然な流れだと感じられる人が多ければ、皆勉強して意見合わせできるだろうし。
659 ：デフォルトの名無しさん：2005/06/21(火) 21:44:31
>>654
Actionにセッターを書くことになるから、依存性は一目でわかるよ。
Actionにセッターを書くことになるから、依存性は一目でわかるよ。
660 ：デフォルトの名無しさん：2005/06/21(火) 23:01:48
DIコンテナ設定ファイルに記述が分散しちまうから見にくいつう話題でそ
661 ：デフォルトの名無しさん：2005/06/22(水) 01:11:46
いや、setAaa(Aaa aaa)みたいなセッターがあれば、Aaaクラスのオブジェクトが設定されるわけで。
で、Aaaクラスのオブジェクトは、だいたいシングルトンなんで、DI設定みなくてもわかることのほうが多い。
気になるならXDocletで集中管理ですよ、と。
そのうちアノテーション対応で設定ファイル不要になるし。
で、Aaaクラスのオブジェクトは、だいたいシングルトンなんで、DI設定みなくてもわかることのほうが多い。
気になるならXDocletで集中管理ですよ、と。
そのうちアノテーション対応で設定ファイル不要になるし。
662 ：デフォルトの名無しさん：2005/06/22(水) 08:36:37
Aaaは普通インターフェイスで定義するんじゃないの？
普通の実装クラスを引数の型に定義するんじゃ、そもそもDIする意味が無いのだが
実際にどの実装クラスをセットするかは、DIコンテナの設定ファイルを見ないとわからない筈
普通の実装クラスを引数の型に定義するんじゃ、そもそもDIする意味が無いのだが
実際にどの実装クラスをセットするかは、DIコンテナの設定ファイルを見ないとわからない筈
663 ：デフォルトの名無しさん：2005/06/22(水) 09:39:29
664 ：デフォルトの名無しさん：2005/06/22(水) 16:06:43
>>658
現実問題として、「皆勉強して意見合わせ」なんて、
少数精鋭でやってる中小のソフトハウスとか
技術コンサルタント会社とかでしかありえない。
大部分の企業の開発現場では、「DI？何それ」って人間を使って
開発を運用もできるようにしなきゃならん。
現実問題として、「皆勉強して意見合わせ」なんて、
少数精鋭でやってる中小のソフトハウスとか
技術コンサルタント会社とかでしかありえない。
大部分の企業の開発現場では、「DI？何それ」って人間を使って
開発を運用もできるようにしなきゃならん。
665 ：デフォルトの名無しさん：2005/06/22(水) 16:27:49
666 ：デフォルトの名無しさん：2005/06/22(水) 16:33:53
667 ：デフォルトの名無しさん：2005/06/22(水) 16:40:42
うん、俺も荒れてる現場で仕事やってる奴とは話が合わないから、降りるよ
668 ：デフォルトの名無しさん：2005/06/22(水) 16:57:37
669 ：デフォルトの名無しさん：2005/06/22(水) 21:08:46
>>668
意味不明。実際に適用する際には重要な話。
意味不明。実際に適用する際には重要な話。
670 ：デフォルトの名無しさん：2005/06/22(水) 21:10:13
いやだからさ、そんなリスク管理もできないんだったら、
安全になってから来りゃえぇ～やん。じゃね、バイバイ
安全になってから来りゃえぇ～やん。じゃね、バイバイ
671 ：デフォルトの名無しさん：2005/06/22(水) 21:13:30
きっと他の人が作った新技術に目を付けて、
「導入教育」と称して商売するコンサルの人でしょ。
「導入教育」と称して商売するコンサルの人でしょ。
672 ：デフォルトの名無しさん：2005/06/22(水) 22:22:51
つうか、なんでそんなに興奮するの？
673 ：デフォルトの名無しさん：2005/06/22(水) 22:58:41
なんでいつもそんなに必死なの？
674 ：デフォルトの名無しさん：2005/06/23(木) 12:51:42
>>669
DI のおおまかな考え方や、実際のインプリメンテーションを評価するのに
そんなに学習コストはかからないと思うが。
これぐらいの技術を適用するぐらいで問題になるくらいの職場なんか、
はっきり言って問題外。
DI のおおまかな考え方や、実際のインプリメンテーションを評価するのに
そんなに学習コストはかからないと思うが。
これぐらいの技術を適用するぐらいで問題になるくらいの職場なんか、
はっきり言って問題外。
675 ：デフォルトの名無しさん：2005/06/23(木) 13:00:57
676 ：デフォルトの名無しさん：2005/06/23(木) 13:13:44
677 ：デフォルトの名無しさん：2005/06/23(木) 13:47:27
678 ：デフォルトの名無しさん：2005/06/23(木) 14:35:38
ちなみにアプレットはJavaScriptではないわけだが…
679 ：デフォルトの名無しさん：2005/06/23(木) 15:00:39
680 ：デフォルトの名無しさん：2005/06/23(木) 15:21:49
10年前にDIっていう言葉はないわけだが。
・・・似た言葉すらなかったところが問題なわけか。orz
継承はステキだからみんなオブジェクト指向でハッピー、サーバーとのやりとりもリモートオブジェクトでハッピーですよ、っていう時代か。
・・・似た言葉すらなかったところが問題なわけか。orz
継承はステキだからみんなオブジェクト指向でハッピー、サーバーとのやりとりもリモートオブジェクトでハッピーですよ、っていう時代か。
681 ：デフォルトの名無しさん：2005/06/24(金) 01:25:26
>>680
そしてDIも同じ道を。
そしてDIも同じ道を。
682 ：デフォルトの名無しさん：2005/06/24(金) 01:40:59
オブジェクト指向があたりまえになったように、DIもあたりまえになる。
683 ：デフォルトの名無しさん：2005/06/24(金) 02:18:31
多重継承が廃れたようにDIも（ｒ
684 ：デフォルトの名無しさん：2005/06/24(金) 02:37:19
多重継承はC++ではバリバリ現役だけどな
685 ：デフォルトの名無しさん：2005/06/24(金) 04:06:11
Javaではインターフェイスとして生き残ってるけどな
686 ：デフォルトの名無しさん：2005/06/24(金) 22:54:02
インターフェイス継承なわけだが。
687 ：デフォルトの名無しさん：2005/06/24(金) 23:30:11
public class whale implements flyable {
について
について
688 ：デフォルトの名無しさん：2005/06/25(土) 00:49:27
まあオブジェクトを組み立てる為の指図書みたいなもんか。
689 ：デフォルトの名無しさん：2005/06/25(土) 00:58:56
// >>687 括弧閉じてないし
}
}
690 ：デフォルトの名無しさん：2005/06/25(土) 02:23:08
について
688 名前：デフォルトの名無しさん 本日のレス 投稿日：2005/06/25(土) 00:49:27
まあオブジェクトを組み立てる為の指図書みたいなもんか。
689 名前：デフォルトの名無しさん 本日のレス 投稿日：2005/06/25(土) 00:58:56
の部分でエラーになるのだがどうか。
688 名前：デフォルトの名無しさん 本日のレス 投稿日：2005/06/25(土) 00:49:27
まあオブジェクトを組み立てる為の指図書みたいなもんか。
689 名前：デフォルトの名無しさん 本日のレス 投稿日：2005/06/25(土) 00:58:56
の部分でエラーになるのだがどうか。
691 ：デフォルトの名無しさん：2005/06/25(土) 02:29:08
パス。
692 ：デフォルトの名無しさん：2005/06/25(土) 08:38:42
STLが結局流行らなかったようにDIも（ｒ
693 ：デフォルトの名無しさん：2005/06/25(土) 09:47:57
>>692
STL、むちゃくちゃはやってるだろ
STL、むちゃくちゃはやってるだろ
694 ：デフォルトの名無しさん：2005/06/25(土) 12:47:29
俺使ったことないし俺の周りでも使ってるやつがいない。
695 ：デフォルトの名無しさん：2005/06/25(土) 15:24:27
>>694
あわれだな
あわれだな
696 ：デフォルトの名無しさん：2005/06/26(日) 10:06:48
Java(というか静的型有り言語)以外でDIが使いものになるか試した人いる？
Seasar2でS2PHP5とかあるのは知っているけど、
試してみるかなあ？
DIのような仕組みが流行するのは
Javaが静的型有り言語だからじゃないかと思っているんだが。
それと、Ruby on Rails の Convention over Configuration
の説明を読んでると、 DI でしばしば使われる設定ファイルが
冗長にみえる(コードで設定することも可能なんだろうけど)
Seasar2でS2PHP5とかあるのは知っているけど、
試してみるかなあ？
DIのような仕組みが流行するのは
Javaが静的型有り言語だからじゃないかと思っているんだが。
それと、Ruby on Rails の Convention over Configuration
の説明を読んでると、 DI でしばしば使われる設定ファイルが
冗長にみえる(コードで設定することも可能なんだろうけど)
697 ：デフォルトの名無しさん：2005/06/26(日) 12:09:21
picocontainer は .NET/Ruby/PHP 版の予定があるみたい
Ruby 版、Rico はもう動くんじゃない?
Ruby 版、Rico はもう動くんじゃない?
698 ：デフォルトの名無しさん：2005/06/27(月) 13:59:52
akabekoいんじゃね？Rubyだし。
699 ：デフォルトの名無しさん：2005/07/07(木) 23:13:09
>>698
akabekoのサンプルソースをよんでみたけど、
結論としてはRubyらしくない。
(SeasarがJavaから出てきたので、仕方が無いのだろうけど)
Rubyらしくない点
* XMLって読みにくい。
* OGNL みたいな新しい言語を覚えたいか？(PHPや.NETでもそうかも)
diconファイルをCopeland みたいに YAMLで指定できないかな。
で、サンプルを見てもDependency Injectionの良さが分からないんだけど、
動的型無し言語でDIの何が良いのか教えて欲しい。
>>17 で指摘されているような
インターフェースによる設計は型無し言語だと出来ない(やるとしたらDuck Typingか)
他にテストの網羅率が上がるということが指摘されているけど、
実際に有効かどうか私にはよくわからない。
akabekoのサンプルソースをよんでみたけど、
結論としてはRubyらしくない。
(SeasarがJavaから出てきたので、仕方が無いのだろうけど)
Rubyらしくない点
* XMLって読みにくい。
* OGNL みたいな新しい言語を覚えたいか？(PHPや.NETでもそうかも)
diconファイルをCopeland みたいに YAMLで指定できないかな。
で、サンプルを見てもDependency Injectionの良さが分からないんだけど、
動的型無し言語でDIの何が良いのか教えて欲しい。
>>17 で指摘されているような
インターフェースによる設計は型無し言語だと出来ない(やるとしたらDuck Typingか)
他にテストの網羅率が上がるということが指摘されているけど、
実際に有効かどうか私にはよくわからない。
700 ：デフォルトの名無しさん：2005/07/08(金) 00:09:59
701 ：デフォルトの名無しさん：2005/07/08(金) 01:03:53
>> インターフェイスによる設計が必要なのは、Javaだからだよ。
>> 必要ないと思う。
へーそうなの、Rubyって。
Lisp経験長いけど、直感的に意味がわからない。
それは俺が型システムマンセーだからなのか？
>> 必要ないと思う。
へーそうなの、Rubyって。
Lisp経験長いけど、直感的に意味がわからない。
それは俺が型システムマンセーだからなのか？
702 ：デフォルトの名無しさん：2005/07/08(金) 01:09:23
703 ：デフォルトの名無しさん：2005/07/09(土) 02:20:28
型い事言うなよ。
704 ：デフォルトの名無しさん：2005/07/09(土) 02:54:15
>>703
未定義です
未定義です
705 ：デフォルトの名無しさん：2005/07/09(土) 03:06:54
＝＝＝＝
頭悪過ぎ。
＝＝＝＝
頭悪過ぎ。
＝＝＝＝
706 ：デフォルトの名無しさん：2005/07/09(土) 05:12:35
>>702
インターフェースの定義をどう考えている？
インターフェースによる設計という言葉がまずかったみたいだけど、
>>699 では Javaでいうところの
interface Greeting {
String greeting();
String reply();
}
のようなインターフェースを指している。
DIで出来るかはわからないけど、これを使えば
実行前にインターフェースとしての型の一致は保障されるはず。
インターフェースの定義をどう考えている？
インターフェースによる設計という言葉がまずかったみたいだけど、
>>699 では Javaでいうところの
interface Greeting {
String greeting();
String reply();
}
のようなインターフェースを指している。
DIで出来るかはわからないけど、これを使えば
実行前にインターフェースとしての型の一致は保障されるはず。
707 ：デフォルトの名無しさん：2005/07/09(土) 05:56:02
>>706
実行前に型の一致を保証するのは、Javaのinterfaceの役目でDIの役目ではないね。
もともと静的型保証しないんだから、メソッド名と引数が一致するものがあればいいわけで。
DIはオブジェクトの結びつけがやりたいんだから、型保証できるかできないかは言語の特性次第。
実行前に型の一致を保証するのは、Javaのinterfaceの役目でDIの役目ではないね。
もともと静的型保証しないんだから、メソッド名と引数が一致するものがあればいいわけで。
DIはオブジェクトの結びつけがやりたいんだから、型保証できるかできないかは言語の特性次第。
708 ：デフォルトの名無しさん：2005/07/10(日) 14:56:08
>>707
Seasar2をつかっているわけじゃないけど、
Seasar2にはautoBindingなるものがあって
interfaceをもとにオブジェクトの連環を作ることが出来る。
(これが便利なのか危険なのか判断が難しいんだが)
ttp://www.seasar.org/DIContainer.html#AutoBindingMode
> メソッド名と引数が一致するものがあればいいわけで。
これがDuck Typing（だと自分では思っている）。
型無し言語におけるDIにはこれをサポートして欲しいかも
Seasar2をつかっているわけじゃないけど、
Seasar2にはautoBindingなるものがあって
interfaceをもとにオブジェクトの連環を作ることが出来る。
(これが便利なのか危険なのか判断が難しいんだが)
ttp://www.seasar.org/DIContainer.html#AutoBindingMode
> メソッド名と引数が一致するものがあればいいわけで。
これがDuck Typing（だと自分では思っている）。
型無し言語におけるDIにはこれをサポートして欲しいかも
709 ：デフォルトの名無しさん：2005/07/11(月) 04:09:34
>>708
> > メソッド名と引数が一致するものがあればいいわけで。
> これがDuck Typing（だと自分では思っている）。
> 型無し言語におけるDIにはこれをサポートして欲しいかも
実際にメソッドがコールされるときまでInjectionを遅らせて、メソッド名と引数が一致するオブジェクトを動的に探す…とか妄想してたが、
複数一致ばかりになりそうなので、結局シンボルのようなものをつけて判別するしかないような。うーむ悩ましい。
> > メソッド名と引数が一致するものがあればいいわけで。
> これがDuck Typing（だと自分では思っている）。
> 型無し言語におけるDIにはこれをサポートして欲しいかも
実際にメソッドがコールされるときまでInjectionを遅らせて、メソッド名と引数が一致するオブジェクトを動的に探す…とか妄想してたが、
複数一致ばかりになりそうなので、結局シンボルのようなものをつけて判別するしかないような。うーむ悩ましい。
710 ：デフォルトの名無しさん：2005/07/27(水) 01:07:42
２つ程質問させてください。
StrutsとSpringの組み合わせで、StrutsのアクションクラスにDIした場合、
DIされるクラスがステートレスじゃない場合には、スレッドセーフでは
なくなるんでしょうか？
逆にDIされるクラスが、ステートレスであれば、Singltonでもそうでなくても
スレッドセーフであるといえるのでしょうか？
イメージとしては、下のコードみたいな感じです。
class Action1 ・・・ { // strutsのアクションクラス
Logic1 logic;
setLogic1(Logic1 logic1) {
logic = logic1;
}
execute(・・・) {
logic1.setState(100);
logic1.calcState();
logic1.getResult();
}
}
StrutsとSpringの組み合わせで、StrutsのアクションクラスにDIした場合、
DIされるクラスがステートレスじゃない場合には、スレッドセーフでは
なくなるんでしょうか？
逆にDIされるクラスが、ステートレスであれば、Singltonでもそうでなくても
スレッドセーフであるといえるのでしょうか？
イメージとしては、下のコードみたいな感じです。
class Action1 ・・・ { // strutsのアクションクラス
Logic1 logic;
setLogic1(Logic1 logic1) {
logic = logic1;
}
execute(・・・) {
logic1.setState(100);
logic1.calcState();
logic1.getResult();
}
}
711 ：デフォルトの名無しさん：2005/07/27(水) 10:34:33
StrutsやSpringをする前に、Javaの基本を勉強したほうがいいよ
712 ：デフォルトの名無しさん：2005/08/08(月) 16:21:38
Springのトランザクション管理で、TransactionProxyFactoryBeanを使っています。
すべてのトランザクションで、特定の例外が発生したらロールバックさせたいのですが、
一元的に設定する方法はありますか？
713 ：デフォルトの名無しさん：2005/08/08(月) 18:07:34
>>712
parentをつかう
parentをつかう
714 ：デフォルトの名無しさん：2005/08/08(月) 19:37:33
>>713
ありがとうございます。
parentを使った場合、親側でtransactionAttributesに、↓のように設定するってことなんでしょうか？
<prop key="*">PROPARGATION_REQUIRED, -MyException</prop>
これだと、結局子側で書いたtransactionAttributesで上書きされてしまってだめなんです。
それとも、ロールバック対象の例外は「MyException」ですって設定するってことができるんでしょうか？
ありがとうございます。
parentを使った場合、親側でtransactionAttributesに、↓のように設定するってことなんでしょうか？
<prop key="*">PROPARGATION_REQUIRED, -MyException</prop>
これだと、結局子側で書いたtransactionAttributesで上書きされてしまってだめなんです。
それとも、ロールバック対象の例外は「MyException」ですって設定するってことができるんでしょうか？
715 ：デフォルトの名無しさん：2005/09/24(土) 16:01:10
うっ、8/8から止まっているスレだったか。
ま、とりあえず質問します。
DIって、旧来からある、
String classname = XXUtil.getProperty(HOGE_KEY);
HelperBean bean = (HelperBean)Class.forName(classname).newInstance();
とかいうのと何が違うの？
ま、とりあえず質問します。
DIって、旧来からある、
String classname = XXUtil.getProperty(HOGE_KEY);
HelperBean bean = (HelperBean)Class.forName(classname).newInstance();
とかいうのと何が違うの？
716 ：デフォルトの名無しさん：2005/09/24(土) 17:03:41
>>715
XXUtil.getPropertyを毎回つくらなくてよい。
そのコードは単に生成するクラス名を外部から与えられるだけ。
そのオブジェクトに関連するものも対応付けてくれないし、シングルトンにすることもできない。
XXUtil.getPropertyを毎回つくらなくてよい。
そのコードは単に生成するクラス名を外部から与えられるだけ。
そのオブジェクトに関連するものも対応付けてくれないし、シングルトンにすることもできない。
717 ：デフォルトの名無しさん：2005/09/24(土) 17:26:11
さんきゅー。
じゃあ、
HelperBean bean = XXUtil.createBean(this);
とやって
createBean(Object o) {
String classname = XXUtil.getProperty(o.class.getName());
HelperBean bean = map_.get(classname);
if (bean == null) {
bean = (HelperBean)Class.forName(classname).newInstance();
map_.put(classname, bean);
}
retunr bean;
ってな感じで、さらにプールされたインスタンスを渡すか、
新しいインスタンスを作って渡すかを外部設定ファイルで
指定できるようにしたら、同じになりますか？
さらなる利点がDIにはありますか？
じゃあ、
HelperBean bean = XXUtil.createBean(this);
とやって
createBean(Object o) {
String classname = XXUtil.getProperty(o.class.getName());
HelperBean bean = map_.get(classname);
if (bean == null) {
bean = (HelperBean)Class.forName(classname).newInstance();
map_.put(classname, bean);
}
retunr bean;
ってな感じで、さらにプールされたインスタンスを渡すか、
新しいインスタンスを作って渡すかを外部設定ファイルで
指定できるようにしたら、同じになりますか？
さらなる利点がDIにはありますか？
718 ：デフォルトの名無しさん：2005/09/24(土) 20:23:14
>>717
同じになったらそれはDIコンテナじゃないのか？
同じになったらそれはDIコンテナじゃないのか？
719 ：デフォルトの名無しさん：2005/09/24(土) 20:26:28
あとはAOPの仕組みとか組み込んで。
720 ：デフォルトの名無しさん：2005/09/24(土) 20:39:17
>>717
関連するオブジェクトもひっぱってくるようにしてくれ。
関連するオブジェクトもひっぱってくるようにしてくれ。
721 ：デフォルトの名無しさん：2005/09/24(土) 22:50:27
そうするとコンテナというにはちょっと大げさな気がするんですが。
722 ：デフォルトの名無しさん：2005/09/24(土) 23:28:27
DIコンテナってのはそういうもんだ。
EJBコンテナなんてもっと大げさだ。
EJBコンテナなんてもっと大げさだ。
723 ：デフォルトの名無しさん：2005/09/25(日) 21:45:08
>721
同意。オレもそう思います。
http://log.giantech.jp/402
「生きてま」の中の人は "Multi Object Factory" がいいんじゃないって言ってて
オレもそっちの方がイイと思います。
とはいえ、いまさら名前を変えるのもちょっとね。
同意。オレもそう思います。
http://log.giantech.jp/402
「生きてま」の中の人は "Multi Object Factory" がいいんじゃないって言ってて
オレもそっちの方がイイと思います。
とはいえ、いまさら名前を変えるのもちょっとね。
724 ：デフォルトの名無しさん：2005/09/25(日) 22:32:05
コンテナという「のは」大げさってことね。
確かに。
確かに。
725 ：デフォルトの名無しさん：2005/09/26(月) 04:11:31
EJBコンテナみたいなおおげさなものはやめようよ、っていうスローガンでDIコンテナが出てきたわけだから、おおげさじゃなくて当たり前だし。
それより、DIコンテナが便利なのはDIの部分じゃなくて、どっちかというとAOPしてくれたりオブジェクト管理してくれたりするコンテナの部分だと思うんさ。
だから「DIってどこが便利なの？」っていう質問の答えがしどろもどろになるんじゃないかと。
それより、DIコンテナが便利なのはDIの部分じゃなくて、どっちかというとAOPしてくれたりオブジェクト管理してくれたりするコンテナの部分だと思うんさ。
だから「DIってどこが便利なの？」っていう質問の答えがしどろもどろになるんじゃないかと。
726 ：デフォルトの名無しさん：2005/09/26(月) 22:01:55
疎結合が進んで見通しが良くなるから
だまされたと思って使ってみろよって感じ。＞便利、、、というと違うな。
だまされたと思って使ってみろよって感じ。＞便利、、、というと違うな。
727 ：デフォルトの名無しさん：2005/09/28(水) 11:30:07
>>725>>726に同意。
うんうん、そんなに大げさなモンじゃないよ。
interfaceにimplを突っ込んでくれるBeanFactoryという位置付けでもいいんじゃない。
使えば便利で離せなくなるのはホント実感する。
あとAOP。漏れはトランザクションにしか使ってないけど、FooServiceImplが
メチャ明快・単純・短文になるのは一種の爽快感さえ覚えるよ。
うんうん、そんなに大げさなモンじゃないよ。
interfaceにimplを突っ込んでくれるBeanFactoryという位置付けでもいいんじゃない。
使えば便利で離せなくなるのはホント実感する。
あとAOP。漏れはトランザクションにしか使ってないけど、FooServiceImplが
メチャ明快・単純・短文になるのは一種の爽快感さえ覚えるよ。
728 ：デフォルトの名無しさん：2005/09/28(水) 13:53:06
AOPをトランザクション以外に使ってる人ってどんだけいるんだろ？
なんに使ってるんだろ？
なんに使ってるんだろ？
729 ：デフォルトの名無しさん：2005/09/28(水) 14:23:04
log
730 ：デフォルトの名無しさん：2005/09/28(水) 15:12:14
あぁ、そういえばそういう用途もあったね。
他にないかな。トランザクションとログ以外。
他にないかな。トランザクションとログ以外。
731 ：デフォルトの名無しさん：2005/09/28(水) 15:26:41
考えられるのはユーザー認証かな。
というか、ログインしたかのチェック。
URL直打ち防止などで。
というか、ログインしたかのチェック。
URL直打ち防止などで。
732 ：デフォルトの名無しさん：2005/09/28(水) 18:46:12
認証
733 ：デフォルトの名無しさん：2005/09/28(水) 19:10:45
でもさぁ、認証だったらP層でやるのが自然じゃないかい？
734 ：デフォルトの名無しさん：2005/09/28(水) 21:16:08
P層でAOPによる認証
735 ：デフォルトの名無しさん：2005/09/28(水) 22:09:53
フィルタでやるほうがいい気がする。
736 ：デフォルトの名無しさん：2005/09/28(水) 22:46:03
自分の場合、Webシステムとローカルで動かすバッチを同一基盤で構築する為に
トランザクション、ロギング、認証、エラー処理（エラー内容をJavaMailで管理者に投げる）
を全てAOPで構築したりした。
Webシステムオンリーだったら、認証とかはフィルタでもいいと思う
トランザクション、ロギング、認証、エラー処理（エラー内容をJavaMailで管理者に投げる）
を全てAOPで構築したりした。
Webシステムオンリーだったら、認証とかはフィルタでもいいと思う
737 ：デフォルトの名無しさん：2005/10/03(月) 17:19:48
ディペンデンシーーインジェクショーン！
738 ：デフォルトの名無しさん：2005/10/03(月) 17:59:31
リンかけ？
739 ：デフォルトの名無しさん：2005/10/03(月) 21:42:51
せいんとせいやだよ。
740 ：デフォルトの名無しさん：2005/10/10(月) 19:31:30
>>736
俺の周りでもそんな事やってる奴いたなー。
俺の周りでもそんな事やってる奴いたなー。
741 ：デフォルトの名無しさん：2005/10/10(月) 21:46:44
で、学習時間が短く、サンプルもあって、手軽に使える奴は
どれですか？
どれですか？
742 ：デフォルトの名無しさん：2005/10/10(月) 22:01:51
>>741が自作するDIコンテナ。
そのDIコンテナが一般公開されたとき、741は恐らく全く学習せずに利用することができる。
動作確認としてつかったものがそのままサンプルとして使える。
そして741にとって最も手軽に使えるだろう。
そのDIコンテナが一般公開されたとき、741は恐らく全く学習せずに利用することができる。
動作確認としてつかったものがそのままサンプルとして使える。
そして741にとって最も手軽に使えるだろう。
743 ：デフォルトの名無しさん：2005/10/11(火) 00:20:01
744 ：デフォルトの名無しさん：2005/10/11(火) 00:40:07
>>743
Seasar2、5分で使える。
Seasar2、5分で使える。
745 ：デフォルトの名無しさん：2005/10/11(火) 06:34:13
746 ：デフォルトの名無しさん：2005/10/11(火) 12:27:30
747 ：デフォルトの名無しさん：2005/10/11(火) 16:56:19
>>746
Seasar2知ってる人ならね。
Seasar2知ってる人ならね。
748 ：デフォルトの名無しさん：2005/10/11(火) 19:33:49
749 ：デフォルトの名無しさん：2005/10/11(火) 19:42:34
Seasarは、「5分でわかんなかったら使わなくていいよ」ってポリシーだから。
750 ：sage：2005/10/11(火) 20:32:14
OSC2005_Seminar.pptという資料を読んでいる途中で5分経ってしまいました。
もうあきらめた方がいいでしょうか。
もうあきらめた方がいいでしょうか。
751 ：デフォルトの名無しさん：2005/10/11(火) 20:38:10
sageる位置を失敗してしまった。もうだめぽ。
752 ：デフォルトの名無しさん：2005/10/11(火) 20:58:22
そう簡単に諦めるな。
上で数人が書いてる通り、やってみればそんなに難しいことじゃないのだよ。
「without EJB～!!」なんて叫び声が聞こえるせいで、高尚なツールのごとき
イメージを持っているのかもしれんが、漏れのごときヘタレマーでも使えるので
難度低いのは間違いない。
理屈から入るより、サンプルを動かして試した方が易しいと思ふ。
Seasar2入門書でもいいけど、書店で入門本が平積みになっているという点で
Springの方がとっつきやすいかもね。
上で数人が書いてる通り、やってみればそんなに難しいことじゃないのだよ。
「without EJB～!!」なんて叫び声が聞こえるせいで、高尚なツールのごとき
イメージを持っているのかもしれんが、漏れのごときヘタレマーでも使えるので
難度低いのは間違いない。
理屈から入るより、サンプルを動かして試した方が易しいと思ふ。
Seasar2入門書でもいいけど、書店で入門本が平積みになっているという点で
Springの方がとっつきやすいかもね。
753 ：デフォルトの名無しさん：2005/10/11(火) 21:34:32
>>748
そんなつもりはない。
質問者が求めてるDIContainer(S2Container)だけなら本当に5分で分かる。
とりあえず、明日は休みなんで真面目な質問には真面目に答えるよ。
ただし、DIContainerに何の意味があるの？とかの是非論は勘弁な。
とりあえず、DIContainerとは何か？って部分はＯＫ？
そんなつもりはない。
質問者が求めてるDIContainer(S2Container)だけなら本当に5分で分かる。
とりあえず、明日は休みなんで真面目な質問には真面目に答えるよ。
ただし、DIContainerに何の意味があるの？とかの是非論は勘弁な。
とりあえず、DIContainerとは何か？って部分はＯＫ？
755 ：デフォルトの名無しさん：2005/10/12(水) 00:44:28
WebLogicでもSpringサポート始めたし、今更Seaser2使う理由は無いだろう。
756 ：デフォルトの名無しさん：2005/10/12(水) 08:46:41
あるとしたら「国産」ってぐらいだな。
757 ：デフォルトの名無しさん：2005/10/13(木) 11:33:27
一太郎みたいに？
758 ：デフォルトの名無しさん：2005/10/13(木) 21:28:20
759 ：デフォルトの名無しさん：2005/10/15(土) 10:44:54
つーか、SpringもS2もデフォルトだとSingletonになるのが納得いかないな。
Singletonパターンは一種のグローバル変数みたいな物で、多用は厳禁なはずじゃないの？
Singletonパターンは一種のグローバル変数みたいな物で、多用は厳禁なはずじゃないの？
760 ：デフォルトの名無しさん：2005/10/15(土) 12:41:11
ロジックはステートレスであるべきって考えが
反映されてるんじゃないかと。
反映されてるんじゃないかと。
761 ：デフォルトの名無しさん：2005/10/15(土) 16:37:49
>>759
Singletonパターンは多用厳禁だからってのは、デフォルトがSingletonであってはいけない理由にならないよ。
せめてどうしてSingletonパターンが多用厳禁で、DIコンテナのデフォルトがSingletonであることがその理由にひっかかるってのがないと。
DIコンテナで管理するようなオブジェクトはSingletonパターンを使っていい場合のオブジェクトになると思うし。
Singletonパターンは多用厳禁だからってのは、デフォルトがSingletonであってはいけない理由にならないよ。
せめてどうしてSingletonパターンが多用厳禁で、DIコンテナのデフォルトがSingletonであることがその理由にひっかかるってのがないと。
DIコンテナで管理するようなオブジェクトはSingletonパターンを使っていい場合のオブジェクトになると思うし。
762 ：デフォルトの名無しさん：2005/10/15(土) 16:41:07
ちょっと関係ないけど
ロジックをステートレスにして切り出したら
結局、ALL staticメソッドにならない？おれいっつも作っててこの辺で悩む
ロジックをステートレスにして切り出したら
結局、ALL staticメソッドにならない？おれいっつも作っててこの辺で悩む
763 ：デフォルトの名無しさん：2005/10/15(土) 17:01:03
764 ：デフォルトの名無しさん：2005/10/15(土) 17:01:26
staticメソッドでもいいんだけど、継承して挙動の変更ができなくなるから嫌われる。
AOPできなくなるし。
AOPできなくなるし。
765 ：759：2005/10/15(土) 17:02:05
>>760
>ロジックはステートレスであるべきって考えが
自分にはこの辺りの理解が出来てなかったみたいだ。
// find1・find2で共通に使用する値を設定
userDao.setUserId(userid);
userDao.find1(...);
userDao.find2(...);
とかやってたし。orz...
>>761
>せめてどうしてSingletonパターンが多用厳禁で、DIコンテナのデフォルトがSingletonであることがその理由にひっかかるってのがないと。
変数のスコープは出来るだけ最小限にしたほうがいいという原則が頭にあったんで、グローバル変数の代用として使える
Singletonがデフォルトということに疑問を感じたってこと。
>ロジックはステートレスであるべきって考えが
自分にはこの辺りの理解が出来てなかったみたいだ。
// find1・find2で共通に使用する値を設定
userDao.setUserId(userid);
userDao.find1(...);
userDao.find2(...);
とかやってたし。orz...
>>761
>せめてどうしてSingletonパターンが多用厳禁で、DIコンテナのデフォルトがSingletonであることがその理由にひっかかるってのがないと。
変数のスコープは出来るだけ最小限にしたほうがいいという原則が頭にあったんで、グローバル変数の代用として使える
Singletonがデフォルトということに疑問を感じたってこと。
766 ：デフォルトの名無しさん：2005/10/15(土) 17:19:27
ttp://patterns-wg.fuka.info.waseda.ac.jp/study/8th.html
ここにひが氏が書いたDIコンテナとデザインパターンの関係が載ってるのだが
その中の、StateパターンとStrategyパターンの説明の違いを読むと、何となく分かるんじゃないだろうか？
DIコンテナで扱ってる「コンポーネント」はあくまでステートレスなものであって、状態を持ったオブジェクトではない
だからシングルトンで扱える
ここにひが氏が書いたDIコンテナとデザインパターンの関係が載ってるのだが
その中の、StateパターンとStrategyパターンの説明の違いを読むと、何となく分かるんじゃないだろうか？
DIコンテナで扱ってる「コンポーネント」はあくまでステートレスなものであって、状態を持ったオブジェクトではない
だからシングルトンで扱える
767 ：デフォルトの名無しさん：2005/10/15(土) 17:25:13
なんか結局JDBCドライバのAPIみたいだな
768 ：デフォルトの名無しさん：2005/10/15(土) 17:34:44
なんかDIって結局Cの関数ポインタ/関数テーブルみたいだな
769 ：デフォルトの名無しさん：2005/10/15(土) 17:40:21
『コンテナ』というぐらいだから、ひとつのアプリケーションにおいて
いわゆる登録しておくものが複数あるはずだ
でも、実際の開発においてDIに登録するものすべきものっていくつある？
実際自分は一つも無かった・・・俺の設計がおかしいのか・・・
いわゆる登録しておくものが複数あるはずだ
でも、実際の開発においてDIに登録するものすべきものっていくつある？
実際自分は一つも無かった・・・俺の設計がおかしいのか・・・
770 ：デフォルトの名無しさん：2005/10/17(月) 09:58:12
>>769
ん～、君はアプリ作る時、interfaceを使ってる？ あと、例えば、
ArrayList myList = new ArrayList();
なんつ～のを見ても違和感を感じないタイプ？
一番簡単な使い方として、myServiceにmyServiceImplを突っ込むとか、
myDaoにmyDaoImplを突っ込むなんてのが教科書的だと思うのだけど、
そういうシチュエーションもなかったの？
ん～、君はアプリ作る時、interfaceを使ってる？ あと、例えば、
ArrayList myList = new ArrayList();
なんつ～のを見ても違和感を感じないタイプ？
一番簡単な使い方として、myServiceにmyServiceImplを突っ込むとか、
myDaoにmyDaoImplを突っ込むなんてのが教科書的だと思うのだけど、
そういうシチュエーションもなかったの？
771 ：デフォルトの名無しさん：2005/10/17(月) 10:52:32
ArrayList myList = new ArrayList();
これの何に違和感を感じりゃいいんだよ。。。
>>769が言いたいのは使うべくして使うところがなかったってことで、
単に使える箇所がないってことじゃないんじゃね？
これの何に違和感を感じりゃいいんだよ。。。
>>769が言いたいのは使うべくして使うところがなかったってことで、
単に使える箇所がないってことじゃないんじゃね？
772 ：デフォルトの名無しさん：2005/10/17(月) 12:15:01
List myList = new ArrayList();
Listで出来る事しかやらないならListで
受けた方がかっちょいいぜ、って事かと。
Listで出来る事しかやらないならListで
受けた方がかっちょいいぜ、って事かと。
773 ：デフォルトの名無しさん：2005/10/17(月) 12:17:36
Servlet側で
List list = new ArayList()
…
request.setAttribute("list", list);
JSP側で
<jsp:useBean id="list" scope="request" class="java.util.List" />
とやってハマったのは俺だけですか？
List list = new ArayList()
…
request.setAttribute("list", list);
JSP側で
<jsp:useBean id="list" scope="request" class="java.util.List" />
とやってハマったのは俺だけですか？
774 ：デフォルトの名無しさん：2005/10/17(月) 12:49:32
775 ：デフォルトの名無しさん：2005/10/17(月) 21:20:23
ちなみに.NETでは
IList myList = new ArrayList();
とかやるとToArrayメソッドやSortメソッドが使えなくて泣くはめになったりする。
そういや、CodeZineでS2Container.NETが紹介されてたけど.NETでDIは使いものになんのか？
IList myList = new ArrayList();
とかやるとToArrayメソッドやSortメソッドが使えなくて泣くはめになったりする。
そういや、CodeZineでS2Container.NETが紹介されてたけど.NETでDIは使いものになんのか？
776 ：デフォルトの名無しさん：2005/10/17(月) 21:38:45
>>775
.NETはよく知らないんだけど、((ArrayList)myList).Sort()で解決する
話とは違うの？
ちなみに、Javaでもキャストしないとインターフェイスに登録されて
ないメソッドは呼べないよ？
.NETはよく知らないんだけど、((ArrayList)myList).Sort()で解決する
話とは違うの？
ちなみに、Javaでもキャストしないとインターフェイスに登録されて
ないメソッドは呼べないよ？
>>776
((ArrayList)myList).Sort();
なんてやるくらいなら、最初からArrayListで宣言するって。
.NET(というか.NET Framework)では「インターフェイスに対してプログラミングする」ってのがやり辛いってことの一例を挙げただけ。
JavaのArrayListの場合は、Listインターフェイスに存在しないメソッドはensureCapacity、trimToSize、cloneだけなんで
Listインターフェイスで宣言してもほとんど問題ないってことだよね。
((ArrayList)myList).Sort();
なんてやるくらいなら、最初からArrayListで宣言するって。
.NET(というか.NET Framework)では「インターフェイスに対してプログラミングする」ってのがやり辛いってことの一例を挙げただけ。
JavaのArrayListの場合は、Listインターフェイスに存在しないメソッドはensureCapacity、trimToSize、cloneだけなんで
Listインターフェイスで宣言してもほとんど問題ないってことだよね。
778 ：デフォルトの名無しさん：2005/10/17(月) 22:50:37
Collection collection = new ArayList()
ここまでやっちゃって、 順序性を意識したロジックで使ってるコードは
見たことある・・・
ここまでやっちゃって、 順序性を意識したロジックで使ってるコードは
見たことある・・・
779 ：デフォルトの名無しさん：2005/10/17(月) 22:57:19
ほほう、.NETは
リスコフの置換原則をあまり
重視しとらんてことですか。
勉強になった。
リスコフの置換原則をあまり
重視しとらんてことですか。
勉強になった。
780 ：デフォルトの名無しさん：2005/10/17(月) 23:09:44
Listを語るスレはここですか？
781 ：デフォルトの名無しさん：2005/10/17(月) 23:11:04
うん
782 ：デフォルトの名無しさん：2005/10/17(月) 23:12:53
Lispを語るスレはここですか？
783 ：デフォルトの名無しさん：2005/10/17(月) 23:16:16
う？
784 ：デフォルトの名無しさん：2005/10/17(月) 23:23:05
785 ：デフォルトの名無しさん：2005/10/17(月) 23:39:08
786 ：デフォルトの名無しさん：2005/10/17(月) 23:45:29
>>784
なるほど、.NETではArrayList自身がユーティリティとしてスタティック
メソッドを提供してるのか、これはこれで字面が美しいな。
ただちょっと気になったんだけど、Object-ArrayListという継承関係で
AdapterメソッドはArrayListクラスに実装されてるの？
私的にはObjectとArrayListの間にスタティックなユーティリティメソッ
ドのみを実装した抽象クラスを挟みたい気分だけど・・・・・・
なるほど、.NETではArrayList自身がユーティリティとしてスタティック
メソッドを提供してるのか、これはこれで字面が美しいな。
ただちょっと気になったんだけど、Object-ArrayListという継承関係で
AdapterメソッドはArrayListクラスに実装されてるの？
私的にはObjectとArrayListの間にスタティックなユーティリティメソッ
ドのみを実装した抽象クラスを挟みたい気分だけど・・・・・・
ごめん、違った(´･ω･｀)
Adapterメソッドは単にIListをArrayListでラップして返してるだけだった。
これはこれで頭いい様な気もするけど・・・・・・
なんだろ？何かモヤモヤする。このモヤモヤの根は一体なんだ？ヽ(`Д´)ﾉｳﾜｧｧﾝ
Adapterメソッドは単にIListをArrayListでラップして返してるだけだった。
これはこれで頭いい様な気もするけど・・・・・・
なんだろ？何かモヤモヤする。このモヤモヤの根は一体なんだ？ヽ(`Д´)ﾉｳﾜｧｧﾝ
788 ：デフォルトの名無しさん：2005/10/18(火) 00:15:11
そもそもSort()メソッドはArrayListに属すべきメソッドなのか？ ってことじゃないの？
JavaならCollections.sort(myList);
のようにユーティリティクラスを利用するところだし
インターフェイスに無くて実装クラスに依存するメソッドが多用されるようだと
たしかにDIは広まりにくいかもしれないな
JavaならCollections.sort(myList);
のようにユーティリティクラスを利用するところだし
インターフェイスに無くて実装クラスに依存するメソッドが多用されるようだと
たしかにDIは広まりにくいかもしれないな
789 ：デフォルトの名無しさん：2005/10/18(火) 00:25:20
ソートみたいなのをインターフェイス挟んだりしてやると遅くなって嫌だったんでしょ。
790 ：デフォルトの名無しさん：2005/10/18(火) 00:43:04
ラップするなら対して変わらない気もするが。
791 ：デフォルトの名無しさん：2005/10/18(火) 00:46:39
インターフェイス挟むと遅くなるのを気にするようなレベルなら、そもそも.NET使わない気が・・・
792 ：デフォルトの名無しさん：2005/10/18(火) 02:19:31
寧ろラップする方がパフォーマンス的には不利
793 ：デフォルトの名無しさん：2005/10/18(火) 02:25:24
正直、
IList myList = new ArrayList();
ArrayList.Adapter(myList).Sort();
よりも、
ArrayList myList = new ArrayList();
myList.Sort();
の方が違和感無い漏れガイル。
IList myList = new ArrayList();
ArrayList.Adapter(myList).Sort();
よりも、
ArrayList myList = new ArrayList();
myList.Sort();
の方が違和感無い漏れガイル。
794 ：デフォルトの名無しさん：2005/10/18(火) 02:32:00
>>793
いや、その場合はそれでいいと思う
Sort（）のメソッド定義を行っているのはArrayListなんだし
逆に言えば、.NETのIListが実用的なインターフェイス定義になっていないということじゃないだろうか
いや、その場合はそれでいいと思う
Sort（）のメソッド定義を行っているのはArrayListなんだし
逆に言えば、.NETのIListが実用的なインターフェイス定義になっていないということじゃないだろうか
795 ：デフォルトの名無しさん：2005/10/18(火) 02:34:32
>>793
ArrayListをLinkedListに変更する必要が生じた場合はどうするの？
ArrayListが持ってるメソッドを全部LinkedListにも実装するから問
題なし？それじゃあ、もっと複雑な型だったら？
その場合も、その元の型が持ってるメソッドを全部実装して問題
なし？
ArrayListをLinkedListに変更する必要が生じた場合はどうするの？
ArrayListが持ってるメソッドを全部LinkedListにも実装するから問
題なし？それじゃあ、もっと複雑な型だったら？
その場合も、その元の型が持ってるメソッドを全部実装して問題
なし？
796 ：デフォルトの名無しさん：2005/10/18(火) 02:51:42
759氏は793氏の発言をきちんと読んだのだろうか？
797 ：デフォルトの名無しさん：2005/10/18(火) 02:59:29
759は795のタイポ？だとしたら、きちんと読んだ上での疑問
なんだけど・・・・・・
なんだけど・・・・・・
798 ：デフォルトの名無しさん：2005/10/18(火) 04:58:01
ArrayListごときでぎゃーぎゃー言うなよ。
IList<T>はまたちょっと違う設計になってるぞ。
IList<T>はまたちょっと違う設計になってるぞ。
799 ：デフォルトの名無しさん：2005/10/18(火) 09:37:23
>>795
YAGNIという言葉もある
YAGNIという言葉もある
800 ：デフォルトの名無しさん：2005/10/18(火) 12:42:21
>>795
ArrayListをLinkedListに変更する必要が生じる場合がどれだけあるかっての。
ArrayListをLinkedListに変更する必要が生じる場合がどれだけあるかっての。
801 ：デフォルトの名無しさん：2005/10/18(火) 12:57:14
802 ：デフォルトの名無しさん：2005/10/18(火) 13:07:09
IList myList = new ArrayList();
ListUtil.Sort(myList);
だと一番しっくりくる感じ。
ListUtil.Sort(myList);
だと一番しっくりくる感じ。
803 ：デフォルトの名無しさん：2005/10/18(火) 14:17:33
>>801
つまり、DIで解決できると謳ってる問題は杞憂ってことか？
つまり、DIで解決できると謳ってる問題は杞憂ってことか？
804 ：デフォルトの名無しさん：2005/10/18(火) 14:19:51
>>795
LinkedList myList = new LinkedList();
LinkedList myList = new LinkedList();
805 ：デフォルトの名無しさん：2005/10/18(火) 14:24:01
806 ：デフォルトの名無しさん：2005/10/18(火) 14:50:00
>805
それはIListだったら解決できるの？
それはIListだったら解決できるの？
807 ：デフォルトの名無しさん：2005/10/18(火) 14:52:30
808 ：デフォルトの名無しさん：2005/10/18(火) 14:54:18
ArrayList固有のメソッドを使っててLinkedListに変更しないといけないシチュエーションってなによ、それ。
809 ：デフォルトの名無しさん：2005/10/18(火) 14:58:07
>>807
IListに属するものが持ちそうなものをあらかじめすべてListUtilにもたせるってこと？
一般のインタフェースで言うなら、ほとんどその労力は空振りになりそうだが。
ArrayListをLinkedListに変更するときに引っかかった部分を対処すればいいだけじゃねーの？
IListに属するものが持ちそうなものをあらかじめすべてListUtilにもたせるってこと？
一般のインタフェースで言うなら、ほとんどその労力は空振りになりそうだが。
ArrayListをLinkedListに変更するときに引っかかった部分を対処すればいいだけじゃねーの？
810 ：デフォルトの名無しさん：2005/10/18(火) 15:00:33
811 ：デフォルトの名無しさん：2005/10/18(火) 15:03:20
>>809
全て持たせる必要はない。誰かが書いてくれてるのなら、それを
ありがたく使わせてもらうが、そうでないなら必要なものだけを定
義すればいい。
>ArrayListをLinkedListに変更するときに引っかかった部分を対
>処すればいいだけじゃねーの？
それをドミノ式バタバタと言ふ
全て持たせる必要はない。誰かが書いてくれてるのなら、それを
ありがたく使わせてもらうが、そうでないなら必要なものだけを定
義すればいい。
>ArrayListをLinkedListに変更するときに引っかかった部分を対
>処すればいいだけじゃねーの？
それをドミノ式バタバタと言ふ
812 ：デフォルトの名無しさん：2005/10/18(火) 15:14:58
> それをドミノ式バタバタと言ふ
起こる確率が低いなら、そっちのほうが効率いいんじゃねぇの？
ArrayListのメソッド呼び出してるんなら、コンパイラが確実に見つけてくれる。
起こる確率が低いなら、そっちのほうが効率いいんじゃねぇの？
ArrayListのメソッド呼び出してるんなら、コンパイラが確実に見つけてくれる。
813 ：デフォルトの名無しさん：2005/10/18(火) 15:42:26
>>807
ArrayListやらLinkedList使ってても解決できるね。
ArrayListやらLinkedList使ってても解決できるね。
814 ：デフォルトの名無しさん：2005/10/18(火) 15:57:49
List の考え方が .NET と JDK で異なる、と。
リストとかでなくてもう少し高次のオブジェクトについて
DI 使った嬉しくなりましたという話をしたいな
リストとかでなくてもう少し高次のオブジェクトについて
DI 使った嬉しくなりましたという話をしたいな
815 ：デフォルトの名無しさん：2005/10/18(火) 16:43:12
>>812
だから、それがドミノ式バタバタってこと。
ドミノ式バタバタ大いに結構。コンパイラのエラーメッセージに
従って順番に書き換えていくから問題なしだと言うなら別に反
論しないから好きにしてくれorz
>>814
話が無駄に複雑化するし、文章が冗長になるだけだ。
Listの例から先の展開を想像できない方が不思議だ。
だから、それがドミノ式バタバタってこと。
ドミノ式バタバタ大いに結構。コンパイラのエラーメッセージに
従って順番に書き換えていくから問題なしだと言うなら別に反
論しないから好きにしてくれorz
>>814
話が無駄に複雑化するし、文章が冗長になるだけだ。
Listの例から先の展開を想像できない方が不思議だ。
816 ：デフォルトの名無しさん：2005/10/18(火) 17:22:37
ArrayListとLinkedListを同時に使わなければ具象クラスでの変数宣言で構わないってことだね。
817 ：デフォルトの名無しさん：2005/10/18(火) 17:57:48
釣りの人はそうだと分かるように書いてくれ、、
818 ：デフォルトの名無しさん：2005/10/18(火) 18:02:48
IListの話で思い出した。
ADO.NETのSystem.Data, System.Data.Commonに
一応DBMS非依存のインタフェースがあるんだけど、
IDataReader/IDataRecordの設計がわけわからん……
IDataReader IDataRecord
↑ ↑
+---------+---------+
|
SqlDataReader, OleDbDataReader,....
いわゆるRecordset/Resultset系のクラスなのだが、なぜか
インタフェースが二つに分割されてて、どっちもないと使い物にはならない。
using (IDataReader reader = cmd.ExecuteReader()) {
while (reader.Read()) {
string id = ((IDataRecord)reader).GetString(1);
}
}
とかやれ、ということか？
これで動くことは動くんだが、最悪……。
ADO.NETのSystem.Data, System.Data.Commonに
一応DBMS非依存のインタフェースがあるんだけど、
IDataReader/IDataRecordの設計がわけわからん……
IDataReader IDataRecord
↑ ↑
+---------+---------+
|
SqlDataReader, OleDbDataReader,....
いわゆるRecordset/Resultset系のクラスなのだが、なぜか
インタフェースが二つに分割されてて、どっちもないと使い物にはならない。
using (IDataReader reader = cmd.ExecuteReader()) {
while (reader.Read()) {
string id = ((IDataRecord)reader).GetString(1);
}
}
とかやれ、ということか？
これで動くことは動くんだが、最悪……。
819 ：デフォルトの名無しさん：2005/10/18(火) 18:10:34
つーか、「LinkedList」は.NET Framework2.0から登場ってこと理解してんの？
しかもIListインターフェイスを実装してないし。
http://msdn2.microsoft.com/en-us/library/he2s3bh7(en-US,VS.80).aspx
それとも、もしかしてSpring.NETで実装されてる「LinkedList」についての話？
http://www.springframework.net/doc-1.1preview/api/html/index.html
しかもIListインターフェイスを実装してないし。
http://msdn2.microsoft.com/en-us/library/he2s3bh7(en-US,VS.80).aspx
それとも、もしかしてSpring.NETで実装されてる「LinkedList」についての話？
http://www.springframework.net/doc-1.1preview/api/html/index.html
821 ：デフォルトの名無しさん：2005/10/18(火) 18:13:48
DIのスレだよな？ここ。
822 ：デフォルトの名無しさん：2005/10/18(火) 18:23:38
Dependncy が何かは分からないが
略すとDIのスレだと思います。
略すとDIのスレだと思います。
823 ：デフォルトの名無しさん：2005/10/18(火) 18:23:43
そうだよ、だからListの話をしているんだよ
824 ：デフォルトの名無しさん：2005/10/18(火) 18:53:06
>>819
こめん、俺の書いたLinkedListという単語は、単なる例(interface的
にArrayListと置き換え可能な何か)で特定の実装を指してない。
てか、そもそも俺はListの話をしてる気すらないｗ
IList myList = new ArrayList()
この記述は当たり前で、その利点も知ってて当然という前提が成立
しないと、DIも糞もない。
こめん、俺の書いたLinkedListという単語は、単なる例(interface的
にArrayListと置き換え可能な何か)で特定の実装を指してない。
てか、そもそも俺はListの話をしてる気すらないｗ
IList myList = new ArrayList()
この記述は当たり前で、その利点も知ってて当然という前提が成立
しないと、DIも糞もない。
825 ：デフォルトの名無しさん：2005/10/18(火) 18:57:10
826 ：デフォルトの名無しさん：2005/10/18(火) 19:48:09
>>821
List myList = new ArrayList();
これもヤダなぁ、ってことになると別な手を考える。例えば
List myList = ListFactory.create("ArrayList");
これでも満足できない、となると、登場するのがDIという名の
BeanFactoryなワケだ。
List myList = new ArrayList();
これもヤダなぁ、ってことになると別な手を考える。例えば
List myList = ListFactory.create("ArrayList");
これでも満足できない、となると、登場するのがDIという名の
BeanFactoryなワケだ。
827 ：デフォルトの名無しさん：2005/10/18(火) 19:51:17
ｽﾏｿ、sage
828 ：デフォルトの名無しさん：2005/10/18(火) 20:11:25
> List myList = ListFactory.create("ArrayList");
これ、何が嬉しいんだかさっぱりわからん
実装クラスをLinkedListにしたいばあい、そういった個所を
"LinkedList"に全置換する気？
これ、何が嬉しいんだかさっぱりわからん
実装クラスをLinkedListにしたいばあい、そういった個所を
"LinkedList"に全置換する気？
829 ：デフォルトの名無しさん：2005/10/18(火) 20:14:09
どこぞで「より良いListの実装」がデビューした時、
一挙に実装を変更できる。
一挙に実装を変更できる。
830 ：デフォルトの名無しさん：2005/10/18(火) 20:29:16
この場合の ArrayList は名前だけなので、
myList の中身がどんな実装クラスになるか
ソースコードは実行時になるまで分からない。
実装クラスを LinkedList にしたい場合、
ListFactory#create(String) の中身を修正するだけ。
変更点は一箇所のみです。
とは言え、それでもなお ListFactory のコンパイルが必要です。
これが BeanFactory になると
「この名前呼ばれたらアレを返す」
って部分をｌ設定ファイルに記述することによって
さらに結合が疎になるわけです。
以下、全置換を楽しみたいマニア向けの記述
List myList = new ArrayList();
もしくは
ArrayList myList = new ArrayList();
myList の中身がどんな実装クラスになるか
ソースコードは実行時になるまで分からない。
実装クラスを LinkedList にしたい場合、
ListFactory#create(String) の中身を修正するだけ。
変更点は一箇所のみです。
とは言え、それでもなお ListFactory のコンパイルが必要です。
これが BeanFactory になると
「この名前呼ばれたらアレを返す」
って部分をｌ設定ファイルに記述することによって
さらに結合が疎になるわけです。
以下、全置換を楽しみたいマニア向けの記述
List myList = new ArrayList();
もしくは
ArrayList myList = new ArrayList();
831 ：デフォルトの名無しさん：2005/10/18(火) 20:33:33
>>829
そんなら俺は要らないなあ。それに、そうであるのなら
List l = ArrayListFactory.create();
としたい。"ArrayList"の指定に意味ってある？コンパイル時型チェックを
失ってまで得られるメリットが。
そんなら俺は要らないなあ。それに、そうであるのなら
List l = ArrayListFactory.create();
としたい。"ArrayList"の指定に意味ってある？コンパイル時型チェックを
失ってまで得られるメリットが。
832 ：デフォルトの名無しさん：2005/10/18(火) 20:35:52
>>830
"ArrayList"といっておきながらLinkedListを造るのは可能だけど、
最悪だなそれって。
ListFactoryはArrayListまたはLinkedListをのどちらか一方だけを造るというのなら
単に
ListFactory.create()でいいと思うんだけど。
"ArrayList"といっておきながらLinkedListを造るのは可能だけど、
最悪だなそれって。
ListFactoryはArrayListまたはLinkedListをのどちらか一方だけを造るというのなら
単に
ListFactory.create()でいいと思うんだけど。
833 ：デフォルトの名無しさん：2005/10/18(火) 20:42:20
えっと、単に、「Factoryの導入」＝＞「DIの導入」
という流れを語りたかっただけなのです。
という流れを語りたかっただけなのです。
834 ：デフォルトの名無しさん：2005/10/18(火) 20:49:31
>832
確かに最初の例がイマイチ。
List myList = ListFactory.create("someList");
とかが良かったと思われ。
ファクトリの機能として必要なこと
・名前を与えられたらインスタンスを返す。
ファクトリ使う側が知ってること
・someList と言う名前を与えれば、必要なインスタンスが取れる。
上二つを守ることで、実クラス名がどこにも出てこない(=疎結合進む)ことが重要。
確かに最初の例がイマイチ。
List myList = ListFactory.create("someList");
とかが良かったと思われ。
ファクトリの機能として必要なこと
・名前を与えられたらインスタンスを返す。
ファクトリ使う側が知ってること
・someList と言う名前を与えれば、必要なインスタンスが取れる。
上二つを守ることで、実クラス名がどこにも出てこない(=疎結合進む)ことが重要。
>>770
>ん～、君はアプリ作る時、interfaceを使ってる？ あと、例えば、
>ArrayList myList = new ArrayList();
>なんつ～のを見ても違和感を感じないタイプ？
だったら、たぶんあなたと同じことを考えながらJavaでコーディングするタイプだと思います
たとえば、DBに登録系のWebアプリケーションを考えた場合
新規登録画面→登録確認→登録完了
変更ログイン画面→変更確認→変更完了
↑まぁ、例えばなんだけども こういう画面遷移系統のアプリがあった場合
どこでDIコンテナ使うのかなぁと思ったり・・・
このWebアプリを脳内で機能拡張させてもいいので、とにかく使う場面を教えて欲しい
>ん～、君はアプリ作る時、interfaceを使ってる？ あと、例えば、
>ArrayList myList = new ArrayList();
>なんつ～のを見ても違和感を感じないタイプ？
だったら、たぶんあなたと同じことを考えながらJavaでコーディングするタイプだと思います
たとえば、DBに登録系のWebアプリケーションを考えた場合
新規登録画面→登録確認→登録完了
変更ログイン画面→変更確認→変更完了
↑まぁ、例えばなんだけども こういう画面遷移系統のアプリがあった場合
どこでDIコンテナ使うのかなぁと思ったり・・・
このWebアプリを脳内で機能拡張させてもいいので、とにかく使う場面を教えて欲しい
836 ：デフォルトの名無しさん：2005/10/18(火) 21:10:20
＞どちらか一方だけを造る
この例だけだとそう見えなくもないかも。
以下のような例はどうです？
(1) Foo なデータアクセスをカプセル化した FooDAO クラスを作った。
FooDAO fooDAO = new FooDAO();
(2) Oracle 用に作ったのだが、将来MySQLでもこのシステムを使うらしい。
→ やりたいことは Foo だが Oracle と MySQL で発行する SQL が違う
→ FooDAO を interface 化して Oracle 用、MySQL 用の実装クラスを作ろう
FooDAO fooDAO = new oracle.FooDAOImpl();
(3) ソースコード中に陽にクラス名が書かれてると、MySQL 用にする時に全置換だね
→ ファクトリクラスを経由させよう
FooDAO fooDAO = FooDAOFactory.create();
(4) Bar なデータアクセスでも同じようなことがおこるし、baz なロジックでもファクトリを経由したい
FooDAO fooDAO = FooDAOFactory.create();
BarDAO barDAO = BarDAOFactory.create();
BazLogic bazLogic = BazLogicFactory.create();
(5) ファクトリ増えすぎ。（← 遠からずここに来ます)
→ 汎用的なファクトリクラスにしよう
FooDAO fooDAO = BeanFactory.getBean("fooDAO");
BarDAO barDAO = BeanFactory.getBean("barDAO");
BazLogic buzzLogic = BeanFactory.getBean("bazLogic");
(6) ファクトリの中身がゴチャゴチャしてきた
→ DI コンテナを使えば生成すべきクラスを設定ファイルに分離できる
とまぁこんなシナリオでどうかと。
この例だけだとそう見えなくもないかも。
以下のような例はどうです？
(1) Foo なデータアクセスをカプセル化した FooDAO クラスを作った。
FooDAO fooDAO = new FooDAO();
(2) Oracle 用に作ったのだが、将来MySQLでもこのシステムを使うらしい。
→ やりたいことは Foo だが Oracle と MySQL で発行する SQL が違う
→ FooDAO を interface 化して Oracle 用、MySQL 用の実装クラスを作ろう
FooDAO fooDAO = new oracle.FooDAOImpl();
(3) ソースコード中に陽にクラス名が書かれてると、MySQL 用にする時に全置換だね
→ ファクトリクラスを経由させよう
FooDAO fooDAO = FooDAOFactory.create();
(4) Bar なデータアクセスでも同じようなことがおこるし、baz なロジックでもファクトリを経由したい
FooDAO fooDAO = FooDAOFactory.create();
BarDAO barDAO = BarDAOFactory.create();
BazLogic bazLogic = BazLogicFactory.create();
(5) ファクトリ増えすぎ。（← 遠からずここに来ます)
→ 汎用的なファクトリクラスにしよう
FooDAO fooDAO = BeanFactory.getBean("fooDAO");
BarDAO barDAO = BeanFactory.getBean("barDAO");
BazLogic buzzLogic = BeanFactory.getBean("bazLogic");
(6) ファクトリの中身がゴチャゴチャしてきた
→ DI コンテナを使えば生成すべきクラスを設定ファイルに分離できる
とまぁこんなシナリオでどうかと。
>>836
う～んわかったような・・・でも「MySQL 用にする時に全置換だね 」のほうが楽なので本末転倒のような・・・
そもそもJDBCドライバ自体が「DBの違い」を吸収するのではないのだろうか？
つまり、説明で挙げられた例がDI使うべき例ではないと思うのだが・・・どうか？
もうしばらくそのレス読み返してみるけどさ
う～んわかったような・・・でも「MySQL 用にする時に全置換だね 」のほうが楽なので本末転倒のような・・・
そもそもJDBCドライバ自体が「DBの違い」を吸収するのではないのだろうか？
つまり、説明で挙げられた例がDI使うべき例ではないと思うのだが・・・どうか？
もうしばらくそのレス読み返してみるけどさ
838 ：デフォルトの名無しさん：2005/10/18(火) 21:27:54
>>836
俺の中では(4)→(5)に大分飛躍があるみたい。そこで型安全性が失われるので。
単に「クラスが増えるのが嫌」なら
DAOFactory.createFoo()やDAOFactory.createBar()という手もあるかなあと。
それでもFactoryの場合は、多分DAOFactoryとLogicFactoryは別になるでしょうね。
それが全部BeanFactoryになっちゃうのも、やや気持ちが悪い。
>>837
JDBCはある程度差異は吸収してくれるけど、SQL自体はDBMSによって違うわけだし、
実際にはDBMS依存部分が残ったりすることも多いでしょ。
ま、実際の業務で複数DBMSに対応しなきゃいかんケースは結構稀だと思うが。
「テスト用モックと差し替え」とかのがありがちな気がする。
俺の中では(4)→(5)に大分飛躍があるみたい。そこで型安全性が失われるので。
単に「クラスが増えるのが嫌」なら
DAOFactory.createFoo()やDAOFactory.createBar()という手もあるかなあと。
それでもFactoryの場合は、多分DAOFactoryとLogicFactoryは別になるでしょうね。
それが全部BeanFactoryになっちゃうのも、やや気持ちが悪い。
>>837
JDBCはある程度差異は吸収してくれるけど、SQL自体はDBMSによって違うわけだし、
実際にはDBMS依存部分が残ったりすることも多いでしょ。
ま、実際の業務で複数DBMSに対応しなきゃいかんケースは結構稀だと思うが。
「テスト用モックと差し替え」とかのがありがちな気がする。
839 ：デフォルトの名無しさん：2005/10/18(火) 21:55:22
>>837
なんで？新しいクラスを書いて、それを設定ファイルに記述する方が
ソースファイルを漁って回るより遥かに楽じゃん？
.NETに関する知識が未熟なんで何とも言い難いんだけど、例えばロ
グイン用のユーザー名とパスワードを受け取るカスタムコントロール
を書くとするよね？
この時、描画、文字種判定、暗号化なんかはベタコーディングなの？
Render、Validater、Encrypterと分けて括り出せそうな気がするんだ
けど・・・・・・これをDIコンテナで管理すれば、カスタムコントロール自
体を再コンパイルする必要は以後なくなる。
てか、ちょっとググってみた感じでは、ASP.NET簡単そうやなぁ。
これで周辺ライブラリが整ったら末恐ろしいわ。結構グラっときたｗ
>>838
これまではMySQLが優勢だったじゃない？
でも、今度のPostgreSQLはパフォーマンス高そうやぞぉ～
なんで？新しいクラスを書いて、それを設定ファイルに記述する方が
ソースファイルを漁って回るより遥かに楽じゃん？
.NETに関する知識が未熟なんで何とも言い難いんだけど、例えばロ
グイン用のユーザー名とパスワードを受け取るカスタムコントロール
を書くとするよね？
この時、描画、文字種判定、暗号化なんかはベタコーディングなの？
Render、Validater、Encrypterと分けて括り出せそうな気がするんだ
けど・・・・・・これをDIコンテナで管理すれば、カスタムコントロール自
体を再コンパイルする必要は以後なくなる。
てか、ちょっとググってみた感じでは、ASP.NET簡単そうやなぁ。
これで周辺ライブラリが整ったら末恐ろしいわ。結構グラっときたｗ
>>838
これまではMySQLが優勢だったじゃない？
でも、今度のPostgreSQLはパフォーマンス高そうやぞぉ～
840 ：デフォルトの名無しさん：2005/10/18(火) 22:01:51
>>839
いやまあ、「動いてるモノはいじらない」がシステム屋の基本なので。
パフォーマンス問題が出たら、その時に考える。もちろん、お金を貰ってｗ
経験上、「必要性が無いうちは手間をかけずにadhocに造っておいて、
後で必要性が出たらその時に考える」というアプローチで困ったことは無いし、
むしろその方が安くつくことが多いような気がする。
いやまあ、「動いてるモノはいじらない」がシステム屋の基本なので。
パフォーマンス問題が出たら、その時に考える。もちろん、お金を貰ってｗ
経験上、「必要性が無いうちは手間をかけずにadhocに造っておいて、
後で必要性が出たらその時に考える」というアプローチで困ったことは無いし、
むしろその方が安くつくことが多いような気がする。
＞この時、描画、文字種判定、暗号化なんかはベタコーディングなの？
＞Render、Validater、Encrypterと分けて括り出せそうな気がするんだ
＞けど・・・・・・
ここまでは同意なんだよね
ただ、なんで
＞これをDIコンテナで管理すれば
ってなるのかがわからんていうことです
「これはあくまでも例」だと言うことはわかります（まさかほんとにこのログの部分だけでRender、Validater、Encrypter全部DIに登録？やりすぎだろ？）
＞Render、Validater、Encrypterと分けて括り出せそうな気がするんだ
＞けど・・・・・・
ここまでは同意なんだよね
ただ、なんで
＞これをDIコンテナで管理すれば
ってなるのかがわからんていうことです
「これはあくまでも例」だと言うことはわかります（まさかほんとにこのログの部分だけでRender、Validater、Encrypter全部DIに登録？やりすぎだろ？）
842 ：デフォルトの名無しさん：2005/10/18(火) 22:09:31
まあ.NETスタイルだと、カスタムコンポーネントを造る
→後はポトペタ
ってのが普通と思われ
それが「DI」なのかどうかは知らない
→後はポトペタ
ってのが普通と思われ
それが「DI」なのかどうかは知らない
843 ：デフォルトの名無しさん：2005/10/18(火) 22:34:53
>>841
例そのままだと粒度が小さすぎるけど、カスタムコントロールという枠組
の中で考えると分からんな、やるかもしれん。
てか、実際のとこ、.NETのカスタムコントロールがどの規模になるのか
現実に書いた事がないから、現時点では全く把握できないんだよな。
Delphiのカスタムコンポーネントなんかだと、機能部品を個別のコンポ
ーネントに分割して、プロパティで接続というのが一般的だったんだが
.NETもDIよりIDE上でポトペタしてプロパティを設定する方が合ってるの
かも？
例そのままだと粒度が小さすぎるけど、カスタムコントロールという枠組
の中で考えると分からんな、やるかもしれん。
てか、実際のとこ、.NETのカスタムコントロールがどの規模になるのか
現実に書いた事がないから、現時点では全く把握できないんだよな。
Delphiのカスタムコンポーネントなんかだと、機能部品を個別のコンポ
ーネントに分割して、プロパティで接続というのが一般的だったんだが
.NETもDIよりIDE上でポトペタしてプロパティを設定する方が合ってるの
かも？
844 ：デフォルトの名無しさん：2005/10/18(火) 23:58:21
つか、DI信者は全置換を恐れ過ぎ。
機械的に検出出来るし。
機械的に検出出来るし。
>>844
確かにソースは追いづらいだろう
確かにソースは追いづらいだろう
846 ：デフォルトの名無しさん：2005/10/19(水) 00:24:36
847 ：デフォルトの名無しさん：2005/10/19(水) 01:16:41
全置換を恐れなく使う兵たちがDIやAOPを語るスレ
848 ：デフォルトの名無しさん：2005/10/19(水) 04:26:45
コピペや置換のあるところ、必ずや漏れありと伝えられておって喃
つーかDRY原則
つーかDRY原則
849 ：デフォルトの名無しさん：2005/10/19(水) 09:43:56
結局DBだけなのかなぁ
DB変ればSQL異なるとはいうけど
基本的にJavaやっている人間なら
SQLはどのDBでも動くような構文で書かないか？
まぁそれもDBがきちんと正規化されていれば可能な話であって
パフォーマンス考えた場合違う設計になるかもね
ちなみにそのシステムにおいてDIコンテナって一個ですよね
その中に、Render、Validater、Encrypter、DBConnection、DAO系とかって全部入っているの？（入っているように設計するの？）
よさげな点は、今どのくらいのオブジェクトが生成されててとかプールされていてとか言う情報が
DIコンテナそのもののステータスとして取得できるのかなぁというところ
DB変ればSQL異なるとはいうけど
基本的にJavaやっている人間なら
SQLはどのDBでも動くような構文で書かないか？
まぁそれもDBがきちんと正規化されていれば可能な話であって
パフォーマンス考えた場合違う設計になるかもね
ちなみにそのシステムにおいてDIコンテナって一個ですよね
その中に、Render、Validater、Encrypter、DBConnection、DAO系とかって全部入っているの？（入っているように設計するの？）
よさげな点は、今どのくらいのオブジェクトが生成されててとかプールされていてとか言う情報が
DIコンテナそのもののステータスとして取得できるのかなぁというところ
851 ：デフォルトの名無しさん：2005/10/19(水) 22:59:02
結論としては、モック意外に使い道無し＞DI
＞結論としては、モック意外に使い道無し＞DI
たとえば、単純な構成ならよいのだろうけど
複数のクラス群がまとめてモックを構成しているとしたら
設定ファイル変えるのと、Factoryクラスの置換とどっちが楽なのだろうか
全然関係ない話になるけど
設定ファイルってやっぱアプリケーション再起動しないと反映されないのね？
たとえば、単純な構成ならよいのだろうけど
複数のクラス群がまとめてモックを構成しているとしたら
設定ファイル変えるのと、Factoryクラスの置換とどっちが楽なのだろうか
全然関係ない話になるけど
設定ファイルってやっぱアプリケーション再起動しないと反映されないのね？
853 ：デフォルトの名無しさん：2005/10/19(水) 23:03:58
「拡張性が高い」ってのは、改造や機能追加が、手間を掛けずに正しく行える、という事。
んで、DI信者の言う「拡張性が高い」は「改造が少数のクラスの変更で実現できる」の意味だが、
現実には、多数のクラスを少しずつ改造した方が、手間が掛からず設計もコードもシンプルに保てるケースが割と多い。
んで、DI信者の言う「拡張性が高い」は「改造が少数のクラスの変更で実現できる」の意味だが、
現実には、多数のクラスを少しずつ改造した方が、手間が掛からず設計もコードもシンプルに保てるケースが割と多い。
854 ：デフォルトの名無しさん：2005/10/19(水) 23:05:25
>>850
全部のオブジェクトをコンテナ管理するかどうかに拘ってるのは何故？
普通、DI導入するなら自作クラスは全てDIコンテナで管理する。
ほとんどがステートレスのシングルトンオブジェクトになるから、それをStragetyパターン等で組み合わせる
あと、別にオブジェクトのプール機能を目的としてはいないから、簡単にオブジェクトのプール数を取得できるようなコンテナは無いと思う
レスを読んでると、何か根本的にDIコンテナの存在理由を履き違えてる気がするが・・・
全部のオブジェクトをコンテナ管理するかどうかに拘ってるのは何故？
普通、DI導入するなら自作クラスは全てDIコンテナで管理する。
ほとんどがステートレスのシングルトンオブジェクトになるから、それをStragetyパターン等で組み合わせる
あと、別にオブジェクトのプール機能を目的としてはいないから、簡単にオブジェクトのプール数を取得できるようなコンテナは無いと思う
レスを読んでると、何か根本的にDIコンテナの存在理由を履き違えてる気がするが・・・
855 ：デフォルトの名無しさん：2005/10/19(水) 23:07:56
856 ：デフォルトの名無しさん：2005/10/19(水) 23:08:02
本当に複数のデータベースで動作しなければならない場合は非常に少ない。
ほとんどの土方プログラマは、データベースが変わる可能性を気にする必要はない。
ほとんどの土方プログラマは、データベースが変わる可能性を気にする必要はない。
>>854
＞レスを読んでると、何か根本的にDIコンテナの存在理由を履き違えてる気がするが・・・
まぁ、実際ここに顔を出すには早すぎる感があると思っている
いまんとこ、DIについてこのスレの内容しか見てないし（しかも、偏ったり間違った意見もあるだろう）
「言う前に自分で理解して来い」と言うならそれまで消えるんですが
＞全部のオブジェクトをコンテナ管理するかどうかに拘ってるのは何故？
僕は、いまのところDIはTomcatの設定ファイルContect要素に書かれるDBソースの定義と同じようなものだと考えているんです
そべてのものをそこで管理するのは重たくない？（役割として重過ぎるの意）って思っています現状
＞ほとんどがステートレスのシングルトンオブジェクトになるから、それをStraｔeｇyパターン等で組み合わせる
う～ん、なるほど 自分はどちらかと言うとコマンドパターンを多用するタイプで、そっちの考えは今までなかった
＞レスを読んでると、何か根本的にDIコンテナの存在理由を履き違えてる気がするが・・・
まぁ、実際ここに顔を出すには早すぎる感があると思っている
いまんとこ、DIについてこのスレの内容しか見てないし（しかも、偏ったり間違った意見もあるだろう）
「言う前に自分で理解して来い」と言うならそれまで消えるんですが
＞全部のオブジェクトをコンテナ管理するかどうかに拘ってるのは何故？
僕は、いまのところDIはTomcatの設定ファイルContect要素に書かれるDBソースの定義と同じようなものだと考えているんです
そべてのものをそこで管理するのは重たくない？（役割として重過ぎるの意）って思っています現状
＞ほとんどがステートレスのシングルトンオブジェクトになるから、それをStraｔeｇyパターン等で組み合わせる
う～ん、なるほど 自分はどちらかと言うとコマンドパターンを多用するタイプで、そっちの考えは今までなかった
858 ：デフォルトの名無しさん：2005/10/19(水) 23:45:13
>>854
> 普通、DI導入するなら自作クラスは全てDIコンテナで管理する。
げ。そうなの？
> ほとんどがステートレスのシングルトンオブジェクトになるから
普通にオブジェクト指向で設計して、自作クラスのほとんどがそうなる
というのは普通に理解しがたい。
> 普通、DI導入するなら自作クラスは全てDIコンテナで管理する。
げ。そうなの？
> ほとんどがステートレスのシングルトンオブジェクトになるから
普通にオブジェクト指向で設計して、自作クラスのほとんどがそうなる
というのは普通に理解しがたい。
>＞ ほとんどがステートレスのシングルトンオブジェクトになるから
＞普通にオブジェクト指向で設計して、自作クラスのほとんどがそうなる
＞というのは普通に理解しがたい。
なんか、実装段階で突き詰めてクラスを作っていると、ステートレスになることは（自分は）よくある
シングルトンになるかどうかは知らんけど
＞普通にオブジェクト指向で設計して、自作クラスのほとんどがそうなる
＞というのは普通に理解しがたい。
なんか、実装段階で突き詰めてクラスを作っていると、ステートレスになることは（自分は）よくある
シングルトンになるかどうかは知らんけど
860 ：デフォルトの名無しさん：2005/10/19(水) 23:50:51
>>859
別名、手続き型ｗ
別名、手続き型ｗ
862 ：デフォルトの名無しさん：2005/10/19(水) 23:56:54
>859
引数の数が増えすぎていない？
リファクタリングしてる？
引数の数が増えすぎていない？
リファクタリングしてる？
863 ：デフォルトの名無しさん：2005/10/20(木) 00:00:31
>>857
そもそも「コンテナ」という言葉自体が、船やトラックを連想させて重たく感じるな。
そもそも「コンテナ」という言葉自体が、船やトラックを連想させて重たく感じるな。
>>857
全部と言うと、ちょっと語弊があったかもしれない
基本的にDIコンテナは、初期化で全てのコンポーネントの関連付けを決定する仕組みなので
状態によって動的にオブジェクトを変動させるような動き（ステートパターンやコマンドパターンなど）には向かない
だからDIコンテナを使って開発すると、状態と振る舞いを分離して作るような方向に向かいがち
普通にクラスを作ってると、フィールドに状態を持ち、継承を使ってメソッドをまとめたりテンプレートパターン使ったりすると思う
DIを使った場合、フィールドには部品化されたステートレスなクラス群を持ち、
メソッド引数で状態を貰って、処理を委譲しながら全体的な処理を行う・・・ような作り方がやり易くなる
全部と言うと、ちょっと語弊があったかもしれない
基本的にDIコンテナは、初期化で全てのコンポーネントの関連付けを決定する仕組みなので
状態によって動的にオブジェクトを変動させるような動き（ステートパターンやコマンドパターンなど）には向かない
だからDIコンテナを使って開発すると、状態と振る舞いを分離して作るような方向に向かいがち
普通にクラスを作ってると、フィールドに状態を持ち、継承を使ってメソッドをまとめたりテンプレートパターン使ったりすると思う
DIを使った場合、フィールドには部品化されたステートレスなクラス群を持ち、
メソッド引数で状態を貰って、処理を委譲しながら全体的な処理を行う・・・ような作り方がやり易くなる
＞引数の数が増えすぎていない？
ああ、それに陥ったコード見るとそうなってる
だもんだかから、その引数を一つのまとまったクラスにして汎用引数クラスとして・・・とか言う事をいつのまにか考えている
最終的に出来上がるものはバランスのいいものが出来上がるのでいいのだけど。
まぁ、そういうことゆっくり考えれるのも仕事以外の時だけなので結構面白いけど
＞リファクタリングしてる？
これは「引数の数」と関係あるの？解説ヨロ
来月から新規に立ち上げるプロジェクトで、リーダがDI使おうとか（そいつもよくわかってないくせに）言っている
メンバー内にJavaすら扱った奴自分以外一人もいないので、他の人のためにもあまりDIのように難しい事をやるべきではないと思っている
がしかし、それならそれできちんとした説明責任があるのでこのスレ見ているんだが・・・
ぱっと見る限り一番標準的なのはSpringだろうか？
実はJSFも使う事が決定しているのでそのコンポーネントもDIコンテナ管理にすべきなんだろ？ここの住人的には。
自分はJSFは経験あるのでよいのだが他のメンバはJava＋JSF+DIだろ・・・かなり辛いと思う
ああ、それに陥ったコード見るとそうなってる
だもんだかから、その引数を一つのまとまったクラスにして汎用引数クラスとして・・・とか言う事をいつのまにか考えている
最終的に出来上がるものはバランスのいいものが出来上がるのでいいのだけど。
まぁ、そういうことゆっくり考えれるのも仕事以外の時だけなので結構面白いけど
＞リファクタリングしてる？
これは「引数の数」と関係あるの？解説ヨロ
来月から新規に立ち上げるプロジェクトで、リーダがDI使おうとか（そいつもよくわかってないくせに）言っている
メンバー内にJavaすら扱った奴自分以外一人もいないので、他の人のためにもあまりDIのように難しい事をやるべきではないと思っている
がしかし、それならそれできちんとした説明責任があるのでこのスレ見ているんだが・・・
ぱっと見る限り一番標準的なのはSpringだろうか？
実はJSFも使う事が決定しているのでそのコンポーネントもDIコンテナ管理にすべきなんだろ？ここの住人的には。
自分はJSFは経験あるのでよいのだが他のメンバはJava＋JSF+DIだろ・・・かなり辛いと思う
＞状態によって動的にオブジェクトを変動させるような動き（ステートパターンやコマンドパターンなど）には向かない
そうそう、Strategyって聞いた時それは思った
＞・・・
なるほど、よくわかります
そうそう、Strategyって聞いた時それは思った
＞・・・
なるほど、よくわかります
867 ：デフォルトの名無しさん：2005/10/20(木) 00:24:06
>>859
> その引数を一つのまとまったクラスにして汎用引数クラスとして
Cだとよく見る。何でも突っ込んでる「環境」と呼ばれる
超巨大な構造体。
typedef struct vi { ..................... };
で、どんな関数も引数にstruct viのポインタを取る、という
とても素晴らしい世界。
> その引数を一つのまとまったクラスにして汎用引数クラスとして
Cだとよく見る。何でも突っ込んでる「環境」と呼ばれる
超巨大な構造体。
typedef struct vi { ..................... };
で、どんな関数も引数にstruct viのポインタを取る、という
とても素晴らしい世界。
868 ：デフォルトの名無しさん：2005/10/20(木) 00:27:46
>>864
話だけ聞くとDIを適用するためにオブジェクト指向的に自然な設計を
捻じ曲げているのでは？……という風にも聞こえる。
そもそも、Strategyを適用したくなるようなケースってそう多いとも思わない
んだけれども。
話だけ聞くとDIを適用するためにオブジェクト指向的に自然な設計を
捻じ曲げているのでは？……という風にも聞こえる。
そもそも、Strategyを適用したくなるようなケースってそう多いとも思わない
んだけれども。
869 ：デフォルトの名無しさん：2005/10/20(木) 00:28:56
871 ：デフォルトの名無しさん：2005/10/20(木) 00:36:47
>>868
自分も使う前に調べてる中でそう思ったｗ
Strategyはようするに、クラス毎に簡単に実装を切り替えられる為に用意してる印象
クラスは非常に分割・部品化しやすくなるし、その切り替えも設定ファイル一発で出来るようになる。
ただ、「状態」を扱うのがちと独特になりがちな面は否めない
実際に使ってみると、確かに便利で手放せないと思った。
気に入るかどうかは人次第、システム次第かもしれないが
定型的業務系システム構築には向いているんじゃないかと個人的には思う
自分も使う前に調べてる中でそう思ったｗ
Strategyはようするに、クラス毎に簡単に実装を切り替えられる為に用意してる印象
クラスは非常に分割・部品化しやすくなるし、その切り替えも設定ファイル一発で出来るようになる。
ただ、「状態」を扱うのがちと独特になりがちな面は否めない
実際に使ってみると、確かに便利で手放せないと思った。
気に入るかどうかは人次第、システム次第かもしれないが
定型的業務系システム構築には向いているんじゃないかと個人的には思う
872 ：デフォルトの名無しさん：2005/10/20(木) 00:50:05
>>852
>設定ファイル変えるのと、Factoryクラスの置換とどっちが楽なのだろうか
ソースはコンパイラが厳しくチェックするが、
設定ファイルはtypoですらスルー。下手をすれば実行するまでノーチェック。
>設定ファイル変えるのと、Factoryクラスの置換とどっちが楽なのだろうか
ソースはコンパイラが厳しくチェックするが、
設定ファイルはtypoですらスルー。下手をすれば実行するまでノーチェック。
873 ：デフォルトの名無しさん：2005/10/20(木) 00:54:46
そこでアノテーションですよ
874 ：デフォルトの名無しさん：2005/10/20(木) 02:45:21
>>870
なんとなくわかる気がする。
どこまで引数にするのかってことに悩んでしまうんだ。
引数を減らせば減らすほど同じ概念で扱える可能性が上がる。
これはこれで気持ち良いのだけど、状態を持たねば動けない
クラスが増える。引数を増やせば今度はどんどん具象に
近づいてく。ここのさじ加減に悩む。
ステートレスは結果的にめいっぱい具象に近づくし、
引数無しのコマンド型にまで落とし込むと思いっきり抽象。
なんとなくわかる気がする。
どこまで引数にするのかってことに悩んでしまうんだ。
引数を減らせば減らすほど同じ概念で扱える可能性が上がる。
これはこれで気持ち良いのだけど、状態を持たねば動けない
クラスが増える。引数を増やせば今度はどんどん具象に
近づいてく。ここのさじ加減に悩む。
ステートレスは結果的にめいっぱい具象に近づくし、
引数無しのコマンド型にまで落とし込むと思いっきり抽象。
875 ：デフォルトの名無しさん：2005/10/20(木) 13:27:58
Strategyパターンで作れるところや、サブシステムの構成とか疎結合にしたいところにはいいが
密結合のほうが都合のいい場面もあるわけで。
純粋にDIにしたほうがいい場面ってのはそこまで多くないんじゃないか？
とはいえ疎結合にしてるとやっぱいいね。
あと、SpringはAOPでのトランザクション管理とかあるしね。
ま、黄金のハンマーはないってことだな。
ついでに、設定ファイル監視して変更あったらSetter叩き直すとかできたら便利かも。
激しくchaosになりそうだが。
密結合のほうが都合のいい場面もあるわけで。
純粋にDIにしたほうがいい場面ってのはそこまで多くないんじゃないか？
とはいえ疎結合にしてるとやっぱいいね。
あと、SpringはAOPでのトランザクション管理とかあるしね。
ま、黄金のハンマーはないってことだな。
ついでに、設定ファイル監視して変更あったらSetter叩き直すとかできたら便利かも。
激しくchaosになりそうだが。
876 ：デフォルトの名無しさん：2005/10/20(木) 23:00:57
結論：手続き型で構造化プログラミング、これ最強。
877 ：デフォルトの名無しさん：2005/10/20(木) 23:21:40
DIはいいけどXMLｲﾗﾈ
878 ：デフォルトの名無しさん：2005/10/20(木) 23:32:14
そうそうやっぱINIファイルだよね
879 ：デフォルトの名無しさん：2005/10/20(木) 23:47:55
いやpropertiesファイルだよやっぱ。
native2asciiバチコーン
native2asciiバチコーン
880 ：デフォルトの名無しさん：2005/10/21(金) 01:06:41
java.util.PropertiesもXMLファイルを読み込むようなこんな世の中じゃ
881 ：デフォルトの名無しさん：2005/10/21(金) 12:12:23
ステートレスというのがよくわからないんだが、純粋関数の集合をクラスにしたという理解で合ってる？
882 ：デフォルトの名無しさん：2005/10/21(金) 19:29:07
>>881
ここではメンバ変数がない、ぐらいの意味。
ここではメンバ変数がない、ぐらいの意味。
883 ：デフォルトの名無しさん：2005/10/21(金) 23:02:32
つまり、サブルーチン集の事ですね。
884 ：デフォルトの名無しさん：2005/10/21(金) 23:18:26
俺のサブルーチン集１００ゴールドでかわね？
885 ：デフォルトの名無しさん：2005/10/22(土) 01:01:12
↑いらね
886 ：デフォルトの名無しさん：2005/10/22(土) 15:29:19
基礎的な質問で、スマｿ。
DIの依存性注入の意味なんだが、
Ａ→Ｂ→Ｃ
と呼び出しているとき、ＢとＣ間の依存性の注入を意味しているのか、
ＡとＢの間の依存性の注入も意味しているのだろうか。
つまり、Ｂ→Ｃ間の依存性は初期化時に決定され、アプリケーションの
動作中は代わることはないのだが、Ａ→Ｂについては、
Ａに渡されたパラメータに応じて、呼び出すＢが変わる場合、
これはＤＩには当たらないのだろうか。
DIの依存性注入の意味なんだが、
Ａ→Ｂ→Ｃ
と呼び出しているとき、ＢとＣ間の依存性の注入を意味しているのか、
ＡとＢの間の依存性の注入も意味しているのだろうか。
つまり、Ｂ→Ｃ間の依存性は初期化時に決定され、アプリケーションの
動作中は代わることはないのだが、Ａ→Ｂについては、
Ａに渡されたパラメータに応じて、呼び出すＢが変わる場合、
これはＤＩには当たらないのだろうか。
887 ：デフォルトの名無しさん：2005/10/23(日) 07:33:13
E・∇・ﾖﾉｼ ＜888ｹﾞｯﾄ♫
889 ：デフォルトの名無しさん：2005/12/29(木) 12:07:42
Java World の今月の特集がフレームワークの話で
「最近はDIコンテナベースが普通だよもん」とか書いてあったのだが
俺の周りは実装クラスでガチガチな設計ばかりで泣きそうになる。
「最近はDIコンテナベースが普通だよもん」とか書いてあったのだが
俺の周りは実装クラスでガチガチな設計ばかりで泣きそうになる。
890 ：デフォルトの名無しさん：2005/12/29(木) 13:16:07
EJB3が流行りだせば、自然にDIベースになる。
心配するな。
心配するな。
891 ：デフォルトの名無しさん：2006/01/05(木) 08:51:55
「普通だよもん」は言い過ぎの気がするなぁ。
892 ：デフォルトの名無しさん：2006/01/21(土) 01:03:39
PicoContainer 1.2がやっと出たぜ。
おれこのコンテナ、起動もコンポーネント取得も速いんで結構好き。
まあXML解析の時間がゼロだからだろな。
おれこのコンテナ、起動もコンポーネント取得も速いんで結構好き。
まあXML解析の時間がゼロだからだろな。
893 ：デフォルトの名無しさん：2006/02/07(火) 01:05:51
JBossのMicroContainerに手を伸ばしている人はいる?
ちょっとみてみたけど，SpringとかSeasar2のような意味でのDIコンテナとはちょっと違うみたいな気が…
あくまでKernelにBeanを埋め込むための設定ファイル処理エンジンみたいな感じがする。
ちょっとみてみたけど，SpringとかSeasar2のような意味でのDIコンテナとはちょっと違うみたいな気が…
あくまでKernelにBeanを埋め込むための設定ファイル処理エンジンみたいな感じがする。
894 ：デフォルトの名無しさん：2006/02/08(水) 20:11:39
DIって予め使うクラスをオブジェクト化してプールしておくことで
何度もクラスを使う時、いちいちオブジェクトを生成しなくていいという利点
もあったりするのでしょうか？
何度もクラスを使う時、いちいちオブジェクトを生成しなくていいという利点
もあったりするのでしょうか？
895 ：デフォルトの名無しさん：2006/02/08(水) 22:01:55
logic や DAO はスレッドセーフに作って
コンテナ内で唯一のオブジェクトを使いまわすのが普通。
結果的にそういう運用が多くなるだけであって
DIの利点であるとは思えません。
特別に Singleton を作ろうとせずに済むのは利点。
(スレッドセーフは意識しないといけないが)
コンテナ内で唯一のオブジェクトを使いまわすのが普通。
結果的にそういう運用が多くなるだけであって
DIの利点であるとは思えません。
特別に Singleton を作ろうとせずに済むのは利点。
(スレッドセーフは意識しないといけないが)
896 ：デフォルトの名無しさん：2006/02/09(木) 00:34:49
897 ：デフォルトの名無しさん：2006/06/14(水) 00:45:04
> logic や DAO はスレッドセーフに作って
> コンテナ内で唯一のオブジェクトを使いまわすのが普通
これはなぜですか？
> コンテナ内で唯一のオブジェクトを使いまわすのが普通
これはなぜですか？
898 ：デフォルトの名無しさん：2006/06/14(水) 10:33:40
>897
・生成処理が比較的重いと想定される。
・リクエスト-レスポンスで完結させて、状態を持たせないようにした方が見通しがいい。
（このレイヤは状態を持つべきでない、と言い切る人もいる。)
→「生成は一度にして唯一のインスタンスを使いまわせばいい。
スレッドセーフに作る必要はあるが、状態を持たないならそれは簡単。」
ってところかと。
・生成処理が比較的重いと想定される。
・リクエスト-レスポンスで完結させて、状態を持たせないようにした方が見通しがいい。
（このレイヤは状態を持つべきでない、と言い切る人もいる。)
→「生成は一度にして唯一のインスタンスを使いまわせばいい。
スレッドセーフに作る必要はあるが、状態を持たないならそれは簡単。」
ってところかと。
899 ：デフォルトの名無しさん：2006/06/15(木) 00:52:14
おまいらそんなに生成が思いlogicやDAO作ってんのか？
もういっその事設定ファイルじゃなくてDBでいいんじゃね？