04/11/07 20:40:01
Java製DIコンテナ
Spring Framework
URLﾘﾝｸ(www.springframework.org)
PicoContainer
URLﾘﾝｸ(www.picocontainer.org)
HiveMind
URLﾘﾝｸ(jakarta.apache.org)
Seasar2
URLﾘﾝｸ(www.seasar.org)
3:デフォルトの名無しさん
04/11/07 20:46:16
RubyでDIという記事
URLﾘﾝｸ(jp.rubyist.net)
上記の記事に出てないRuby製DIコンテナ
URLﾘﾝｸ(homepage1.nifty.com)
4:デフォルトの名無しさん
04/11/07 20:48:53
関連ありそうなスレ
Java Spring Frameworkを語るスレ
ｽﾚﾘﾝｸ(tech板)
国産DIコンテナSeaserとくーす その2
ｽﾚﾘﾝｸ(tech板)
5:デフォルトの名無しさん
04/11/07 21:03:45
.NET版DIコンテナ
Spring.NET
URLﾘﾝｸ(www.springframework.net)
Dosanko
URLﾘﾝｸ(cvs.sourceforge.jp)
Kodama
URLﾘﾝｸ(sourceforge.jp)
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 つかったことないけど。
URLﾘﾝｸ(rubyforge.org)
10:デフォルトの名無しさん
04/11/08 16:59:38
Pythonのものはないかと探して見つけたもの
PyContainer
URLﾘﾝｸ(www.pycontainer.glt.pl)
11:デフォルトの名無しさん
04/11/08 17:15:14
Dependency Injection in Ruby
URLﾘﾝｸ(onestepback.org)
12:デフォルトの名無しさん
04/11/08 17:16:07
色々とあるもんだなー。
Perlはないのかな？
13:デフォルトの名無しさん
04/11/08 18:51:20
IOC - A lightweight IOC (Inversion of Control) framework
URLﾘﾝｸ(search.cpan.org)
14:デフォルトの名無しさん
04/11/08 19:03:11
おーPerlだ。㌧ｸｽ
スクリプト系でも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は
ｽﾚﾘﾝｸ(tech板)
で語ることになってるのかと。
>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
ＰＯＪＯって何だ？
ただの普通のクラスと何が違うんだ？
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出ました。
URLﾘﾝｸ(www.picocontainer.org)
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はスレ違いじゃないと思います。
URLﾘﾝｸ(www.kakutani.com)
>今のところ、本記事ではアスペクト指向については考慮していないが、今後追加するなり、
>他の記事を書くなりして、是非とも取り組んでみたいと思っている。
54:デフォルトの名無しさん
04/11/10 00:33:54
どーでもいいが、太田君もかくたに君(お子さん誕生おめでとう)も
トリップつけなさい。
URLﾘﾝｸ(info.2ch.net)
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コンテナいれなくても享受できるでしょ。
享受できてないじゃんｗ
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は諸刃の剣だそうだ
URLﾘﾝｸ(d.hatena.ne.jp)
72:デフォルトの名無しさん
04/11/10 02:21:16
テストがしにくいってことね。なるほど。
73:デフォルトの名無しさん
04/11/10 02:22:17
POJDってなに？
74:デフォルトの名無しさん
04/11/10 02:27:45
>>73
URLﾘﾝｸ(forum.javaeye.com)
を読め。
じゃなくて>>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
中国語サイトのは、アノテーションのない普通の宣言ってことか。
みんなみんな、プレインオールドっていいたいだけ違うんかと。
そんなにプレインオールド好きなら、頭髪までプレインオールドになってしまえｗ
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なんてのもあるぞ。
URLﾘﾝｸ(blog.goo.ne.jp)
> "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自体のブラッシュアップ、ドキュメントの整備、英語圏へのプロモーションが進めば大ブレイクするかもね。
今は中の人が盛り上がってるだけだけど、このままのモチベーションで開発が続けば１年半後くらいがみものかも。
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ブラウザでアクセスして、２ちゃんブラウザのログを更新したり
閲覧したりしたいだけなんだけど・・・・・・・
こういう用途でも使えるものなんでしょうか？＞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はまだまだこれからの段階だと思う。
URLﾘﾝｸ(ruby.jamisbuck.org)
あと、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
彡､ |∪| | Ｊ > 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－出先間の暗号化とか、２ちゃんブラウザに近い機能の
追加(透明あぼ～んとかログ検索とか)を考えると、このままCGIとして書いていっていいのかな？と
もっと上手い方法があるんじゃないかと巡回してたら、ここをみつけたという次第です。
>>148
自宅PCではOpenJaneDoe(２ちゃんブラウザ)を使ってるんですが、これを会社に持ち込む事はで
きないんで、会社ではWEBブラウザを使って２ちゃんを読んでます。
でも、これだと会社で読んだ内容が２ちゃんブラウザのログには反映されず、非常に不便です。
そこで、これをどうにかできないかな？というのが出発点なんで、ログは２ちゃんブラウザのログそ
のもの(２ちゃんブラウザから読めないと意味がないので)をガリガリ更新する予定です。
とりあえず、この様な用途にも使う事はできる、そしてメリットも(大小の違いはある様だけれど)ある
という感触を得たんで頑張ってみます。
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
禁止されてるのはソフトウェアのインストールで、２ちゃんを読む事じゃないんで
その点は大丈夫です。
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を導入しなきゃならないのか
コンポーネント化するってことは取り外しが簡単だからだろ？
それをしたなくなきゃプログラミング言語の機能を使って普通にＯＯＰするのだ。
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
>別の仕組み
「仕組み」とは何なのか
モジュール化、依存性を少なくして簡潔なシステムにするための仕組みであるなら、
それは普通にＯＯＰするのと何が違うのか。
そこがどうにも弱いんだな。
ソフトウェアをパーツ化して取り外し可能にすることが目的、そういう仕組みが欲しいなら、
アプリケーション側でその拡張方法を定義するのが礼儀だと思う。
だからそういう機能がお好みなら、そのときはEclipseを見習おう。
189:デフォルトの名無しさん
04/11/13 14:11:07
なんでプラグインアーキテクチャを持ち出してDIコンテナに反論
した気になってるのかね。支離滅裂。
むしろDIコンテナはプラグインアーキテクチャを推進するものだと
思うんだが。
とりあえず↓でも読んどけ。
URLﾘﾝｸ(blog.goo.ne.jp)
URLﾘﾝｸ(blog.goo.ne.jp)
> 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は中途半端でＯＯＰやるのと大差ないってことを言いたかった。
その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の策定メンバーとあるが、名前や肩書きを鵜呑みにするのは危険であるという
> 証明になるかもしれない。
> これからプロセスや手法及びプロジェクト管理を学ぼうと思う人は、
> あくまで１つの本として参考にすることが必要だ。
ほぼそのまんまだね。
悲惨な風景だ。
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なんか、自分では使わないｗ。
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
うーん。
URLﾘﾝｸ(xlegend.dip.jp)
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
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
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原理主義者ですから（ｗ
まあ、本気でむやみやたらに使ったらあかんけど。それは当然。
ある程度アーキテクチャはきめとかないとな。くーすとかでいいと思うけど。
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依存せずピュアなＯＯプログラミングである。
これで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みたいなもんだし。