5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Dependncy Injectionを語るスレ

1 :デフォルトの名無しさん:04/11/07 20:32:05
依存性注入ということらしい。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

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/

3 :デフォルトの名無しさん:04/11/07 20:46:16
RubyでDIという記事
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/


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

6 :デフォルトの名無しさん:04/11/07 21:18:33
補足

PicoContainerにはRuby版と.NET版もあり。
PHP版のDIコンテナを作るというのもどこかで見かけた。

7 :デフォルトの名無しさん:04/11/07 22:15:50
結論
 EJB3.0で決まり

8 :デフォルトの名無しさん:04/11/07 22:51:16
EJB3.0ってDIコンテナになるの?

9 :デフォルトの名無しさん:04/11/08 00:24:44
>>3
Needle つかったことないけど。
http://rubyforge.org/projects/needle

10 :デフォルトの名無しさん:04/11/08 16:59:38
Pythonのものはないかと探して見つけたもの

PyContainer
http://www.pycontainer.glt.pl/

11 :デフォルトの名無しさん:04/11/08 17:15:14
Dependency Injection in Ruby
ttp://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc

12 :デフォルトの名無しさん:04/11/08 17:16:07
色々とあるもんだなー。
Perlはないのかな?

13 :デフォルトの名無しさん:04/11/08 18:51:20
IOC - A lightweight IOC (Inversion of Control) framework
ttp://search.cpan.org/~stevan/IOC-0.08/

14 :デフォルトの名無しさん:04/11/08 19:03:11
おーPerlだ。dクス
スクリプト系でもDIって流行ってきてるんだね。
Javaだけってわけじゃないんだ。

15 :デフォルトの名無しさん:04/11/09 05:58:21
で、DIって具体的にどういう的に便利なの?
・小規模...わざわざxmlに定義するよりPOJOでやった方が簡単
・大規模...インスタンスの生成管理したいので大部分では使わない
 →ソース追いづらくなるしDI使わないに統一した方がいい
・中規模...ウォーターフォールでインターフェースを決め打ちできる
 &インスタンスが始めから無駄に一個ずつ生成されていてもどうでもいい
 程度の規模ならメリットあり

って感じ?あ、こういうのもあるね。
・中規模...設計がわかった気になった厨くんの自己満足に最適
現場の人間のモチベーションは大事だからね

16 :デフォルトの名無しさん:04/11/09 06:05:50
規模にかかわらず、OOPの真のメリットが理解出来ない人達(残念ながら結構いるよね)を
束ねて開発する際に、始めに指針をきちんと提示してあげればソースの綺麗さを
ある一定の水準に保てることかな。

ちゃんとしたOOPとOOPモドキが混じったソースは汚いことこの上ないからね。
全部構造化設計で共通処理をちゃんとサブルーチン化して、あとは
システムが処理する順番通りに記述していった方がはるかにマシ。
前時代的だけど。

17 :デフォルトの名無しさん:04/11/09 10:05:18
>>15
>大規模...インスタンスの生成管理したいので

これが大変だからDIコンテナ使うんじゃ?
インターフェースによる設計が強制されるし。

18 :太田@会社:04/11/09 11:01:45
15さん>
どんな規模でもユニットテストを厳密にしようと思ったら有効化と。
単体テストの網羅率が低いプログラムを4年もメンテしたら考えが変わりますよ。

19 :デフォルトの名無しさん:04/11/09 11:41:20
>>15
> わざわざxmlに定義するよりPOJOでやった方が簡単

DIで使うのはPOJOなんだけど。
あと、わかんないなら、StrutsとHibernate使うときになんか便利とか、その程度で最初はいいと思う。
基本的にはある種のパラダイムシフトだから、やってみないことにはメリットは実感できないよ。
やらないうちは、ファクトリ書くのとどう違うの?って感じだけど。

「DIってどういうときに便利なの?」っていうのは「オブジェクト指向ってどういうときに便利なの?」という問いがばかげてるのと似てる。

20 :デフォルトの名無しさん:04/11/09 11:46:36
>>18
DI使わないで書いてますので間違ってる所はバンバン指摘してくださいね。

DI使うと単体検査の網羅率が変わるんですか?
どの項目になにを入力したらエラーになる、というのは
結局人が書かないといけないと思うのですが。

太田さんが言われてるのは趣味の延長でやっているような
検査仕様書といえば正常系の画面遷移くらいしか記述しないような
人たちのことを言っていますか?

あえていえば、xmlファイルでクラス名やメソッド名を書き間違えると
実行時クラスキャストエラーになってプログラムが停止してしまうので
最低限一通り正常処理は通しておかないと目も当てられない、
というのはあるかと思いますが、ってこれは極端か。

21 :デフォルトの名無しさん:04/11/09 11:58:02
> DI使うと単体検査の網羅率が変わるんですか?
> どの項目になにを入力したらエラーになる、というのは
> 結局人が書かないといけないと思うのですが

単体検査をやりやすくなるので、網羅率が間接的に変わるかも。
オブジェクトとオブジェクトを結びつけるためだけのコードも減るので、やっぱり網羅率はあがるかも。
ただし、Javaコードの網羅率があがっても、DI定義の網羅率は低いことが多いので、トータルでは変わってないかも。
DI定義のテストをどう考えるか、というのは問題のひとつだと思う。

> xmlファイルでクラス名やメソッド名を書き間違えると
> 実行時クラスキャストエラーになってプログラムが停止してしまうので

該当クラスがないときは、DI定義の読み込み時でエラーになるコンテナが多いので、クラス名の間違いに関してはあまり問題なさそう。
あと、現実問題として、最初のひとつのオブジェクトを読み込むとあとは芋づる式にインジェクションされたオブジェクトを取得するので、クラスのキャストエラーというのも実は心配するほどもない。
Container.getInstance("name")みたいなことをすることは結構少ない。
ということで、やっぱ極端かと。
テストしろよ、という話でもあるし。

22 :デフォルトの名無しさん:04/11/09 11:59:53
>>19

なるほど、言われてみれば確かにポインタを初めて勉強したときも、
ポインタのポインタや関数ポインタの話を聞いたときも、実際に
やってみるまで「なんのためにそんなことをするのか」わからなかった。
TemplateMethodパターンもAbstractProductはともかく、AbstractFactoryクラスまで
抽象化する意味が始めはよくわからなかった。

やってみろというのはその通りだ。でもメリットもわからないうちから
業務には適用できないし(してるアホもいるけどね)、なんか作ると便利なモノないかな。

どうせ時間かけるなら、その時間をOOのスキルアップに使った方が
いいような気がしてDIの勉強に本腰が入らないんだよね。

23 :デフォルトの名無しさん:04/11/09 12:35:48
>>22
「OOのスキルアップ」が足りてないなら、そっちやったほうがいいのかもしれないけど、DIの勉強って、はっきりいってすることないから、ちょっと試しに何か使ってみればいい。
勉強っていっても、ほんとDIってsetXxxメソッド用意して<property name="xxx"><value>aaa</value></property>書くだけで、その文法とコンテナの準備が違うだけだし。
で、これ見ても「だから何?」なんだけど、やってみるとその「だから何?」のためにコードをたくさん書かされていたことに気づく。

24 :デフォルトの名無しさん:04/11/09 12:38:54
コンポーネントの再利用って、DI使わないときには、OOの技術やらデザインパターンの知識と有効活用が必要で、ちょっとキバらないといけないと思うんだけど、DI使うと、システムの一部分がなぜかどこでも使えるようになってたりするから不思議。

25 :22だけど:04/11/09 13:00:00
スキルアップが足りてると思ったら技術者として終わりだよね・・

26 :デフォルトの名無しさん:04/11/09 13:14:47
誰も>>1の綴り間違いに気づかない

27 :デフォルトの名無しさん:04/11/09 13:14:57
技術的な面での知識をつける事は勿論スキルアップだけど
マネジメントの視点から開発効率を考えて
より合理的な方法を探るのも立派な「スキルアップ」だと思うよ。

と自分にも言い聞かせてますけど。
>15の「設計がわかった気になった厨くんの自己満足に最適」
ってのは、ちょっと耳が痛いですなー。

28 :デフォルトの名無しさん:04/11/09 13:58:53
>22自己レス
TemplateMethodじゃなくてFactoryMethodだね

29 ::04/11/09 14:30:33
>>26
>>1の母です。この度は…

スマソ言われるまで気付かなかった。
回線切って首吊って逝ってくる。

30 :太田@会社:04/11/09 14:47:54
えーとすでに21さんが書かれていますが,
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のトレンドとして捉えて触ってみても
損は無いと思うよ。

34 :デフォルトの名無しさん:04/11/09 15:40:29
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で必死に定義書きまくるのはどうなんだといわれりゃその通りですが
結合を疎に持ってく方向自体は間違ってないかと。

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はそれを織り込む仕組みになる。

45 :デフォルトの名無しさん:04/11/09 21:12:15
POJOって何だ?
ただの普通のクラスと何が違うんだ?

46 :デフォルトの名無しさん:04/11/09 21:39:02
むしろ、普通のクラス。
なにか特定のインターフェイスの実装やらクラスの継承を義務づけられてないということ。
だから、RMIのリモートオブジェクトとか、EJBとか、StrutsのActionとかActionFormはPOJOじゃない。

47 :デフォルトの名無しさん:04/11/09 22:47:33
>>30
するってえと太田さんところでは単体検査とは本当にユニット単位で
検査すること(JUnitで出来るようなこと)であって、機能毎にプログラムの
分岐を現実的な範囲内で網羅するような試験ではないって事ですかね。
だとすると私とは前提が違うのでかみ合わないわけですね。

まあもともとDIに興味を持ったからこそいろいろ聞いているわけだけど、
調べていくうちに「なんかなー、いまいち手間に比べてメリットが薄い気がするなー」
というのが正直なところなわけですよ。メリットがあるのはわかるんだけど。
で、みんなにメリットを語ってもらおうと思って質問するんだけど、まだピンと来ない。

EclipseにSpringプラグインをいれたらxmlの定義を書いてるときもコード補完で
型検索とかできるの?

48 :デフォルトの名無しさん:04/11/09 22:49:10
(Springのスレ違から誘導されてきました)

PicoConatiner 1.1出ました。
http://www.picocontainer.org/Download

49 :デフォルトの名無しさん:04/11/09 23:05:27
>>47
> 本当にユニット単位で検査すること(JUnitで出来るようなこと)



> 機能毎にプログラムの分岐を現実的な範囲内で網羅するような試験

って具体的にどう違うの?
後者はJUnitでは出来ないことなんだよね?

50 :49:04/11/09 23:06:18
>>47
DIだけ見てて、AOPを見てないとか?

51 :デフォルトの名無しさん:04/11/10 00:10:47
スレタイが「Dependency Injectionコンテナを語るスレ」だったら
AOPの話題もスレ違いにならなかった罠。

52 :デフォルトの名無しさん:04/11/10 00:17:47
>>47は以下のような依存関係を持つコンポーネントの単体テストを
どうやって実行してるんだろうか。

プレゼンテーション層のコントローラ

ドメイン層のサービス

データソース層のDAO

そもそも「そんな層分割は知らん」とか「一気通貫目視に決まってんだろ」とか
言うんだったら勉強して出直して来い。

「Mockで依存関係を切ってカバレッジ確保してます」ということならまずそこが
DIコンテナの出番。

53 :かくたに:04/11/10 00:21:17
>>51
AOPはスレ違いじゃないと思います。
http://www.kakutani.com/trans/fowler/injection.html#SomeFurtherIssues
>今のところ、本記事ではアスペクト指向については考慮していないが、今後追加するなり、
>他の記事を書くなりして、是非とも取り組んでみたいと思っている。


54 :デフォルトの名無しさん:04/11/10 00:33:54
どーでもいいが、太田君もかくたに君(お子さん誕生おめでとう)も
トリップつけなさい。

http://info.2ch.net/guide/faq.html#C7

55 :デフォルトの名無しさん:04/11/10 00:59:42
>>49
うちの単体は機能単位でできることは出来るだけ網羅したい感じ。
画面遷移して前画面のパラメータも引きずってくるし、桁あふれを
狙うような無茶をするのも単体。テストデータはあまり厳密じゃない。
外部モジュールとは結合しないので代わりにエミュレーターを立てたりする。
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でカバレッジ」っていうのはわからん。



57 :デフォルトの名無しさん:04/11/10 01:19:46
>>52
ちなみにURLおせーて、っていうのは依存関係を持つコンポーネントの単体テストを
JUnitでわかりやすく実施するサンプルとかのことね。
でもコントローラーからdaoまでだったら、たとえばWebアプリなら普通に
URLのGETパラメータに情報載せてセッション帰ってきたらDBにアクセスして
値確認すればいいだけのような気がするけど、違うの?

58 ::04/11/10 01:23:12
すみませんすみません。DI+AOPもアリといういうことでお願いします。

AOP単独だとAspectJみたいな話になるし、そうすると別スレのほうが
いいのかなとか思ったりしますが、皆さんのご判断にお任せします。

初めてスレ立てしたので、気が回りませんでした。
回線吊って首切って逝ってきます。

>>48
オメ!

59 :デフォルトの名無しさん:04/11/10 01:26:35
>>55
> AspectJとかちょこっといじってたし。
> EclipseでTomcatプロジェクトと共用できなくて業務では使ってない。
> AJDT入れると他のプラグインが挙動不審になったりしたし。

> AOPのメリットはDIコンテナいれなくても享受できるでしょ。

享受できてないじゃんw

60 :デフォルトの名無しさん:04/11/10 01:30:29
連書きスマン
>依存関係を持つコンポーネントの単体テストをJUnitで

逆か。依存関係を切ったままJUnitでテストしろって話ね。
まあコントローラーでエラーになることは無いから(なったらテストクラスの
パラメータが足りないって事だから)Modelの段階でのエラーと
daoの段階でのエラーを分けて管理しろという事ですか。うーん、やっぱり
出直して勉強してきた方がいいみたいだけど、どのサイトorどの本を読めばそのメリットがわかる?

61 :デフォルトの名無しさん:04/11/10 01:33:36
>>59
えーっと、俺が享受してたかどうかじゃなくて、DIに時間を割くべきかどうかの判断に
AOPは含まないよ、DI無しでAOPだけ導入することもできるから、って言いたかったんだけど
っていうか細かいツッコミにいちいち反応するなよ<俺って感じ?

#これだけ書く時間があったらDIのサンプルぐらい動かせそうだな・・

62 :デフォルトの名無しさん:04/11/10 01:35:33
>>56
JUnitをいままでのテストを置き換えるものとしてとらえなくてもいいんじゃない?
むしろ、プログラマがプログラムが動いて自分の作業が完了したというためのものという感覚で。
いままでなら「コンパイルが通っただけでできたっていうなバカ、動作テストしたのか?」っていうところを、「ユニットテスト作ったのか?」っていう感じで。

63 :デフォルトの名無しさん:04/11/10 01:42:18
>>61
いや、>>55の書いていたような理由から、だれも実業務でAspectJなんか使えないし、つまりAOP使えてなかったんでしょ。
ほんとにAspectJでAOPだけ導入ができると思う?
で、DIコンテナですよ、と。
結局DIコンテナを評価するべきで、SpringとかSeasarとかはデータベース抽象化機能を提供してて宣言的トランザクションが使えて、と。
実際問題、DIコンテナは、宣言的トランザクションが気軽に使える仕組みだと最初はとらえていいんじゃないかと思ったりする。

64 :63:04/11/10 01:48:00
と勢いだけで書いてみたけど、AspectJで実際にシステム組んでるところってあるのかな?
パイロットプロジェクトという意味合いではなく。

65 :かくたに ◆572YBhdE/s :04/11/10 01:53:05
>>54 ありがとうございます。コテハンといっても基本ヲチなので捨てハンみたいなもんだからトリップ無用かな、と。
# とりあえずつけてみるテスト

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を持ち回らないでどうやって別々のトランザクションとして実行するのか
疑問だったんだけど。


67 :デフォルトの名無しさん:04/11/10 02:06:46
>>66
ThreadLocal

68 :デフォルトの名無しさん:04/11/10 02:08:01
>>67
もしくはJTA

69 :63 =67:04/11/10 02:13:09
>>66
> AspectJが駄目だからDIコンテナをAOP込みで評価しろってことね。
そう。
つまり言語拡張の仕組みは受け入れにくいから、現実的にAOPのためにはDIが最適解かと。
それと、上の方に書いたけど、さまざまなオブジェクトから参照されるオブジェクトを横断的関心事として考えると、DIで横断的にインジェクションということも考えられる。

ThreadLocalは、サーブレットでのリクエストごとの情報を渡すのにとっても役に立って素敵。

70 :デフォルトの名無しさん:04/11/10 02:14:58
POJO
ぽじょ

POJD
ぽじゅどぅ

後者を発音すると一瞬自分がフィリップ・トゥルシエになった気分が味わえます(ウソ)。

71 :デフォルトの名無しさん:04/11/10 02:18:23
>>69
> 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
>>73
http://forum.javaeye.com/viewtopic.php?t=5280
を読め。

じゃなくて>>65を読め。

75 :デフォルトの名無しさん:04/11/10 02:30:05
結論:良さの判らない頭の悪い香具師は無理して使わなくて結構。

76 :デフォルトの名無しさん:04/11/10 02:34:12
ageてまでいうことかと

77 :デフォルトの名無しさん:04/11/10 02:35:41
かくたにさんとか太田さんとか良く名乗りを上げられるなと感心する。
本人かどうか疑えばきりが無いけどきっと本人でしょ?すごいな。

78 :73:04/11/10 02:46:59
>>74
つまりPOJDっていうのは、Javaの基本文法とJ2SEのライブラリは知ってるけど、他のライブラリとかフレームワークは知ったこっちゃない開発者ってことですね?

79 :73:04/11/10 02:52:48
中国語サイトのは、アノテーションのない普通の宣言ってことか。
みんなみんな、プレインオールドっていいたいだけ違うんかと。
そんなにプレインオールド好きなら、頭髪までプレインオールドになってしまえw

80 :デフォルトの名無しさん:04/11/10 02:54:56
>>78
Rod Johnsonにその文面英語に訳してメール送ってみろ。

つーかおそろしく下手な煽りだな。

81 :80:04/11/10 02:56:14
訂正。

>>79は煽りとして合格。

82 :デフォルトの名無しさん:04/11/10 02:59:40
見事な釣り師だということだな。
素直に釣られたことを認めた>>80も天晴だ。
今日も快晴だな。

83 :デフォルトの名無しさん:04/11/10 03:01:03
>>82
おっすオラ>>80
おめえけっこういいやつだな。

84 :デフォルトの名無しさん:04/11/10 03:04:18
Plain Old = 平凡な
PORH = 平凡なRod Hair

…普通じゃん。PORH!! ぽー! ぽー!!

85 :73:04/11/10 03:05:53
ショボーン(´・ω・`) ( ´・ω) (  ´・) (   ) (・´  ) (ω・´ ) (`・ω・´)シャキーン

86 :デフォルトの名無しさん:04/11/10 03:19:45
MOJOなんてのもあるぞ。

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とい
うわけです。

89 :太田@会社 ◆TDNdW1Xcyo :04/11/10 10:35:47
失礼しました。つけ方間違えました。

90 :デフォルトの名無しさん:04/11/10 12:40:38
まだDIも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で依存性を排除できればそれぞれ担当者が単体テストを
実施できて網羅率を上げることができる。


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という手法があると捉えています。

レビューしないでスキルの低い技術者が作ったものがそのまま放置されるのは
いただけないですよね。レビューアがスキルの高い人のやり方をスキルの低い人に
伝えていくことができればいいんですけどねえ。レビューによって詳細な進捗もわかるし。

専門の組織があるのは微妙ですね。レビューはプロジェクトリーダーがやって、
リーダーは自分の範囲内の仕様は把握していて、突発的な欠員がでても
代わりの人にちゃんと引き継げるくらいの近さがいいと思ってます。
太田さんとこは大きな会社っぽいので組織変更は難しいでしょうけど。

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が多くなるよ。

102 :デフォルトの名無しさん:04/11/11 00:52:04
91の主張はマクロな視点だとその通りなんだけど、
実際クラス間に依存があるテストを行う場合、どちらかのテストを先にするしかなくなるんだよね。
すべてのクラスにDI適用させるのは無駄だし

103 :デフォルトの名無しさん:04/11/11 01:00:52
俺はOOすることとDIすることは全く別次元
(相補的ではあるが依存でも排他でもない)
だと思うんだが、認識間違ってるのかな?

>100
interface は別に増えてもかまわないのでは。
増えることでどんなメリットとデメリットが出るかが重要なのであって。

>102
91氏は依存性がある場合はA→B→Cの順にやる、
って明言してると思いますが。

なんか1氏の思惑通りにはスレが進んでない気がするよ。

104 :デフォルトの名無しさん:04/11/11 01:04:36
DBのWebフロントエンドだと、結果的にすべてのクラスにDI適用させることになったりして。
で、そういうアプリケーションだと、せいぜい継承くらい知っておけば、OOの知識というのもほとんど必要なかったり。
細切れの独立したクラスをDIで結びつけるわけで。

105 :デフォルトの名無しさん:04/11/11 01:09:14
>>103
> 俺はOOすることとDIすることは全く別次元
> (相補的ではあるが依存でも排他でもない)
> だと思うんだが、認識間違ってるのかな?

DIはOOの上に成り立ってると思うが。
OOする、っていうのがなんのことなのかよくわからんけど。

> なんか1氏の思惑通りにはスレが進んでない気がするよ。

荒れてないし、いいんでないの?

106 :デフォルトの名無しさん:04/11/11 01:25:39
>>103
91はそれぞれ独立してテストするって言ってるでしょ。
あともしテストするなら順番逆になるよ

107 :デフォルトの名無しさん:04/11/11 01:27:32
結局DIも適用させる範囲絞らないと効率悪くなるから
トレードオフなんだよね

108 :デフォルトの名無しさん:04/11/11 01:51:55
>106
>順番逆になる
そうですね。うっかりしてました。

>独立してテストするって言ってる
? DIで依存性を排除できれば、では?

ところでDIって一言でいった場合、どういう意味なんでしょうか。
相関するモジュール群の結合を疎にし、コードベースではなく
コンフィグレーション(XMLファイルがありがち)によって結び付ける、
程度の意味だと思ってたんでOOの上とは違うよな、と思ってしまうんですが。

109 :デフォルトの名無しさん:04/11/11 01:54:30
クラスとクラスの関連が強いんであっても、そのクラスを取り替えることがなかったり、オブジェクトを一つずつしか生成しないんだったら、あまりDIの意味はないね。
業務アプリみたいに、似たようなクラスと別の似たようなクラスをいろいろな組み合わせで関連させるものだとDIのやりがいがあると思う。

110 :デフォルトの名無しさん:04/11/11 01:57:30
>>108
オブジェクトとオブジェクトを結びつけるものだと思うので、OOありきかと。
OOじゃない技術の上でDIするためには、結局OOじゃない技術の上でOOみたいなことをしてないとDIできないんじゃないかと。

111 :デフォルトの名無しさん:04/11/11 02:46:44
>>108
コードベースじゃないとは限らないよ。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フレームワークのほうが偉いと思うよ。

114 :デフォルトの名無しさん:04/11/11 13:27:01
>>113
>だから、eclipseを見習おうといいたい。
>extension point をアプリ側で定義する。
>変更箇所が多そうなところを見つけてうまく定義すると素晴らしいアプリケーションになる。

具体例を提示されたことで、なんか目の前が開けてきました。

115 :デフォルトの名無しさん:04/11/11 13:28:21
まあ、extension pointっていっても、そんなもん無くたってプラグイン機構は作れるんだが
ここで人間の感性が反映されるわけ。コードの表現力が。
DIが悲しいのは、苦労して導入したところで、手間の割に表現力に乏しいところだと思うんだよ。
それと、DIを導入することで、初心者にも仕事をまかせられるとかいう意見あるけど、
これはどうも、いまいち。あやしい。
そんなことやる暇あれば仲良くなるためにどうすればいいか、考えたほうがいいなと。

116 :デフォルトの名無しさん:04/11/11 13:33:50
eclipseの設計思想は、googleで
"the eclipse house rules"

を検索されたい。
なぜこんな素晴らしい設計指針がマッチする文章がPDF一枚なのかは謎だが、
結局地道にこれを実践することがいいアプリを作る唯一の方法なのだと漏れは結論する

117 :デフォルトの名無しさん:04/11/11 15:48:40
DIだけだとそうかもしれんが、DI+AOPだと業務アプリには欠かせない。
デスクトップツールやライブラリ自体には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つかって独立性を高くってできないような感じ。

121 :デフォルトの名無しさん:04/11/11 17:48:29
>>115
>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コンテナ使った場合の特徴。

125 :124:04/11/11 18:34:29
SpringとSeasarでは、今のところSpringの方が導入が楽。
Seasarは、現時点では周辺ライブラリの充実度やドキュメントの整備など今一歩のところがある。
ただ、のびしろとしてはSeasarの方があるので、S2JSFとSeasar自体のブラッシュアップ、ドキュメントの整備、英語圏へのプロモーションが進めば大ブレイクするかもね。
今は中の人が盛り上がってるだけだけど、このままのモチベーションで開発が続けば1年半後くらいがみものかも。

126 :124:04/11/11 18:41:35
そういう意味では、情報集約サイトとして機能してないホームページをどうにかして欲しいんだけど、S2JSFとセミナー準備で手一杯のようだ。
年があけたころから機能していくんじゃないかと、外野から見て思う。

127 :デフォルトの名無しさん:04/11/11 18:49:04
>>123
テキストエディタで設定ファイルを書くのは確かに面倒。特にSpring。
そこでEclipseプラグインの出番。SpringやS2にはすでにある。
S2のKijimunaというEclipseプラグインは設定ファイルのエディタを提供してくれる。
XMLの要素や属性の補完だけではなく、クラス名やプロパティ名も補完してくれるから
面倒さはほとんど感じない。


128 :124:04/11/11 18:54:43
SpringはAOPの定義がクソめんどいね。
技術的にはSeasarの方がかなりいいと思う。
ただ、現状スウィートスポットがSpringより狭い印象がある。けど、時間の問題。

129 :デフォルトの名無しさん:04/11/11 19:00:22
>>125
Seasarに足りない周辺ライブラリって?
Springの方が充実してるのは確かだと思うけど,
差があるのはJDOとかiBATISとかVelocityとかSpring MVCとか、
なくても困らないようなマイナーなものばっかりじゃない?
そのためにSpringとは思わないけど。

130 :デフォルトの名無しさん:04/11/11 19:16:33
>>129
そりゃ、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のどちらにするかの
判断材料となるほど影響力のあるプロダクトのサポートに違いが
あるのか聞きたいということなので許してほしい。


134 :124:04/11/11 20:07:20
>>132
たぶん、多くはないんだろうけど、それなりに開発をやってると、なにか一つマイナーなライブラリを使ってたりして、Springだと検索するとみつかる感じ。
その代表がiBATISってことで。

>>133
しがらみなく新たに開発だと、そこまで影響力のあるライブラリの違いは確かにないと思う。
Hibernate2対応とかそれぞれのライブラリをみると、むしろSeasarの方に軍配があがるとも思うし。
S2DaoがiBATIS自体を補完すると思うので、新たにiBATIS対応する必要もない気もする。
だから、若干スウィートスポットが狭いと感じるのも時間の問題だと。

135 :デフォルトの名無しさん:04/11/11 20:11:48
>>124

>それと、業務で作った機能がなぜかライブラリとして独立した形になっている

もう、そんな幻想だれが信じるんだよ。
ひとつでいいから実例見せてくれ。

> ただ、現実的には、DIコンテナの価値は、その周辺ライブラリ
ツールに頼る必要のないところでなんでそんなにツールマンセーになれるのか不思議だよ。
そんなにツールのこと学ばなくても、シンプルに設計することを知らなきゃ意味ないし、
シンプルに設計することはツールは必要ない。

136 :124:04/11/11 20:29:30
>>135
実例としては、DIコンテナの周辺ライブラリ。
DIコンテナって、周辺ライブラリがたくさんあるけど、それは、簡単にライブラリ化できるから。
公式じゃなくてもSpringXXXとかS2Xxxとかいっぱいある。

DIコンテナは周辺ライブラリあってナンボだと思ってて、DIのみ語ってめんどくさそうとか言ってもしかたないと思ってるから。
で、周辺ライブラリがそろってるDIコンテナはSpringとSeasarになるかと。
もちろん、DIはDIでとても有意義なものだと思うけど。
比較的あたらしいスレでこんなこというのもなんだけど、現実的には「DIってどうよ?」という段階はすでに過ぎてると思う。

> ツールに頼る必要のないところで

だって、便利だし。
あと、SpringとかSeasarって、使っててもそんなに依存するものじゃないから、Spring+Hibernate+StrutsでやってるものをSpringからSeasarに乗り換えるのも、そこまで苦ではない。

> シンプルに設計することはツールは必要ない。

知識も必要だし、ツールも必要だと思う。
もちろん、デザインパターンってなに?という人だけが集まってDIを活かせるとは思わない。
DIでのシンプルな設計を学ぶには、DIコンテナ使う必要はあると思う。

137 :124:04/11/11 20:32:12
誤解のないように補足しておくと、Springでやってるプロジェクトを途中からSeasarに切り替えるのはもちろん作業時間てきに無駄。
ではなくて、前のプロジェクトをSpringでやってて、次のプロジェクトはSeasarでっていうときに、前のプロジェクトの成果物の再利用に苦労はそれほどないってこと。

138 :124:04/11/11 20:42:37
ぶっちゃけ言えば、Web+DBの業務アプリで、プログラム自体の設計に頭を使ってもしかたないと思う今日この頃。

139 :デフォルトの名無しさん:04/11/11 20:55:48
>>134
> たぶん、多くはないんだろうけど、それなりに開発をやってると、なにか一つマイナーなライブラリを使ってたりして、Springだと検索するとみつかる感じ。
> その代表がiBATISってことで。

ああ、なるほどね。納得した。


140 :デフォルトの名無しさん:04/11/11 21:00:58
>>135

> もう、そんな幻想だれが信じるんだよ。

信じなくてもいいよ。出てきたばかりのものに実績とか言われてもな。
オブジェクト指向だって何10年かかってようやく今の認知度だ。

> そんなにツールのこと学ばなくても、シンプルに設計することを知らなきゃ意味ないし、
> シンプルに設計することはツールは必要ない。

考え方とツールが別というのはわかるけど、ツールがないのに考え方ばかり
論じてたって形あるものにはならんと思うよ。


141 :デフォルトの名無しさん:04/11/11 21:01:30
>>138
俺も同意する。

142 :デフォルトの名無しさん:04/11/11 21:11:40
なあ>>135よ、オマエさんはきっと出来る奴なんだろうな。
ところでな、オマエさんのその考えとかを同僚とかはすぐに理解してくれるかい?
もしそうなら恵まれた職場にいるし、だったらDIなんてものはオマエさんには不要だ。
こんなところでつまらない連中を相手にしてるのは勿体無いと思う。

しかしな、オマエさんが周囲の奴を見て使えねえ連中ばっかりだと思うなら
DIはひょっとするとオマエさんを楽にさせてくれるかも知れないよ。

なあ>>135よ、オマエさんのはオマエさん並みに出来る奴ばっかりか?


143 :デフォルトの名無しさん:04/11/11 21:12:49
>>142

× なあ>>135よ、オマエさんのはオマエさん並みに出来る奴ばっかりか?
○ なあ>>135よ、オマエさんの周りはオマエさん並みに出来る奴ばっかりか?


144 :デフォルトの名無しさん:04/11/11 21:20:41
DBを使用しないWEBアプリでDIコンテナを使うメリットってありますか?
自宅PCにWEBブラウザでアクセスして、2ちゃんブラウザのログを更新したり
閲覧したりしたいだけなんだけど・・・・・・・

こういう用途でも使えるものなんでしょうか?>DIコンテナ

145 :デフォルトの名無しさん:04/11/11 21:43:45
単機能のアプリケーションだとあまりメリット感じれないかもね。
自分なら、とりあえずDIコンテナ使うけど。すでにある程度慣れてるから。

146 :デフォルトの名無しさん:04/11/11 22:08:44
自分なら、とりあえずEJB使うけど。すでにある程度慣れてるから。

147 :デフォルトの名無しさん:04/11/11 22:11:58
>>144
その程度だたらperlとかrubyとかの出番じゃない?

148 :デフォルトの名無しさん:04/11/11 22:17:12
>>144
そのアプリってログはどうするのかな。自分で保持しつづけるの?
もしそうなら、仮にDBを使わなくてもストレージ管理が必要になるよね。
テキストファイルなんかでもさ。それがちょうどORMツールみたいな
位置付けになるから、DIは有効だよ。
テキストファイル管理コンポーネントを自作するとしてもPOJOで済むしね。
でももしログを持ちつづけるならDBを使ったほうが楽だと思うよ。
インストールが面倒ならPure JavaのDBでもいいんじゃないかな。

もし単なる串を作りたいならどうだろうね。漏れならDI使うと思うけど
もっと別の方法でもいいかも知れないね。串を作ったことがないから
よくわからない。ごめん。

>>146はすごいね。尊敬するよ。

149 :デフォルトの名無しさん:04/11/11 22:18:12
>>147
そういえば、PerlやRubyのDIも上のほうで紹介されてるね。
これを使うというのはどうなのかな?

150 :デフォルトの名無しさん:04/11/11 22:42:52
>>142
> 出来る奴ばっかりか?

うるせー。漏れが出来ようが出来まいが回りがどうだろうが
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の魅力を感じとりやすいと思う。

152 :デフォルトの名無しさん:04/11/11 22:46:03
>>150
この俺様がクマー

153 :デフォルトの名無しさん:04/11/11 22:54:13
>>150
>>依存は少ないほうがよい。
わかってんじゃんw

154 :デフォルトの名無しさん:04/11/11 22:54:53
>>150
よくわからんな。藻舞は言語標準のAPIしか使っちゃ駄目だと
いいたいわけか? Jakarta-commonsも使わないか?

そもそも開発者の腕に依存するのとツールに依存するのでは
前者のほうがリスクが高いと思うんだがどうよ。
藻舞の腕に依存するほうが恐いんだよ。なまじ優秀であるほどな。
代わりがきかんだろうが。



155 :デフォルトの名無しさん:04/11/11 22:55:20

   ∩___∩         |
   | ノ\     ヽ        |
  /  ●゛  ● |        |
  | ∪  ( _●_) ミ       j
 彡、   |∪|   |        J > DIに依存するアプリを作るのはリスクです。
/     ∩ノ ⊃  ヽ  
(  \ / _ノ |  |
.\ “  /__|  |
  \ /___ /

156 :デフォルトの名無しさん:04/11/11 23:04:17
DI使っててもこちらからコンテナのクラスを直接利用しなければ大丈夫でしょ。


157 :デフォルトの名無しさん:04/11/11 23:06:38
なあ>>150さんよ、気に障ったなら悪かった。でもなあ、
>DIは何の解決にもならないだろう。当たり前の話だ。
というけど本当かなあ。何かは解決してるんじゃないかい?

EJBだって今でこそ大袈裟とか言われているけどさ、
透過的なトランザクションとかとても大きなテーマを
解決したからここまできたんだと思うんだよ。

DIも何かを解決してくれるんじゃないのかなあ。
>>150さんよ、オマエさんから見るとDIってのは
本当にまったく何もないものなのかなあ。

158 :デフォルトの名無しさん:04/11/11 23:37:28
>>147
最初はCGIで書いてたんですが、自宅PC−出先間の暗号化とか、2ちゃんブラウザに近い機能の
追加(透明あぼ〜んとかログ検索とか)を考えると、このままCGIとして書いていっていいのかな?と
もっと上手い方法があるんじゃないかと巡回してたら、ここをみつけたという次第です。

>>148
自宅PCではOpenJaneDoe(2ちゃんブラウザ)を使ってるんですが、これを会社に持ち込む事はで
きないんで、会社ではWEBブラウザを使って2ちゃんを読んでます。
でも、これだと会社で読んだ内容が2ちゃんブラウザのログには反映されず、非常に不便です。
そこで、これをどうにかできないかな?というのが出発点なんで、ログは2ちゃんブラウザのログそ
のもの(2ちゃんブラウザから読めないと意味がないので)をガリガリ更新する予定です。

とりあえず、この様な用途にも使う事はできる、そしてメリットも(大小の違いはある様だけれど)ある
という感触を得たんで頑張ってみます。

159 :デフォルトの名無しさん:04/11/11 23:50:54
>>156

>>150タソはそこら辺が納得できないらしい。

160 :デフォルトの名無しさん:04/11/11 23:56:56
DIコンテナの周辺ライブラリに依存することに危惧を持ってるみたいだね。
たしかに、S2DaoとかS2JSFとかSpringMVCとか、大がかりなものだとそういう危惧はあるかもしれんけど。
HibernateとかStrutsとかの対応だと+αだし、そもそものHibernateやStrutsへの依存度が減るから、問題ないと思うんだけどね。
DIだけだと、依存度もなにも、単なるクラス作るだけだからあまり問題ないし。

161 :デフォルトの名無しさん:04/11/11 23:57:46
>>158
会社が2chを読んじゃいけないと決めてるんだから、抜け道作って読むのはやめなされ。

162 :デフォルトの名無しさん:04/11/12 00:31:44
>>161
禁止されてるのはソフトウェアのインストールで、2ちゃんを読む事じゃないんで
その点は大丈夫です。

163 :デフォルトの名無しさん:04/11/12 01:00:38
しかし、そこまでして会社から2chをみるかと・・・

164 :デフォルトの名無しさん:04/11/12 01:15:07
このスレは一見盛り上がってるように見えるが、
厨が暴れる+まともな人間が折伏するという構図で
レスがついているだけだ。

165 :デフォルトの名無しさん:04/11/12 01:18:40
>>164
2chだからね。

166 :デフォルトの名無しさん:04/11/12 01:21:12
>>150
そんなに既存のDIコンテナに依存するのが嫌だったら、
自分で作ればいい。

setter injectionだけサポートするような簡単なやつだったら
数日で作れるよ。

# 作れないくらいスキルが低いんだったらこのスレにもう来るな。

AOPとか、このスレの上のほうに出てた副次的なメリットは
享受できなけどね。

167 :デフォルトの名無しさん:04/11/12 01:22:40
そういうのを盛り上がってるというんだよ。
まともな議論やら正確な情報で淡々と流れるスレなんて盛り上がってるって言わない。

168 :デフォルトの名無しさん:04/11/12 01:31:54
>>166
俺様ライブラリに依存ならOKっていうのも
>>150の主旨と違うと信じたいけどね。

まあ>>150が腕のいい釣り師だというのは
認めようや。

169 :デフォルトの名無しさん:04/11/12 01:35:57
で、結局>>150が複数コンポーネントの依存関係をどうやって
解決してるのかが全く見えないわけだが。

釣り師じゃなくて真性厨だろう。

170 :デフォルトの名無しさん:04/11/12 01:43:26
スレと関係ないんだけどさ、俺「釣り」とか「釣り師」っていうのは、

 釣り師 ↓     .
           /| ←竿
     ○  /  |
.    (Vヽ/    |
    <>     |
゙'゙":"''"''':'';;':,':;.:.,.,__|_________
             |
  餌(疑似餌)→.§ >゚++< 〜
                 の組み合わせだと思ってたんだけど、

最近自称釣り師がダイレクトで自分の本音を攻撃されて「釣れた!」とか
言ってるの多いよね。
 これは、どっちかというと、



          ,〜〜〜〜〜〜 、
|\     ( 釣れたよ〜・・・)
|  \    `〜〜〜v〜〜〜´
し   \
゙'゙":"''"''':'';;':,':;.:.,.,  ヽ○ノ
          ~~~~~|~~~~~~~ ̄ ̄ ̄ ̄ ̄ ̄ ̄
                 ト>゚++<
              ノ)

かと思うんだけど、どうよ?

171 :デフォルトの名無しさん:04/11/12 01:45:49
>>170
          ,〜〜〜〜〜〜 、
|\     ( 釣れたよ〜・・・)
|  \    `〜〜〜v〜〜〜´
し   \
゙'゙":"''"''':'';;':,':;.:.,.,  ヽ○ノ
          ~~~~~|~~~~~~~ ̄ ̄ ̄ ̄ ̄ ̄ ̄
                 ト>゚++<
              ノ) ←>>150


172 :デフォルトの名無しさん:04/11/12 02:43:23
クラス図で書いてくれ

173 :デフォルトの名無しさん:04/11/12 04:53:49
___________________
|<<interface>>|
|   ネタ   |
 ̄ ̄↑ ̄ ̄ ̄
________|_____________   ____________
|釣りラー >>150|◇--|釣りリー|
 ̄ ̄ ̄ ̄ ̄ ̄ ̄    ̄ ̄ ̄ ̄

174 :デフォルトの名無しさん:04/11/13 03:24:09
>>142の「DI=低スキル志向」ロジックは意味不明。
くーすマンセー君かな。とりあえずPofEAA読みなよ。

まあ、それ以上に>>135が駄目すぎるわけだが。

175 :デフォルトの名無しさん:04/11/13 04:24:57
>>174
そうやって、高いところから見下ろす態度は、あまりよくないと思われ。
ダメなやつは何をやってもダメ、とか、禁句ですよ。

176 :デフォルトの名無しさん:04/11/13 09:14:33
>>175

そんなこというと何もいえなくなってしまうではないか。窒息死する。

DIは普通にOOPするのと何が違うのかってところで、
何も使わないのと何も変わらない。変わらないなら使わないほうがいい、っていう

この考えの人を納得させる意見と、自己満足のdiブロガーには物凄い開きがあるわけ。

納得させるためにはどうするか。
もうね、ネット上でどうこうやってもダメよ。実社会でdiについて話して、diでビジネスをやる。
これしかない。

177 :176:04/11/13 09:16:10
いや、まぁ漏れは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
何だ単なるアンチか。

180 :デフォルトの名無しさん:04/11/13 10:01:30
>>176
>自己満足のdiブロガー

何だ個人攻撃したいだけか。
ところで>>176は実際に
何かDIコンテナ使ってみたのか?


181 :デフォルトの名無しさん:04/11/13 10:33:02
結論としては、やっぱ構造化プログラミングが一番だね。でFA?

182 :デフォルトの名無しさん:04/11/13 12:19:21
>>121
> Eclipseのプラグインは見事だと思うけど業務アプリには
> それこそ手間の割にメリットがないと思う。

これが無いならそもそもなんでわざわざdiを導入しなきゃならないのか
コンポーネント化するってことは取り外しが簡単だからだろ?
それをしたなくなきゃプログラミング言語の機能を使って普通にOOPするのだ。

183 :デフォルトの名無しさん:04/11/13 12:39:37
>>182
Eclipseだとプラグイン横断的な機能はどうやって作るの?

184 :デフォルトの名無しさん:04/11/13 12:46:53
AspectJ

185 :デフォルトの名無しさん:04/11/13 12:48:15
>>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の功績だし。


188 :デフォルトの名無しさん:04/11/13 13:05:28
>>185
>別の仕組み

「仕組み」とは何なのか
モジュール化、依存性を少なくして簡潔なシステムにするための仕組みであるなら、
それは普通にOOPするのと何が違うのか。
そこがどうにも弱いんだな。

ソフトウェアをパーツ化して取り外し可能にすることが目的、そういう仕組みが欲しいなら、
アプリケーション側でその拡張方法を定義するのが礼儀だと思う。
だからそういう機能がお好みなら、そのときは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が引き受けてくれます。

190 :デフォルトの名無しさん:04/11/13 14:24:37
Eclipseのプラグインてそれだけでひとつの製品レベルの大きさだやなと思ったりする。
漏れは頭が悪いからやっぱりプラグインにはSOAだよとでも逝ってみる。

191 :デフォルトの名無しさん:04/11/13 14:25:22
コピペうざい。

192 :デフォルトの名無しさん:04/11/13 17:16:23
>なんでプラグインアーキテクチャを持ち出してDIコンテナに反論
>した気になってるのかね。

そういうところがdiのメリットだと思う人がいそうだったから。
コンポーネント化がメリットだって言うんでしょ?
それをやるにもdiは中途半端でOOPやるのと大差ないってことを言いたかった。

そのblog読んだけど、もしJavaでサーバサイド業務アプリが作りたくて
プラグイン機構欲しい場合は、plexusはイイかもしれませんな。
(詳細は知らんので断言できないけど。)

193 :デフォルトの名無しさん:04/11/13 17:20:35
> 1. ソースコードへの修正を加えずに実装を切り替えることができる。

これだが、いい加減、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に移しているだけの話。

なんでもかんでも仕様と実装に分けてしまうのは可読性を落とすだけだが
適切な箇所で使うのなら、なんら問題ないかと

197 :デフォルトの名無しさん:04/11/13 17:57:24
文章に関してはみんなヘタレのような希ガス

198 :デフォルトの名無しさん:04/11/13 18:28:42
スクリプト言語だって、ちょっと規模が大きくなれば
設定として切り出せる部分はどんどん外に追い出すもんだと思ってるんだが、
193氏はなんでもかんでもソースに書きたい人なの?


199 :デフォルトの名無しさん:04/11/13 18:37:57
ソース厨ハケーソ

200 :デフォルトの名無しさん:04/11/13 18:53:19
>>193

スクリプト言語を使いたきゃ使えばいい。S2GroovyBuilderでググれ。



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に戻ってきたら、その時は考え直す。

206 :デフォルトの名無しさん:04/11/13 21:04:39
>>202
制御構造使いたいときって、あるものなの?

207 :デフォルトの名無しさん:04/11/13 21:26:25
>>192
plexusが良くて他のDIコンテナだと何がいかんのか?

208 :デフォルトの名無しさん:04/11/13 23:01:10
>> 198
> 設定として切り出せる部分はどんどん外に追い出すもんだと思ってるんだが、

切り出し可能な部分はっていう意味か?

仕組みさえ用意すれば、現在の依存性注入に加え、繰り返し条件、条件分岐、
フィールドの型まで設定ファイルに追い出せる。実現できれば、ほとんどの
問題は解決じゃないか。

198 氏はなんでも XML に書きたい人なの?

209 :デフォルトの名無しさん:04/11/13 23:28:09
>208
有意なレベルであればなんでもかんでも外出ししたいですよ。
ただ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 の
策定メンバーとあるが、名前や肩書きを鵜呑みにするのは危険だな。

お前のように。

214 :デフォルトの名無しさん:04/11/14 13:39:28
>>213の元ネタ(Amazon書評)をコピペ。

> レビュアー: さすらいのスナフキン (プロフィールを見る)   九州福岡 Japan
>  本書の内容は悪くないと思います。しかし、色々なプロセスや手法を解説しているものの、
> 著者達自身が実際にどこまで理解できているかがはなはだ疑問の解説があることが残念。
> 特にCMMの部分はかなり間違った解釈(要件が安定していないと適用は難しいとか重量で
> 融通が利かない風な解説)が多い上に、実際にあまり著者自身が実戦経験がないと
> ハッキリ分かってしまう部分がある。著者の一人はビッグネームであり、もう一人は
> CMMIの策定メンバーとあるが、名前や肩書きを鵜呑みにするのは危険であるという
> 証明になるかもしれない。
>  これからプロセスや手法及びプロジェクト管理を学ぼうと思う人は、
> あくまで1つの本として参考にすることが必要だ。

ほぼそのまんまだね。

悲惨な風景だ。

215 :デフォルトの名無しさん:04/11/14 14:01:56
>>213はスナフキン

216 :デフォルトの名無しさん:04/11/14 14:06:01
さあ 盛  
       り 
         上
            が
              っ
               て
                参
                 り
                  ま
                   す
                   た


217 :デフォルトの名無しさん:04/11/14 14:26:27
確か山本昌邦氏が言ってたんだけどさ。

最近のサッカーやってる大学生はバイタルエリアが何たらとか
やたら戦術的なことを聞きたがるんだが、実際にプレーさせて
みると基本中の基本インステップキックひとつまともに蹴れない
なんてケースが多いらしい。

以上、このスレの口先DIイラネー厨を見て思い出した話。

218 :デフォルトの名無しさん:04/11/14 14:34:06
S2とSpring、
どっちがいいの?


219 :デフォルトの名無しさん:04/11/14 14:51:01
>>217
それってこのスレの参加者全員に言えそうな感じ。
例えば、>>218に対して技術的な具体例を交えてきちんと
返答できる人って何人も居ないんじゃないか?

220 :デフォルトの名無しさん:04/11/14 15:33:08
>>182
> Eclipseのプラグインは見事だと思うけど業務アプリには
> それこそ手間の割にメリットがないと思う。
>
>これが無いならそもそもなんでわざわざdiを導入しなきゃならないのか

極論好きだな。

DIさえ使わないのは右すぎ。
Eclipseプラグイン的なのは左すぎ。
DIコンテナ使うのが中庸。

ってだけなんだけど。
当然コンテキストに依存するけどね。
漏れの場合は数人〜数十人でWebアプリ作る場合を想定してる。

221 :デフォルトの名無しさん:04/11/14 16:51:30
パクリ>>213の謝罪まだー?

222 :デフォルトの名無しさん:04/11/14 16:57:41
>>221
パクリだと?本人に決まってるじゃないか!
ね?>>213タソ

223 :デフォルトの名無しさん:04/11/14 17:08:16
>>222
あースマン本人だろうね(w

ちなみにCMMに関する記述のどのへんが間違いなのか、
本文の記述を引用して解説してくれないか。>>213

…プププ…。

224 :デフォルトの名無しさん:04/11/14 17:33:00
>>218
定義ファイルが強力でシンプルに書けるのはS2
国際的に普及しているのはSpring
S2のライブラリで気に入ったものがあって、足りないものがなければS2
JetSpeedとか、S2が対応してないもの使うならSpring
今後もしばらく、Hibernateなんかの各ライブラリはSpring対応しかしないことが多いと思うから、S2のほうはS2の中の人ががんばって対応する必要がある。

純粋に技術的なところで比べれば、S2の方が定義ファイルが書きやすくていいけど、実際問題、大差ない。
どっちでもいいから、やりやすそうなのを使えばいい。

225 :デフォルトの名無しさん:04/11/14 17:52:08
確か山本昌邦氏が言ってたんだけどさ。

最近のサッカーやってる大学生はバイタルエリアが何たらとか
やたら戦術的なことを聞きたがるんだが、実際にプレーさせて
みると基本中の基本インステップキックひとつまともに蹴れない
なんてケースが多いらしい。

以上、このスレの口先DIマンセー厨を見て思い出した話。


226 :デフォルトの名無しさん:04/11/14 18:02:17
こぴぺうざ

227 :デフォルトの名無しさん:04/11/14 19:08:22
>224
俺も Spring の定義ファイルはどうにかならんもんかと思った。
けど現実に Spring の方が人気あるように見えたので
そっち採用になりますた。Ruby と Perl & Python もそうだけど
プロジェクトリーダーが日本語使うのやめて
英語圏向けのリリースを一義にせん限り
ジリ貧は免れないような気がします。

初めに Spring 使うこと決めてしまったので
S2 に関してはあまり調べてなかったり。

228 :デフォルトの名無しさん:04/11/14 19:21:29
>>227
autowireとかparentとかうまく使えば、まあなんとか楽になると思う。
AOPなんか、自分では使わないw。

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使わなかった場合と比べてどうなのかわかんないし、
説明しようも無いと思う。

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
>>232
>>233

駄目だよ。

厨くんはJUnitすら使ったことない初心者なんだからもっと優しくしてあげないと(w

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と関係あるのか?

243 :デフォルトの名無しさん:04/11/14 23:43:19
>>242
まー、しいて言えばキモいとこかな。DI 廚と同じく。

244 :デフォルトの名無しさん:04/11/14 23:49:10
>>243









( ´_ゝ`)フーン

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

・どうしようもなくなると教えて君に一時的に変身する。

同一人物な気がするんだが。

248 :デフォルトの名無しさん:04/11/15 00:09:38
>>247
そんなことはどうでもいい。DIについて語れ。


249 :デフォルトの名無しさん:04/11/15 00:15:47
>>248どうした?

250 :デフォルトの名無しさん:04/11/15 00:19:09
ファウラーたんも言ってる通り、ある程度の規模にならないとメリット見えないよ。
それまではServiceLocatorでいいんじゃね

251 :デフォルトの名無しさん:04/11/15 00:23:57
>>250
Fowlerが言ってるのは規模の問題じゃないよ。

そのコンポーネントが他のアプリケーションで使われることを
想定するかどうかでしょ。

252 :デフォルトの名無しさん:04/11/15 00:35:12
>>250
あとAOPね。

ってスレの最初のほうの話題が輪廻転生してんじゃねーかボケ。

253 :デフォルトの名無しさん:04/11/15 00:36:09
まだ「コンポーネントの再利用」なんて夢を見てる香具師がいるのか…。

254 :デフォルトの名無しさん:04/11/15 00:40:23
>>251
ほかのアプリケーションで使われるかどうかは関係ないよ。
単に結合を疎にするための方法のひとつってだけだから。



255 :デフォルトの名無しさん:04/11/15 00:47:12
>>254
以下の通り大いに関係があると書いてあるんだが。
意見を述べるのは自由だが、出典を偽装するのはやめろ。

> ところが、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
>>253
ネタじゃなくてループだとしたら真性のアホだな。

>>24とか>>124を忘れたのか?

258 :デフォルトの名無しさん:04/11/15 00:53:03
>>257
>>135-136もお忘れなく。

259 :デフォルトの名無しさん:04/11/15 00:53:07
>>24を間に受けるのはちょっと厳しい。

260 :デフォルトの名無しさん:04/11/15 00:54:37
そりゃ、やらなきゃわからんだろうって。あいだに受けてもしかたないし。

261 :デフォルトの名無しさん:04/11/15 00:57:37
>>260
> あいだに受けてもしかたないし。

ワロタ

262 :デフォルトの名無しさん:04/11/15 01:00:40
  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>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に関しても同じことを考えてることがうかがいしれる。

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

280 :デフォルトの名無しさん:04/11/15 11:12:00
結局、DIを使うことと普通にOOPするのと何が違うのさ
誰か教えてくれ

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


283 :デフォルトの名無しさん:04/11/15 12:17:00
>>280は放置でお願いします。

284 :デフォルトの名無しさん:04/11/15 13:32:26
>>276>>277も放置でお願いします。

285 :デフォルトの名無しさん:04/11/15 13:56:58
277はただの誤爆か、非常に筋違いか、まあ一目見てDIのこととは関係ないことがわかるんだけど、276ってなんなの?
パッケージのことを「依存関係を整理する仕組み」といってるの?

286 :デフォルトの名無しさん:04/11/15 13:57:53
>>283-284
自分の発言が含まれていないか、どきどきする
>>290も放置でお願いしてみます。

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の実装を切り替えることが困難になってしまう。
実装の切り替えを行いたいという要件がなければこのままで何も問題ないが
適切な箇所で実装の切り替えを可能にしておくと、テストの時とか何かと嬉しい。
不要な人には不要だろうけどね。

296 :デフォルトの名無しさん:04/11/15 23:48:33
>>295
DIを使ったところで、実装への依存を完全になくせるわけじゃないから、DIは不要。



とかまた言い出しそうだ。

297 :デフォルトの名無しさん:04/11/16 00:09:20
>>295
それはそうなんだけどさ。そういうメリット一式は>>1のリンク先に既出なんだよね。

んで支離滅裂アンチDI厨は一切メリットが理解できないらしい。たぶん層分割とか
TDDとかちゃんと考えて設計したことがないんだろうね。

298 :デフォルトの名無しさん:04/11/16 00:11:10
  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>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のことですね?

304 :デフォルトの名無しさん:04/11/16 00:42:50
>>301
とりあえず無闇にageるな。ノイズが混じる。

305 :デフォルトの名無しさん:04/11/16 02:24:48
>>279
それみたけど、DIだけを考えたら確かに無闇に適用すべきじゃない、というのはごもっとも。
でも今のDIコンテナはAOPと組み合わされて強力になったわけで、
そのあたりを過小評価してないだろうか、と思った。

DBのトランザクション制御が必要なアプリケーション(ほとんど全てのアプリケーションだが)
ならDIコンテナを使って恩恵にあずかれるだろうから、
むやみやたらに使ってもいいんでないかいと思ってる。
漏れ最早DI原理主義者ですから(w

まあ、本気でむやみやたらに使ったらあかんけど。それは当然。
ある程度アーキテクチャはきめとかないとな。くーすとかでいいと思うけど。


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では。
「インターフェースを相手にコードを書く」ことに慣れているか否かの問題で
あるような気もする。

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要らず。

314 :デフォルトの名無しさん:04/11/16 09:09:56
>>312
認定厨だね。

315 :デフォルトの名無しさん:04/11/16 09:10:58
>>313
いいねぇ、いちいちファクトリ作る工賃まで請求できて。

316 :デフォルトの名無しさん:04/11/16 09:12:47
>>313
> 実装を切り替えたいシーンってそんなに無いし

「テストしてないし」に聞こえるのは気のせいか・・・

317 :デフォルトの名無しさん:04/11/16 09:20:57
>>315
アホか。ほんの数行の決まりきったクラスだ。
しかもDIよりこちらのほうがコードの意図が明白。美しい。DI依存せずピュアなOOプログラミングである。
これでDI依存から脱北しよう。

318 :デフォルトの名無しさん:04/11/16 09:37:15
>>317
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要らずのシンプルな解決法を教えて欲しいところです。

320 :デフォルトの名無しさん:04/11/16 10:34:30
ほんの数行の決まりきったクラスを
interface ごとにわざわざ作るんですか?
ソース自動生成とかで?
まさか手で書くとは思いたくも無いけど。
DI排除してまで無駄に手間をかけるメリットってなんだろう。

321 :デフォルトの名無しさん:04/11/16 11:00:23
>>317
いいねぇ、ほんの数行の決まりきったクラスを、それもDI使えば不要になるクラスを書く工賃がもらえて。
なんか、関数ポインタのポインタとか駆使して、OO言語を不要といってるようなむなしさを感じる。

322 :デフォルトの名無しさん:04/11/16 12:19:27
>>317
実行時にDIコンテナに依存しない代わりに
コンパイル時から俺様Service Locatorに
依存してる状態に退化してるだけだろ。

センス悪いと思う。

323 :デフォルトの名無しさん:04/11/16 12:40:39
ていどひくい

324 :デフォルトの名無しさん:04/11/16 13:14:21
>>322

まぁセンスの問題だな。漏れはDIは気持ち悪いんでこれでいいよ。
実はあんまりJava使わないしな。

325 :デフォルトの名無しさん:04/11/16 13:22:12
>>319
>fooが他のクラスとの依存関連がある場合を考えて
>依存先のクラスを誰が生成して誰が関連付けるか

それはそうプログラミングする以外手は無いと思うんだが
DI使おうが使うまいが同じ

326 :デフォルトの名無しさん:04/11/16 14:10:01
依存関係があるクラスを「書く」のはプログラムする以外にないだろうけど、
複数の依存関係にあるオブジェクトを、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
>>324
> 実はあんまりJava使わないしな。

逃げに入りましたよ。
Javaをあんまり使わず、テストもロクにやってない人にDI不要とか自作ファクトリーで十分とか言われても説得力が・・・

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 に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ?

333 :デフォルトの名無しさん:04/11/16 23:42:44
>>332
論破して欲しくて、DIの良さを教えて欲しくて、ここに書き込んでるんだろ?
ふがいなくてごめんな。

334 :デフォルトの名無しさん:04/11/17 00:04:29
XML がソースそのものだと言ったが、もうひとつ。

 DI 廚 = マップ廚

分かるか?実行時解決マンセー!?
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成マンセーとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。

なんなら俺が DI + II(Implementation Injection)コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ?

335 :デフォルトの名無しさん:04/11/17 00:04:42
>>333
まーな。おまいらも、もう少し欠点を出し合って議論しろよ。
わざと盲目的に良い点だけ見てるわけでもないだろ。

336 :デフォルトの名無しさん:04/11/17 00:06:28
>>334
勝手にコピペすんな。

337 :デフォルトの名無しさん:04/11/17 00:06:38
>>332

> なんなら俺が DI + II(Implementation Injection)コンテナでも作ろうか。

是非作ってください。オープンソースで。おながいします。
いつ出来ますか?

338 :デフォルトの名無しさん:04/11/17 00:07:42
XML がソースそのものだと言ったが、もうひとつ。

 DI 廚 = マップ廚

分かるか?実行時解決マンセー!?
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成マンセーとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。

なんなら俺が DI + II(Implementation Injection)コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ?

339 :デフォルトの名無しさん:04/11/17 00:11:38
>>334
問題提起になってない。くだらん。

340 :デフォルトの名無しさん:04/11/17 00:13:09
>>332
設定をXMLで行うことのデメリットについては認識しているよ?

何故、DIの必要性について議論が分かれるかといえば
君がメリットを正しく理解できていないからだと思う。


341 :デフォルトの名無しさん:04/11/17 00:16:53
>>332
> どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
> 生成マンセーとかいう香具師もいたな。何が犠牲になってるかも分からずに
> 実行時なんたらって言いたいだけちゃうんかと。

AOPとか、O/Rマッピングの定型的な処理とかでバイトコード生成を使うと
何が犠牲になるのか説明してくれないか。

342 :デフォルトの名無しさん:04/11/17 00:30:57
>>332
単なる「依存性の実行時解決」と、「型と実装の実行時解決」が
ストレートに結びついてしまうとは素晴らしい思考回路ですね。

343 :デフォルトの名無しさん:04/11/17 00:34:05
実行時解決のリスクについて言いたかっただけでは?

344 :デフォルトの名無しさん:04/11/17 01:04:44
↓ここのseasar株上昇ってところ
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

347 :デフォルトの名無しさん:04/11/17 01:34:27
>>332
何が犠牲になってるのか、解説キボンヌ

348 :デフォルトの名無しさん:04/11/17 01:47:34
>>332
吉野家コピペみたいに流行るといいね。
どこに貼ろうかな。

349 :デフォルトの名無しさん:04/11/17 01:58:31
>>348
くだらんもん流行らすなよ・・・それじゃ、ただの荒らしじゃねぇか。

350 :デフォルトの名無しさん:04/11/17 02:01:29
DI は実装の注入を含蓄してると思うのは俺だけですか?
DI+IIって、頭痛+頭がガンガンする、くらいにくどい気がするのは俺だけですか?
>332って>208の後半部と同じこと言ってる気がするのは俺だけですか?

>214に対する回答ってどこに書いてあったか、誰かご存知ないですか?

351 :デフォルトの名無しさん:04/11/17 02:25:48
>>348
既にこのスレが荒らされてるし(w

352 :デフォルトの名無しさん:04/11/17 02:26:39
>>350
だからもはやネタスレだってば

353 :デフォルトの名無しさん:04/11/17 02:28:56
  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>213タン再登場まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/


354 :デフォルトの名無しさん:04/11/17 02:30:47
アーキテクチャの変化についていけない人が、そんな自分を正当化するスレです。

355 :デフォルトの名無しさん:04/11/17 02:32:28
ひとりの人格が崩壊していくのをリアルタイムで見ている気分だ。
この先こいつが死んだりしたときに非公開の日記にこのスレのことが
書かれてたりすると、果たして冷静でいられるのだろうかと思ったりする。











…ま、そうなっても同情しないけどな。

356 :デフォルトの名無しさん:04/11/17 02:34:38
>>354以下の通り要訂正。

アーキテクチャの変化についていけない半端者が、そんな自分を正当化しようとしてその他大勢の袋叩きに会うスレです。

357 :デフォルトの名無しさん:04/11/17 02:36:09
>>355
禿藁 && 禿胴

358 :デフォルトの名無しさん:04/11/17 02:40:57
ファクトリ作るのと変わらんって言ってるけど、そこから先の差がでかいんだよね。
ORマッピングとかも、データ取ってくるだけならDbUtilsと大差ないけど、そこから先の差がでかい。

359 :デフォルトの名無しさん:04/11/17 02:42:50
>>358
ネタスレにつきマジレス不要(w

360 :デフォルトの名無しさん:04/11/17 02:45:07
そこから先の差がでかいって言ってるけど、ファクトリ作るのと変わらないんだよね。
ORマッピングとかも、そこから先の差がでかいって言ってるけど、DbUtilsやらMapへの流し込みと大差ない。

361 :デフォルトの名無しさん:04/11/17 02:49:11
>>355の心配は杞憂だったようだ。>>360は元気だ。

ゾンビみたいな奴だな。

362 :デフォルトの名無しさん:04/11/17 02:49:18
>>360
孤軍奮闘












ガンガレ!偉いぞ!






…俺は賛同できないがな。

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
>>365
複雑なロジックって何?
具体的に言ってね。

367 :デフォルトの名無しさん:04/11/17 03:01:35
>>364
zombieだからゾンビ、ゾンビアー、ゾンビエスト!じゃないかな。

>>365
「自業自得」って言葉を知ってるかな?

368 :デフォルトの名無しさん:04/11/17 03:01:48
>>365
身のほどって何?
具体的に言ってね。

369 :デフォルトの名無しさん:04/11/17 03:02:16
DIの
わは
かば
らか


370 :デフォルトの名無しさん:04/11/17 03:03:12
>>367
スマソ 勉強になりますた。
回線切って首吊ってゾンビになるます

371 :デフォルトの名無しさん:04/11/17 03:03:58
>>369
もうちょっと頑張ろうね。立て読みは本文が皮肉になってないと面白くないよ

372 :デフォルトの名無しさん:04/11/17 03:04:52
>>371
3レスつれたら上等。

373 :デフォルトの名無しさん:04/11/17 03:06:11
>>360>>362のガンガレという言葉に妙に禿増されてしまうヤシ

374 :デフォルトの名無しさん:04/11/17 03:07:25
キミらネタに反応しすぎ。

375 :デフォルトの名無しさん:04/11/17 03:08:32
ついに360=362は369のようなしょぼいネタに走ってしまったのか??

376 :デフォルトの名無しさん:04/11/17 03:09:27
>>374の正体は、実はみんなが反応してくれて喜んでいる>>360だったりする

377 :デフォルトの名無しさん:04/11/17 03:10:01
>>371
>>375
ワラタ

もしかしてマジレス?

378 :デフォルトの名無しさん:04/11/17 03:10:43
ΣΣ(゚д゚lll) バレタヨ
さらに =>>358だったりして。

379 :デフォルトの名無しさん:04/11/17 03:12:34
で、本物の厨は今頃回線切って首吊って本物のゾンビになってると。

380 :デフォルトの名無しさん:04/11/17 03:12:35
さあ 盛  
       り 
         上
            が
              っ
               て
                参
                 り
                  ま
                   す
                   た






………………微妙にな。

381 :デフォルトの名無しさん:04/11/17 03:14:48
>>377
マジもマジ、大マジよ!
ゾンビだぜ!!

382 :デフォルトの名無しさん:04/11/17 03:16:53
微妙だな。

383 :デフォルトの名無しさん:04/11/17 03:17:09
>>332タンのおかげでスレが盛り上がって楽しい夜でした。ありがとう。

つーか二度と来るんじゃねーぞボケが。

384 :デフォルトの名無しさん:04/11/17 03:20:12
キミら、早く寝なさい。
こんなとこで遊んでるヒマがあったらドキュメント書きなさい。

385 :デフォルトの名無しさん:04/11/17 03:20:58
>>383
そんなに邪険にしないでください。
ネタスレなのにネタを投下する人がいないと閑古鳥でつ。
体を張って笑いを作ってくれている>>332タソはいい人でつ。
でもそろそろ>>213のオチをつけてくれると嬉しいでつ。

386 :デフォルトの名無しさん:04/11/17 03:23:55
>>384

ドキュメントを書くのは馬鹿です。漏れはマスをかきます。

>>332は、DI + II(Implementation Injection)コンテナを書くそうです。
早く書いてください。ガマンできません。

387 :デフォルトの名無しさん:04/11/17 03:24:29
>>385
> でもそろそろ>>213のオチをつけてくれると嬉しいでつ。

そうだね。ちなみに俺は>>214=>>383

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
>>385
君はあれか。S2スレでひがたんのうんことか言ってた奴か。

文体が一緒なんだが。

392 :デフォルトの名無しさん:04/11/17 03:31:58
このスレはすべて外部からインジェクションされてますが、なにか?

393 :デフォルトの名無しさん:04/11/17 03:32:34
>>390
じゃあこんなつまらんことで板に負荷をかけたことを反省して
回線切って首吊ってとっとと逝ってこい。

394 :デフォルトの名無しさん:04/11/17 03:40:57
>>391

ひがたんのうんこと言ってたのは別の人でつ。
うんこと言ってる人に粘着してみたでつ。

でもあっちのスレにはネ申が降臨したでつ。


文体に敏感な>>391はきっとひがたんをうんこといったやつでつ。


同じ人が同じ文体で書くと思っているのがウブでつね(藁





でつなんて普通にみんな2chなら書くでつよ。プププ



次は何に粘着する気だ?バーカw

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
>>394がいい感じにスパークしてるわけだが。

今夜のオチとしてはイマイチだな。

399 :デフォルトの名無しさん:04/11/17 03:46:32
バーカバーカ!
お前の母ちゃんデベソ!


400 :デフォルトの名無しさん:04/11/17 03:46:53
>>396
女子供ですが、チンコのサイズはオトナです。

401 :デフォルトの名無しさん:04/11/17 03:48:20
いい加減寝ろよお前ら。微妙に期待してしまって寝れないじゃないか(w

402 :デフォルトの名無しさん:04/11/17 03:49:23
>>400
使えないチンコはサイズ無関係にコドモです。チンカス洗えよ。

403 :デフォルトの名無しさん:04/11/17 03:49:27
>>401
そこで満を持して>>213タン登場ですよ。

404 :デフォルトの名無しさん:04/11/17 03:50:08
>>402
むくと痛いです(;_;)

405 :デフォルトの名無しさん:04/11/17 03:50:23
内容は悪くないな

406 :デフォルトの名無しさん:04/11/17 03:52:16
>>404
使えねえ

>>405
半端に>>213かよ!

頼むからお前ら寝ろよ(w

407 :デフォルトの名無しさん:04/11/17 03:53:25
>>406
眠れねーよ。

お前のように。

408 :デフォルトの名無しさん:04/11/17 03:53:57
今夜は寝かさないぜ!






























おやすみなさい

409 :デフォルトの名無しさん:04/11/17 03:57:57
今このスレに何人いるんだ?
点呼だ点呼!
いち!
次!!

410 :デフォルトの名無しさん:04/11/17 04:00:59
2!
誰もいないようだな。俺も寝るぞ。じゃあな。

411 :デフォルトの名無しさん:04/11/17 04:02:22
>>409-410
もうお前ら2人しかいないから寝なよ。

とりあえず参。


412 :デフォルトの名無しさん:04/11/17 04:06:34
353あたりから4人でやってるね。4さまですた。

413 :デフォルトの名無しさん:04/11/17 04:07:58
そのうちひとりは>>213かな?
とりあえず5だ。おやすみ。

414 :デフォルトの名無しさん:04/11/17 04:12:36
俺もいるぞ。6な。寝る。

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
中身のないスレだな 7だ。

419 :デフォルトの名無しさん:04/11/17 08:44:44
じゃあ、中身のあるネタを。

ローサが・・・ΣΣ(゚д゚lll)
しかも、話題の主題ではない。orz
ttp://220.111.244.199/otakara/1116idol01.jpg

420 :デフォルトの名無しさん:04/11/17 09:40:47
DIは夜中にレスが100進むくらいの人気と関心のある、
ナウでホットなトピックなんですよ!

と言えば上司も分かってくれる。

421 :デフォルトの名無しさん:04/11/17 20:01:30
>>XML自体がソースコードだということに気づけ。
そこでTigerですよ。

と知ったかしてみる。

422 :デフォルトの名無しさん:04/11/17 20:02:14
ナウなヤングがフィーバーしてるスレはここですか?

423 :デフォルトの名無しさん:04/11/17 21:16:54
>>421
そこでCocoon2ですよ、ってのは?

424 :デフォルトの名無しさん:04/11/18 01:21:55
>>423
XSP自体がソースコードだと言うことに気づけ、と大喝されるよ、きっと。ハァハァ。

425 :デフォルトの名無しさん:04/11/18 01:26:57
S2スレからコピペ。

> 563 名前:デフォルトの名無しさん 本日のレス 投稿日:04/11/18 00:06:17
> DIはある意味ではハシカみたいなもんじゃないかと思います。
>
> 思い起こせば、Javaを覚えたてのころは継承を乱用し、
> GoF本を読めば(作ってるシステムにとって)意味のないクラスを量産し、
> 作ってる本人はご満悦ですが、保守する人とかどうしてるんだろう、
> と思う今日このごろなコードもかつては作ってしまった気もします。
>
> ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。
>
> 新しい設計技法、言語、ツールを知ると使いたくなるというのは
> 技術者の真っ当な感情だと思いますが、下手に使うとまわりが被害をこうむりますかも。
> あと、伝染性がある上に発病期間までに時間があったりすることも。
> ちゃんとテストして(使ってみて)、これは行けると踏んでから、
> まずはリスクの少ない部分から適用していきましょうと(予防接種)。
>
> 生産性と品質に対して何の寄与もしないどころか、
> 足を引っ張るだけのフレームワークにハメられた僕は
> 別な何かが見える様になったと思います。

426 :デフォルトの名無しさん:04/11/18 01:31:48
>>425の論法

・継承やDPの乱用はよくない。
・継承やDPは導入期に大いにもてはやされた。
・よって導入期に大いにもてはやされているDIの乱用はよくない。

ただの一般論かよボケが。

で、DIの乱用ってのが具体的にどういう層への適用なのかが
全く提示されていないわけだが。

427 :デフォルトの名無しさん:04/11/18 01:35:32
>>426
いや、>>425って別の文章のコピペネタだから。

428 :デフォルトの名無しさん:04/11/18 01:38:48
さあ今夜もはじまりました!

429 :デフォルトの名無しさん:04/11/18 01:41:17
>>427
orz
回線吊って首吊ってゾンビゾンビアーゾンビエストになって帰ってくるよ 。

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スレの方が賑やかっぽい?

435 :デフォルトの名無しさん:04/11/18 01:50:58
425はSpringがDIだと知らない悪寒

436 :デフォルトの名無しさん:04/11/18 01:52:16
>>434
決定的にS2スレのほうが盛り上がってるね。
要因は品質でもシェアでもなく、単に中の人が
見てるかどうかの違いかと。

437 :デフォルトの名無しさん:04/11/18 01:56:40
ネタスレには人が集まるもんさ。

438 :デフォルトの名無しさん:04/11/18 01:59:52
425はS2スレのこぴぺ
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を見ても動じなくなります。

440 :デフォルトの名無しさん:04/11/18 02:12:23
ネタスレはある意味ではハシカみたいなもんじゃないかと思います。

思い起こせば、2chを覚えたてのころはageを乱用し、
スレ立てを知れば(見ている板にとって)意味のないスレを量産し、
カキコしている本人はご満悦ですが、ROMする人とかどうしてるんだろう、
と思う今日このごろなレスもかつては書いてしまった気もします。

ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。

新しい粘着対象、2ch語、AAを知るとカキコしたくなるというのは
ネラーの真っ当な感情だと思いますが、下手に書き込むとまわりが被害をこうむりますかも。
あと、伝染性がある上に発病期間までに時間があったりすることも。
ちゃんとテストして(スレの空気を読んで)、これは行けると踏んでから、
まずはリスクの少ないカキコからレスしていきましょうと(予防接種)。

スレの流れとネタに対して何の寄与もしないどころか、
足を引っ張るだけの>>332に釣られちゃった僕は
別な何かが見える様になったと思います。

441 :デフォルトの名無しさん:04/11/18 02:15:22
元ネタ
http://d.hatena.ne.jp/taichitaichi/20041116#p1

しみじみ読んじゃったよ。うーむ。
俺も今、中学男みたいに頭のなかタップンタップンで
抗体が出来てないんだろうなあ。

442 :デフォルトの名無しさん:04/11/18 02:21:15
>>441
こぴぺされたのはそれに対するレス
http://d.hatena.ne.jp/muimy/20041117#1100683249

443 :デフォルトの名無しさん:04/11/18 02:23:10
1の思惑をはるかに飛び越えて立派なネタスレになった。
思えば dependncy な時点でネタスレ化は必定だった。

444 :デフォルトの名無しさん:04/11/18 02:35:15
そうだな。1よGJだ。
ところで今夜は>>213>>332のような剛の者は出てこないのかな。

445 :デフォルトの名無しさん:04/11/18 02:36:46
>>444
とりあえず今夜も呼んどくか。

  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>213タン再登場まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/


446 :デフォルトの名無しさん:04/11/18 02:37:49
  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>332タンDI + II まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/


447 :デフォルトの名無しさん:04/11/18 02:38:09
念のため。

>>213の凄さについては>>214を参照。

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 はこんな感じでやってみようと思う。

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かよ!

454 :デフォルトの名無しさん:04/11/18 03:01:33
>>450
オブジェクト指向が必要なら、DIも必要じゃねぇか。

455 :デフォルトの名無しさん:04/11/18 03:04:49
はっきり言って、業務アプリは、関数だけあれば作れます。間違い無い。
継承すらイラナイかもしれない。と思う今日この頃。
DIなんて不要。間違い無い。
せいぜい流行語大賞。間違い無い。

456 :デフォルトの名無しさん:04/11/18 03:05:05
akon氏がくーすのことを「21世紀の手続き型」とか言ってたような。
良い意味で悪い大人だな。

457 :デフォルトの名無しさん:04/11/18 03:05:29
>454
そんなことを書くとピュア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は不要です。
お偉いさんはそこがわかっとらんのです。

468 :デフォルトの名無しさん:04/11/18 03:21:03
ネタとしていまいちだな。寝るよ。

469 :デフォルトの名無しさん:04/11/18 03:21:46
言葉遊びだからな。
おやすみ。

470 :デフォルトの名無しさん:04/11/18 12:29:00
オッス! オラ悟空!!
なんかこのスレの>>332から邪悪なでっけえ気を感じて来てみたんだけどよ。
・・・う・・あ・・・な、なんて気だ!!
今のオラじゃ、とてもかないそうにねぇ!!!
20倍界王拳でも全然相手になりそうにねぇ!!!
でもよ、こんなにヤバイ状況だってのにオラ、ワクワクしてきたぞ!!!
この世にこんなつえぇ奴がまだ居たなんてよ!!
おっと、感激してる場合じゃねぇな。
なんとか>>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の勉強して問題ないですよね。

477 :デフォルトの名無しさん:04/11/18 21:08:27
活字の情報はSpringの方が多いな。
ネットの情報だと、どっちも同じくらいじゃないの?

478 :デフォルトの名無しさん:04/11/18 21:14:57
漏れはS2派だが、まずはSpring触ることをお薦めする。
ある程度DIを理解したところで、他のDIコンテナにも触れてみるといいんじゃないかな。

479 :デフォルトの名無しさん:04/11/18 21:24:13
>>478
オレはSpring派っていうか、とりあえず今はSpring使っててSeasar2は使ってないんだが、その理由が気になる。

480 :デフォルトの名無しさん:04/11/18 21:38:21
やっぱりDIの出発点だと思うから<Spring
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が先。

485 :476:04/11/18 22:09:52
Springからやってみます
みなさまdクスコ

486 :デフォルトの名無しさん:04/11/18 22:12:11
そんな理由だったらわざわざ苦労して面倒なほうを触る必要も無いと思うんだけどね。

487 :デフォルトの名無しさん:04/11/18 22:14:22
>>484
「両方やりたいなら」という条件つきなんだね。
今回は、どちらかやりたいということで、無関係な意見ではある。

488 :デフォルトの名無しさん:04/11/18 22:20:21
こちらも盛り上げてくれ

Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/l50


489 :デフォルトの名無しさん:04/11/18 22:39:09
とりあえず今夜も呼んどくか。

  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>213タン再登場まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>332タンDI + II まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/


490 :デフォルトの名無しさん:04/11/18 22:53:12
>>488
デンパを発してないからなぁ

491 :デフォルトの名無しさん:04/11/18 22:59:04
S2の優位点って設定の容易さだけなのかな。

だとしたらSpringに仕様改善提案するなり
設定のフロントエンドだけ差し替えたりって対応も
ありだと思うんだが。

492 :デフォルトの名無しさん:04/11/18 23:33:01
>>491

> だとしたらSpringに仕様改善提案するなり

是非してくれ。いやマジで。

493 :デフォルトの名無しさん:04/11/19 00:34:26
>>483
Rubyは海外で使われてるし国内でも開催されてないRuby単独カンファレンスが米国で開催されてるし、Rubyを扱う会社もあるよ?


494 :デフォルトの名無しさん:04/11/19 00:42:06
たしかにRubyはすでに海外でもメジャーになりつつあるね。英語本の翻訳本が存在するくらいだし。
日本が一番活発なコミュニティなんだろうけど、Groovyが出た時でも「Rubyのようなスクリプト言語の
利点を...」って海外でも紹介されてたし。

まあS2がそこまでいけるかどうかは、露出度次第だと思う。
でも今は露出より開発進めることじゃないかな。S2JSFとかS2Flexとか。

495 :デフォルトの名無しさん:04/11/19 01:14:31
大事なのは、酒を飲むことです。

496 :デフォルトの名無しさん:04/11/19 06:22:35
>>491
Rod的には、あの設定ファイルのクドさがたまらなくイイんだろ。


497 :デフォルトの名無しさん:04/11/19 16:29:38
面倒なことくらい分かりきってるのに
(<property name="hoge">... よりも <hoge>.. の方が
特殊な性癖の御仁を除けば読みやすいだろう。)
あえて採用してるところからして、永久未来クドいままだろう。

498 :デフォルトの名無しさん:04/11/19 19:02:57
>>497
それやっちゃうとXMLのバリデーションができないからでしょ。
S2だってやってないし。

それにそんなレベルの問題だったらコードアシストで解決できる。

499 :デフォルトの名無しさん:04/11/19 19:06:34
失礼。問題にしてるのは読みやすさか。だったらコードアシストは関係なかったな。

そういう観点からすると、groovyベースとかが主流になったほうが良いのは確かだね。

500 :デフォルトの名無しさん:04/11/19 20:45:56
ということは、Spring用のツールが普及して定義ファイルを見なくてよくなることがあれば、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
>>500
何で定義ファイルを見なくて済むようになるのがSpringだけだと感じるのかわかりませんね。
2行目以下はアホの戯言ですね。もう少しネタになるようにしないと>>213には勝てませんよ。


505 :デフォルトの名無しさん:04/11/20 00:52:53
>>504
ん?
Seasarも定義ファイルみなくなっていいけど、そのとき「SpringよりSeasarの方が定義ファイルの記述が楽」という現状唯一の優位性がなくなるんじゃないの?

506 :デフォルトの名無しさん:04/11/20 00:55:12
>>505
未来と現状を混ぜて考える理由が不明です。


507 :デフォルトの名無しさん:04/11/20 00:56:48
504氏は新しいタイプのネタ?
S2信者を装ってSpring派との分断を謀る策士に違いない。

508 :デフォルトの名無しさん:04/11/20 01:08:09
>>506
あぁ、つまり、現状で定義ファイルの記述が楽だから過渡的にSeasar使ってるだけで、Springのいい感じのツールが広まったらSpring使えばいいってことね。

509 :デフォルトの名無しさん:04/11/20 01:09:04
>>505
お前SpringもS2も触ってないだろ。
正直に言ってみろ。

510 :デフォルトの名無しさん:04/11/20 01:10:49
>>508
それでいいんじゃないですか?本当に広まったらね。
ところでSpringに詳しそうだからいつどういうツールが出てくるのか教えてくれないかな。

511 :デフォルトの名無しさん:04/11/20 01:34:15
>>507
また今夜もネタ師降臨か!?
寝させてくれよ頼むから。

512 :デフォルトの名無しさん:04/11/20 01:37:49
とりあえず今夜も呼んどくか。

  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>213タン再登場まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>332タンDI + II まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/


513 :デフォルトの名無しさん:04/11/20 01:38:56
>>510
こんなんが使えるようになれば、それはそれで鬱陶しくていいかも。
ttp://www.springframework.org/spring-ide/eclipse/BeansGraph.png

514 :デフォルトの名無しさん:04/11/20 01:39:16
>>214のナイスアシストがなければ>>213はネ申にはなれなかった。
よって>>214が真の神!

515 :デフォルトの名無しさん:04/11/20 01:45:29
>>513
アンチDI厨が喜んで叩いてきそうだ

516 :513:04/11/20 02:07:50
一応種明かししておくが、513の画面はリードオンリーね。

517 :デフォルトの名無しさん:04/11/20 12:06:06
仕様書より先にコーディングするDQNのコードを解析する為のものか…。

518 :デフォルトの名無しさん:04/11/20 12:39:50
>>517
いや、ただSpringのBean定義を表示するだけ。

519 :デフォルトの名無しさん:04/11/20 12:55:22
>>295
>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スレでネタやるよりはマシ。次善の策ということで。

525 :デフォルトの名無しさん:04/11/21 21:40:05
何が次善の策なのか。
スレ違いうざいんだよ。

526 :デフォルトの名無しさん:04/11/21 21:42:00
あっちが荒れるよりは、こっちが荒れる方がマシって事だろう>次善の策
どっちも中身の無さでは大差ないけどなw

527 :デフォルトの名無しさん:04/11/21 21:45:02
あっちでスルーしてればいいだけじゃん。わざわざ別のスレ荒らす理由にはならん。
それとも図星指されて顔真っ赤ですか?

528 :デフォルトの名無しさん:04/11/21 21:45:56
今夜は俺が呼ぼう。

  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>213タン再登場まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>332タンDI + II まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

529 :デフォルトの名無しさん:04/11/21 21:47:58
>>527
コピペしたい年頃なんだろ。
>>522>>213に憧れてるんだよ。

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 語らんくせにネタのひとつも書けんのか。
くだらん。うんこスレか禿スレに戻るか。

536 :デフォルトの名無しさん:04/11/23 00:12:52
>>535
騙るなよ。俺が本物の>>213=>>322だ。
つまんねーんだよボケ。

537 :デフォルトの名無しさん:04/11/23 00:36:27
NetBeansはBean定義ファイルからオブジェクト生成コードを自動生成するというおもしろいDIのしくみをもっています。
最古のDIコンテナはDelphiです。
Delphiはフォームデザインをコンポーネント定義ファイルに保存して、Application.createFormとするとコンポーネント定義にしたがったフォームを生成してくれます。

538 :デフォルトの名無しさん:04/11/23 00:53:40
>>536
はぁ? かっこつけて騙ったうえ、リンク間違いかよ w
あほですか?w

539 :537:04/11/23 01:08:10
Delphiはデータベースのコネクションなど非視覚部品もコンポーネントとして配置できたり、自分で自由にコンポーネントを作成できたりしたので、まさにDIコンテナです。
VBはそこらへん弱かった。

540 :デフォルトの名無しさん:04/11/23 01:17:20
>>535のように暇じゃないのでコピペする時間も惜しい。だから今夜も俺が予防


  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>213タン再登場まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>332タンDI + II まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/


541 :デフォルトの名無しさん:04/11/23 01:18:21
>>538
あほちゃいまんねん
ぱーでんねん

542 :デフォルトの名無しさん:04/11/23 01:23:25
>>540
乙。

>>535みたいな偽者は放置で。

543 :デフォルトの名無しさん:04/11/23 01:57:36
>>537
どのへんがDependencyのInjectionになってるのかよーわからん。

544 :デフォルトの名無しさん:04/11/23 02:03:39
どっちのこと?
NetBeansも、フォーム定義からフォームとボタンの間に依存性を注入するコードを生成するわけだし。
Delphiは、完全にDIコンテナだよ。
データベースとフォームを関連付けるのに、コードを書く必要はない。
フォーム定義は、ビーン定義になってる。
ただフォームエディタで見た目をいじくれるようになっているからコンポーネントが重いだけ。
DIコンテナの要件にPOxOであることが含まれるなら、DIコンテナではない、という程度。

545 :デフォルトの名無しさん:04/11/23 02:27:03
>>541
オサーンは黙ってろ。

546 :デフォルトの名無しさん:04/11/23 02:28:55
>>544
えーと。あんた自動なら、なんでも DI か。おめでたいな。

547 :デフォルトの名無しさん:04/11/23 02:31:03
>>540
☆ チン
を NG ワードにしますた。
☆ カン
とかすんなよ。

548 :デフォルトの名無しさん:04/11/23 02:33:06
>>544
で、それは type なにになるの? 新しい type か?

549 :デフォルトの名無しさん:04/11/23 02:37:51
>>542
>> >>535みたいな偽者は放置で。

Uzeeeeee 俺は本物だ、ボケ、氏ね。


これでいいか?w
お前の幼稚な煽りにノッてやる w

550 :デフォルトの名無しさん:04/11/23 02:42:06
ここは英単語の前後に半角スペースが多いインターネットですね。

551 :デフォルトの名無しさん:04/11/23 02:45:13
明日以降は↓でよろしく>all

  ☆ ティン

       ☆ ティン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>213タン再登場まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

  ☆ ティン

       ☆ ティン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>332タンDI + II まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/


552 :デフォルトの名無しさん:04/11/23 02:52:22
偽者だと言われて本物と主張しては話にならん。
再三の召喚要請にもかかわらず
214 をなかったことにしてこそ 213 タン。
ステレオタイプなかたりでは DI スレは踊れない。

>550
読みやすくて好きだよ。

553 :デフォルトの名無しさん:04/11/23 02:57:46
>>552
漏れも仕事の文書では半角スペース入れてるけどね。
2chでやると目立つからやらない。

554 :デフォルトの名無しさん:04/11/23 02:58:59
偽者ばっかりだな。

俺が本物の>>213=スナフキンだよ。

555 :デフォルトの名無しさん:04/11/23 03:00:03
>>552
>>214 を無かったことにして? 全然思わんが。
214 はすぐ書かずに、空気読んで少し引っ張ってほしかったとは思ったが。

半角空白だけはおまいと話があうな。

556 :デフォルトの名無しさん:04/11/23 03:08:30
>>552
あー、召喚要請って、そんなん忙しくて毎日見れるか。

毎日、いろんな各社のプロジェクトまわって、ダメダメ独自ドメインフレーム
ワーク設計の欠陥を指摘してんだよ。最近、AOP や DI を意識して中途半端な
ものを作ろうとしてるアーキテクトが多い。

557 :デフォルトの名無しさん:04/11/23 03:16:35
そんな使い古されたカタカナ使わないよ。
DI+IIくらいにインパクトある言葉を想像する御仁だ、彼は。

558 :デフォルトの名無しさん:04/11/23 03:22:43
やっぱり偽者だね。

559 :デフォルトの名無しさん:04/11/23 03:31:00
>>557
よく分からんが DI + II がそんなにネタとしてハマったのか?
俺は新しい用語が好きだ。たぶんおまいらもそうなんだろう。

これは Java で言えることかもしれんが、マニアは新しい言葉つけるの好きだな。
ロッドとかファウラーとかね。 マニア受けするんだろな。
俺は会社まわってアーキテクトに説明するときに、極力新しい用語は使わん。
もちろん的確にハマって、かつ、受け入れられやすいものは使うが。

PG がバカじゃなくて、新しい用語使いまくって PG に説明するアーキテクトが
バカなんだ。

560 :デフォルトの名無しさん:04/11/23 03:34:24
>>558
んー、煽ってんの? 俺は仕事でも 2ch でも感情なんかないから。

561 :デフォルトの名無しさん:04/11/23 03:36:55
Netbeansはただのコードジェネレーションだし、Delphiはただのコンポーネントじゃないか?
だいたい定義ファイルから定義を読み込んでオブジェクトを生成するだけなら、はるか昔から
あるだろ。NeXTSTEPなんかどうなるんだよ。
おれは「実行時にもインターフェイスさえ同じなら好きに実装を差し替えられる」ってのはDIの
要件の一つだと思うけど、Netbeansではそれはできんわな。コンパイル前のソースを生成す
るんだから。

まあ、DIだってすんごく新しい発見というわけではなく、発想の転換なんだろうけどね。

562 :デフォルトの名無しさん:04/11/23 03:39:58
>>548
Delphiの場合はsetXxxが呼び出されるから、setter injection
NetBeansをDIっていうなら、新しいtypeだね。

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コンテナだよ。

565 :デフォルトの名無しさん:04/11/23 04:02:29
オブジェクトとってくるときに、そのたびごとに生成するか、一個だけオブジェクト用意しておくか、っていうのも選べる。

566 :デフォルトの名無しさん:04/11/23 04:10:02
>>565はそこまで大それたもんじゃなかった気がする。起動時に変数としてもってるかもってないか、程度。

567 :デフォルトの名無しさん:04/11/23 04:11:15
>>564
じゃー、俺と彼女はどっちが DI コンテナ?

568 :デフォルトの名無しさん:04/11/23 04:12:20
知り合ったきっかけの共通の友達。
つまり合コンの幹事。

569 :デフォルトの名無しさん:04/11/23 04:17:42
>>568
職業から女の子集めてこれるし、そのとき好みの女の子の隣に勝手に座らせてくれるし、お気に入りの娘がいりゃ呼びたい女の子リクエストできるし、まったくDIコンテナだよ。

570 :デフォルトの名無しさん:04/11/23 04:18:56
インジェクションされるためにはPlain Old Japanese Boyじゃだめだ罠

571 :デフォルトの名無しさん:04/11/23 10:22:52
>>560

俺は仕事でも 2ch でも感情なんかないから。
俺は仕事でも 2ch でも感情なんかないから。
俺は仕事でも 2ch でも感情なんかないから。




( ´,_ゝ`)プッ


572 :デフォルトの名無しさん:04/11/23 10:24:08
>>556
アマゾンのネタ書評を書くのに忙しいのでつね


573 :デフォルトの名無しさん:04/11/23 10:25:43
>>549
駄目です。全然お前使えません。

574 :デフォルトの名無しさん:04/11/23 15:57:38
>>555
> 空気読んで少し引っ張ってほしかったとは思ったが。





( ´,_ゝ`)プッ

575 :デフォルトの名無しさん:04/11/23 16:24:00
>>572

> アマゾンのネタ書評を書くのに忙しいのでつね

違うだろアマゾンの書評を元にネタを考えるのが忙しいんだよ

576 :デフォルトの名無しさん:04/11/23 18:43:04
>>535
こいつは真性の構ってクソだったのか。

577 :デフォルトの名無しさん:04/11/23 19:30:21
久しぶりにスレが深夜に進んだので
もしかしてご本人様だったのかもと思ってみることにした。

しかし踊れなかった。

578 :デフォルトの名無しさん:04/11/23 21:57:26
>>576
そうだな。お前みたいに構うバカがいるからな w

579 :デフォルトの名無しさん:04/11/23 22:24:29
>>578
役に立てて嬉しいよ
人生いいこともあるから
挫けずに生きろな

580 :デフォルトの名無しさん:04/11/23 23:13:06
ところで、
.NETのDIコンテナって使ってる人いる?

いたら使い勝手とか信頼性とかその他について感想を聞かせて欲しいんですけど。

581 :デフォルトの名無しさん:04/11/24 01:58:40
このスレはネタスレから普通のスレに戻りました。
3日後くらいにレスつくといいね。>>580

582 :デフォルトの名無しさん:04/11/24 05:24:06
>>580
.NETって、MSとか売り物のコンポーネントで間に合う分には、DIってあまり欲しくならないかも。

583 :デフォルトの名無しさん:04/11/24 07:02:04
「DelphiがDIコンテナ」ということにすると、.NETフレームワーク自体も重量DIコンテナということができる。
で、.NETではその重さを手軽に使えるツールと豊富なコンポーネントでカバーしてるから、その環境で満足できる分には改めて軽量DIコンテナが必要ないんじゃないかと。

584 :デフォルトの名無しさん:04/11/24 10:31:25
そもそもCOMが…以下(ry

585 :デフォルトの名無しさん:04/11/24 13:04:21
燃料投下。
ttp://d.hatena.ne.jp/higayasuo/20041124#1101254759

586 :デフォルトの名無しさん:04/11/24 13:22:58
これが燃料として機能するのは Spring スレにおいてではないか?
あのスレ閑散としてるし、投下してもむしろ歓迎されかねないが。

587 :デフォルトの名無しさん:04/11/24 13:36:59
>>586
貼っといた。
「最新版(OR次バージョン)では改善されとるんじゃボケ」
みたいなSpringマスターの突っ込みがあると面白い。

588 :デフォルトの名無しさん:04/11/24 22:22:59
どうもギター侍ネタが寒くてイライラしてヤなんだが
それはまぁひが氏のせいじゃなくて時代が悪いんだよね。

いろんな意味で Ruby の初期のスタンスと同じ空気を感じる。

ところで method injection とやらは、どんなものなの?

589 :デフォルトの名無しさん:04/11/24 23:13:35
>>588
是非 >>332 に教えてもらってはどうか?
そろそろ DI コンテナくらいは出来上がっているころだろうからな

590 :デフォルトの名無しさん:04/11/24 23:32:38
じゃあ>>588のために呼んでおくか

  ☆ ティン

       ☆ ティン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>213タン再登場まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

  ☆ ティン

       ☆ ティン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  >>332タンDI + II まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/



591 :デフォルトの名無しさん:04/11/24 23:39:34
>>588
> ところで 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

593 :デフォルトの名無しさん:04/11/24 23:48:53

内容は悪くないな。

594 :デフォルトの名無しさん:04/11/24 23:55:01
>591-591
thx.読む。

595 :591:04/11/24 23:56:13
>>592
「んー、煽ってんの? 俺は仕事でも 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
>>594が微妙に>>592をスルーしてるのがワロタ

601 :デフォルトの名無しさん:04/11/25 00:26:13
>599
俺、普通にS2とSpringの差が気になってるんで。
ネタスレではあるけど普通にDIの話がなされるなら
それはそれで勉強になるので助かる。

流しだけどS2のリンク先文書の該当部分と該当サンプルは読んだ。
Spring の文書は英語なんで午前中にマターリと読んでみる。

Spring で大部分の処理の前に共通処理挟もうとして
IntroductionAdivce と BeforeAdvice で格闘した挙句
思うようにいかなかったことがあったので
正直、かなり興味を抱いている。

602 :デフォルトの名無しさん:04/12/02 12:17:32
>>521
今さらなんだけど、クラスメソッドをオーバライドできるから信頼性無いって
的外れな批判だよね。一文字でも間違えたら機能しなくなるのがプログラ
ミングなわけで、それは何を使おうが同じ。

603 :デフォルトの名無しさん:04/12/02 12:20:41
>>602
それはすごく的外れな批判に思えるが。
「信頼できない」と「信頼性がない」は意味が違うぞ。

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厨の人、呼ばれてるよ。

606 :デフォルトの名無しさん:04/12/15 01:52:10
おおDIスレよ、しんでしまうとはなさけない

607 :デフォルトの名無しさん:04/12/27 16:05:32
>>603
>>604
言ってることがわからん

608 :デフォルトの名無しさん:05/02/18 23:08:01
バカが征くでDI是非議論出てるね。

609 :デフォルトの名無しさん:05/03/06 11:58:40
>>608
ググってみたけど、みつからなかったので
詳細希望。

167 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)