【Java】DIコンテナって本当に便利か？

1 ：デフォルトの名無しさん：2008/08/20(水) 23:23:26 .net

インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどｗ

2 ：デフォルトの名無しさん：2008/08/20(水) 23:42:55 .net

DIってなに使ってるんだよｗ
いまどきXML地獄なんてどのFWにも無いぞ

3 ：デフォルトの名無しさん：2008/08/22(金) 00:40:41 .net

使わずに組んだほうがラク

4 ：デフォルトの名無しさん：2008/08/22(金) 01:57:47 .net

>>2
Spring2.5からはアノテーションインジェックションが
使えるようになったからXML地獄じゃなくなったよ。

5 ：デフォルトの名無しさん：2008/08/22(金) 05:09:45 .net

優柔不断すぎるプロジェクトが多い気がする。
インタフェース作っても、実装クラス一つしかなかったり。
結局、特定の組み合わせでしか動かなかったり。

6 ：デフォルトの名無しさん：2008/08/22(金) 10:44:21 .net

実装クラスひとつはふつうと言えばふつう。

7 ：デフォルトの名無しさん：2008/08/23(土) 15:43:06 .net

>>1
インターフェース書くのが嫌ってことなら、そっちの方が大問題だね
まあ、そもそも DI するのにインターフェース書かなきゃいけないってことは無い訳だが

脱線するが、
interface と abstract class は全く違うものなんだけど、分かってるつもりでいて、実は分かってないやつは非常に多い
>>1 もそんなとこだろう
abstract class は拘束、interface は主体的な宣言とか言ったらヒントになるか…
共通点は勿論あるんだが、設計においては、これは全く違う意味を持ってくる
それが分からんと、 interface の価値が見出せなくなったりするようだ
なんと言うか、interface を拘束の意味でしか理解していないとでも言うか…

それから、実装クラスが一つしかないと、端折って直接実装を呼びたくなったりするらしいが、
その点 DI は interface の旨味を再確認させてくれる。

8 ：デフォルトの名無しさん：2008/08/23(土) 23:57:34 .net

>>7
お前が interface と abstract class の違いをよく理解していないことだけはわかった

9 ：デフォルトの名無しさん：2008/08/24(日) 02:25:07 .net

↑
どうやら何かを判ったつもりになってひとりで納得しているの図

10 ：デフォルトの名無しさん：2008/08/24(日) 10:08:27 .net

インターフェースは不要っしょ
俺ぁ余計なクラス、設定が増えまくる事自体が問題だと思う

11 ：デフォルトの名無しさん：2008/08/24(日) 10:39:57 .net

springスレも落ちたし、guiceスレも時間の問題だな。

12 ：デフォルトの名無しさん：2008/08/24(日) 12:41:17 .net

具体的な個々の処理が存在するならインターフェースは書くべきだよ
実装しかないと、常に密結合状態じゃん
サービスの実装に
new InitialContext();
とか直接書いたりしないでしょ？それと同じ

後から何か処理を加えたいと思った場合、インターフェースがあれば最初の実装に手を加えなくても済むケースがあるでしょ？
実装しかないと、そいつにドンドン追加する羽目になりがち
下に何か加えることは出来るけど、上に被せられないし
それに、インターフェース守れば良いんだから、却って自由に書けると思うんだが

ただ DI に関して、設定が増えまくるのは確かに苦痛
そこでアノテーション
でもこれって、テストとリリースでどうやって分けんのかとか、ちょっと混乱しそうな気もする
ルール付け徹底すりゃいい話なんだろうけど

13 ：デフォルトの名無しさん：2008/08/24(日) 12:58:04 .net

ぐだぐだなところは、インタフェースを書き換えるから意味ないって。

14 ：デフォルトの名無しさん：2008/08/24(日) 13:05:54 .net

XMLが地獄だと思わないんだが。
クラス図書くより全然楽だし。

アノテーションの方が地獄っぽくないか？
組み合わせ変更するのに、なんでコンパイル必要なんだよ。
何のために interface 書いたのか分からん。

もっとも DI 嫌ってる人は、そんな瑣末なことなんてどうでもいいんだよ。
本当は疎結合の良さが分かってないだけ。
自分がなんで DI 好きになれないのか、それすら分かってない。
DI なんてどうでもいいから、疎結合に慣れろ。
慣れた結果、密結合で十分かつ適当な場合と
そうではない場合が分けられるようになればそれでいい。

15 ：デフォルトの名無しさん：2008/08/24(日) 13:18:46 .net

疎結合を保つためにDIは必要ないし、
DI使ってても密結合になってる例はたくさんあるし。

16 ：デフォルトの名無しさん：2008/08/24(日) 13:36:21 .net

>>15
確かに

結局は分かってるか分かってないかに落ち着いてしまうのかな
シングルトン強制ギプスとか思っても、分かってりゃ必要に合わせてシングルトンで書くわけだし

ただAOPは捨てがたいな
AOPを捨てれないとDIも捨てられないw

17 ：デフォルトの名無しさん：2008/08/24(日) 13:48:19 .net

>>12
>>10を見て目を疑ったんだが、結合度とか凝集度って未だに普及してない概念なのかねぇ。
まぁ、インターフェース大増殖とか設定ファイル大増殖とかアノテーションだらけってのは見てて気分のいいもんではない、というのは確かなんだが。

そこらへん、Scalaだとだいぶ緩和されそうだけど、普及するかなぁ。

interface Hige { String execute(); }
void hoge(Hige hige) { println(hige.execute()); }
が、
def hoge(hige: {def execute: String}) = println(hige.execute)
(higeがStringを返すexecuteメソッドを持っていれば何でもいい)
となるので、リスナーみたいなインターフェースはまとめて削減できそう。

18 ：16：2008/08/24(日) 13:49:56 .net

いや、やっぱ必要ないファクトリ書くのも プロパティセットするコード書くのも面倒くさいからDI捨てらんないわ

19 ：デフォルトの名無しさん：2008/08/24(日) 15:00:05 .net

>>15
確かに。でもそれを言い始めたらキリがないのでは。

20 ：デフォルトの名無しさん：2008/08/24(日) 16:40:09 .net

>>11
Seasarのことも思い出してください＞＜

21 ：デフォルトの名無しさん：2008/08/24(日) 18:38:55 .net

疎結合？ソースが見にくいんですけど

22 ：デフォルトの名無しさん：2008/08/24(日) 19:30:53 .net

ネタなのかマジなのか微妙なところ突いてくるな

23 ：デフォルトの名無しさん：2008/08/24(日) 19:42:31 .net

成果物としてのコードが特定のフレームワークに強く依存するのが怖い。
「それがどうした、知らないお前が勉強不足」と開き直れるほど枯れた技術ではないし。

開発現場が全速力で短距離を走り抜けるための技術というか…
と感じながらも全速力で走らメシが食えないから使うんだけどな。

24 ：デフォルトの名無しさん：2008/08/24(日) 20:46:26 .net

特定のフレームワークに ”強く依存” ってのが気になるね。
いったいどんなコード書いてんだ？
ぶっちゃけ特定の「なんちゃら」への依存が弱まることはあっても、強くなるケースっていまいち想定できないな。

モジュール間の結合度を弱めてテストをし易くするのが利点と思いきや、”強く依存” とはこれ如何に？
もしそれでモデルにフレームワークへの依存が入り込んでるんなら、実装に問題があると思ったほうが良いのでは？

内製だったらモデルとフレームワークの強い依存関係が許される、なんてオチじゃないよね？

あと枯れてる枯れてないって、じゃ generics や annotation は枯れてないから使わねーと？

25 ：デフォルトの名無しさん：2008/08/24(日) 21:17:10 .net

＞ 開発現場が全速力で短距離を走り抜けるための技術というか…
それは RoR とかポトペタで画面作れますとか、
O/R mapper でウハウハだよもんとか、
そう言うレベルの話では。

DIコンテナが提供してくれるのは糊だけ。
既存のポトペタとくっつけたきゃそうするし、
フルスクラッチの俺様フレームワークとくっつけても良いし。

疎結合の利点を最大で活かすために糊に徹してるのが DI コンテナ。

26 ：デフォルトの名無しさん：2008/08/25(月) 01:06:47 .net

下手のコードを閉じ込める
自分でファクトリ書かなくていい
テストコードが嫌でも書きやすくなる

下２つが特に有難い
短期開発でメンバのスキルが低いときは逆にDI使わないと品質は保てない
ファクトリ書いてる時間を他の作業に回せるし

27 ：デフォルトの名無しさん：2008/08/25(月) 08:03:17 .net

ファクトリとかわざわざつかわねーし。
余裕あるんだな

28 ：デフォルトの名無しさん：2008/08/25(月) 21:35:10 .net

密結合を気にしない >>27 の一言でした



ファクトリ書かなくても良いってのが DI の利点の一つなわけだが、
そもそもなんでファクトリ書くべきなのか分からんようでは、その利点も分からん訳だ。
溝は深いね〜

29 ：デフォルトの名無しさん：2008/08/25(月) 22:17:32 .net

>>28
ファクトリとかソースが見にくくなるだけ。

30 ：デフォルトの名無しさん：2008/08/25(月) 22:59:07 .net

大抵のOSSのフレームワークやミドルウェア製品の
提供するAPIには必ずファクトリが含まれるわけだが

31 ：デフォルトの名無しさん：2008/08/26(火) 01:31:50 .net

「DIのいいところ教えてください。」
って聞きたいのに、強がって
「DIコンテナって便利か？」
って聞いてるわけか。

32 ：デフォルトの名無しさん：2008/08/26(火) 03:55:28 .net

DIコンテナが分からないんじゃなくて
それが登場した背景の考え方が分かってない。
だからいつまで経っても話がかみ合わない。

モジュールの凝集度高めて疎結合目指すなんてのは
それこそ20年以上前から言われてることなのに
理解して実践してるのはごく少数なのが現実。

33 ：デフォルトの名無しさん：2008/08/26(火) 21:52:13 .net

だよもんとか（某板の外では）数年ぶりに聞いた

34 ：デフォルトの名無しさん：2008/08/26(火) 22:29:25 .net

>>32
全くもってそうらしいね

今途中から突っ込まれて行ってるプロジェクトは結構グダグダで火を吹いてるんだが、
ソースを見てビックリ呆れること多数。
所謂大規模開発で、結構な数の業者が入っていて、開発人員も多いんだけどね。
規模なんてソースの品質には関係ないらしいよ。

勿論 DI なんて使ってないんだが、更に残念な事に自分等でファクトリを書いてない。
おまけにベンダ製のツールが吐いたファクトリクラスがあるんだが、
そのファクトリを使うとき、getFactory() ってなスタティックメソッドがあるにも関わらず

毎 回 そ の フ ァ ク ト リ を new し て る 。 orz

てめぇー、インスタンスの取得方法を知らなくてもいいようにファクトリがあんのに、
そのファクトリを毎回 new してどーすんのよ！？ってな感じ orz orz
そんなコードがゴロゴロ

こんなんが某超大手元受の金融機関向けシステム開発だってんだから
残念な業界ですねって言いたくなるよ。

その残念な質の一画を自分の会社が占めている事実が更に残念。
早く辞めてぇ

（ﾏな内容でｽﾏｿ）

35 ：34：2008/08/26(火) 22:38:15 .net

誤：インスタンスの取得方法を
正：インスタンスの生成方法を

36 ：デフォルトの名無しさん：2008/08/26(火) 23:19:54 .net

>>34
お前も残念な会社の社員なんだろ？ｗｗｗ

37 ：デフォルトの名無しさん：2008/08/26(火) 23:59:18 .net

>>34
気持はわかるけど、ここマ板じゃないから。

38 ：デフォルトの名無しさん：2008/08/27(水) 00:18:53 .net

>>34
そんなつまらん会社辞めろ。
お前も残念な質の会社の一角を占めてるんだ。
辞める気がないならつまんない愚痴言わず、
会社、業界を良くする努力しろ。

39 ：デフォルトの名無しさん：2008/08/27(水) 00:24:48 .net

Springスレが落ちたってのがDIはゴミってのを物語ってないか？

40 ：デフォルトの名無しさん：2008/08/27(水) 00:28:08 .net

>>34
>ベンダ製のツール
そのベンダ製のツールの使用ガイドとかはちゃんとアナウンスされてるんだろうな？
「用意しました。後勝手に使ってね」ってのはマネジメントしてねぇ。

>規模なんてソースの品質には関係ないらしいよ
基本的には「ある」と思ってる
規模が大きくなればなるほど全体的なソースの品質は低下する

まあ上記のような問題を解決するための手段として
AOPやらDIみたいなのが出てきたのだけど
結局AOPやDIで何がやりたいかの理解が
実装者個人個人にまかされてしまってるのが問題な希ガス。
実装ガイドくらいではそこまでの統一はとりづらい。
で堂々巡りな状況に陥ってるような。

41 ：デフォルトの名無しさん：2008/08/27(水) 00:36:09 .net

DIに興味ない人がたくさんてことを物語ってるとは思う。
興味ある人も取り立てて語る事なかったし。
気になって試して、気に入ったら使う。
ドキュメントが詳細だから疑問に持つこともない。

> 結局AOPやDIで何がやりたいかの理解が
テストとか便利にできるよ程度でいいんだけどね。
テスト極めようと思ってれば、気がつけば疎結合になってるだろうし、
適切なテストがきちんと通るなら品質には問題は出ない。
でも背景知らずにツールだけ知って、
使い方分からない、良さ分からないとか言ってる人が多数なわけで。
で、説明するのも面倒だから放置して
気が付くと自分しか使ってないとか、そんな感じ。

42 ：デフォルトの名無しさん：2008/08/27(水) 01:11:47 .net

DIに限らないけど「技術に興味が無い人が使うツール」というところまで持っていかないと広まらないよ。

43 ：34：2008/08/27(水) 02:04:26 .net

>>36
笑いごっちゃーないですわ…

>>37
重々承知です。ご勘弁を

>>38
辞めるにしろ、対策するにしろ、具体策を考えてるところです。
ただ、このプロジェクトは今更どうこう出来る状態じゃないので、今ある部分は最後までそのままだと思われ。

>>40
そのベンダのツールは勿論マニュアル付きです。
つか、読まなきゃ使えないはず…
まあファクトリを理解せずに毎回 new しちゃってる、ってことなんだと思いますよ…

>>規模なんてソースの品質には関係ないらしいよ
>基本的には「ある」と思ってる
>規模が大きくなればなるほど全体的なソースの品質は低下する
…
次転職するときは面接で何を聞かなきゃいけないか良く分かった、ってことは最近痛感している。

44 ：デフォルトの名無しさん：2008/08/27(水) 02:27:13 .net

>>42
その事を理解してないプロジェクトの多いこと多いこと
チーム内で最低のレベルにいるメンバーにも
問題なく使わせられるようにしないといけないのになぁ

>>43
>そのベンダのツールは勿論マニュアル付きです
そのマニュアルの内容にもよるけど
上で語っているようなレベルのもの？
マニュアルを自分が理解できたから
他人も理解するべきってのは違うぞ。

ちとマ的とゆうかPM的になっちゃたな・・・

45 ：デフォルトの名無しさん：2008/08/27(水) 21:26:50 .net

>>39
ああ、落ちてる。せっかく立てたのに・・・。

46 ：デフォルトの名無しさん：2008/08/27(水) 22:58:15 .net

蜜結合でも機能ごとに分かれてた方が
結局後で分かりやすいんだよな

47 ：デフォルトの名無しさん：2008/08/28(木) 00:32:17 .net

Springスレ立てないの？
SpringMVC語ってくれる人あそこくらいだったんでよく見に行ってたんだが

48 ：デフォルトの名無しさん：2008/08/28(木) 01:32:59 .net

>>47
もはやS2の方が完全上位なんじゃね？

49 ：デフォルトの名無しさん：2008/08/28(木) 06:20:19 .net

学べば学ぶほど悲しくなる
無知こそ最強って感じだよorz

50 ：デフォルトの名無しさん：2008/08/28(木) 06:42:56 .net

>>24
利用するDIコンテナに強く依存

51 ：デフォルトの名無しさん：2008/08/28(木) 08:15:02 .net

>>49
相当流行ってからじゃないと勉強もイミないかも・・・

52 ：デフォルトの名無しさん：2008/08/28(木) 19:54:11 .net

人は流れに乗ればいい

53 ：デフォルトの名無しさん：2008/08/28(木) 22:50:00 .net

jspを書かなくていいとか、
せっかく覚えたのに。。。

54 ：デフォルトの名無しさん：2008/08/29(金) 01:48:31 .net

>>47
俺もSpringMVCが好きなんだけど、
じゃぁ毎日語ることがあるのかと言われると、そんなものはない。
Spring スレは3年くらいスレが保守されてたが、
1.2.x が安定したころから、特に話題もなくなった。

55 ：デフォルトの名無しさん：2008/08/30(土) 01:50:09 .net

>>54
SpringMVC悪くないんだけど、
あのControllerの深い継承具合はどうかと。
なんだよ、あのテンプレートメソッドの嵐。
せっかくDIコンテナなんだから、
ブリッジパターンとかもーちょっとすっきりできなかったのかよ。

56 ：デフォルトの名無しさん：2008/08/30(土) 19:32:22 .net

引数戻り値に平気でコレクションの実装クラス使う連中にDIが理解できるはずがない

57 ：デフォルトの名無しさん：2008/08/31(日) 14:28:16 .net

Springはゴミですかそーですか

58 ：デフォルトの名無しさん：2008/08/31(日) 16:20:22 .net

>>56
気持ちはわかる。なにも考えずにそういう事する奴は確かにいる。
メソッド全部publicとかと同レベル。

でもサービスクラスを書いてるときに、要素の入れ替えがあるから
LinkedListに使ってるよーとか、こいつは要素追加するとソートされるよ
とかを利用者に伝えるために戻り値の型を実装クラスで書いた方が
いいんじゃないかと思うこともある。

59 ：デフォルトの名無しさん：2008/08/31(日) 16:37:08 .net

ファクトリを書かなくていいのにメリットがあるのは同意だけど、
起動時遅いとかメモリ喰うとかのデメリットもあるよね。

インジェクションするクラスを設定で簡単に切り替えられるのが
一番の目的だったと思うんだけど、本番環境にデプロイするのは
1パターンだけであまりメリットが感じられない。テスト用なら
こんな高機能いらなくて設定ファイルでObjectIdと実クラス名
の紐付けできるファクトリがあればいいだけだし。

似たようなシステムをちょこっとクラス入れ替えていくつも
リリースするような時には確かに有効。ソースツリーも
一つで管理できるし。でもそんなプロジェクト一回しか経験したこと無い。
Web側(jsp)は全然違うから別ソースだし。似たようなプロジェクトの時も
反省点を踏まえて作り直したりするし。

ファクトリのコード削減とAOPによるログ出力くらいなんでしょうか。

60 ：デフォルトの名無しさん：2008/08/31(日) 17:09:36 .net

>>50のレスが秀逸すぎるわ

61 ：デフォルトの名無しさん：2008/08/31(日) 20:56:39 .net

>>59
起動遅いのはあまり問題にならんと言うか、
モジュールレベルで完璧に作れてれば
あとは組み合わせるだけなんで、別にどうでも・・
クライアントアプリなら問題にはなるけど
あまりそういう分野で使われてないだろうし。
逆に S2みたいな Hot-Deploy を売りにするセンスが俺には理解できない。
結局つながないと開発できないのかよ、それって DI かよって。

メモリってそんなに食う？これは実感したことないや。

日頃からテストがきちんとできる仕組み用意して
それを実践してるなら、別に DI コンテナ使う必要はないよ。
俺は自分で用意するの面倒だし、
自分のコードなんて全然信用してないから
十分にテストされたものを使うだけの話。

62 ：デフォルトの名無しさん：2008/08/31(日) 21:09:44 .net

>>59
>ファクトリのコード削減とAOPによるログ出力くらいなんでしょうか。

それって大きいと思うけど。
それから宣言的トランザクションは使わないの？

今のプロジェクトで DI，AOP 使えれば良いのに、ってかなり思うよ。
ログ出力のコード分量もかなりなもんだし、
トランザクション制御の為に、サービスクラスに abstract execute() みたいなの強制してて超汚ねーし、
必要ない new をやたらと書きまくるやつはいるし（これは別問題か…）

慣れてきてから、DI 使わないプロジェクトで同じ事やろうとしてごらん。
汚いの面倒くさいの… 馬鹿らしくなるよ。

63 ：デフォルトの名無しさん：2008/08/31(日) 23:50:23 .net

うちが使ってるフレームワークもどきみたいなのでは
ServiceとDaoは自動生成でSinleton生成コード吐くし、
bean idとクラス名結びつけるファクトリは枯れたxml読み込み
クラスを利用して1クラスで完結してるんですわ。

private AnyService anyService;
と宣言してアクセッサ用意するより
private AnyService anyService = AnyService.getInstance();
で設定したクラスをインスタンス化できた方が若干楽だし
publicなget/setAnyService()があるとそれを利用側プログラムで
呼び出していいと思われても嫌だし。springでセットしたserviceが
入ってるからgetしても問題は無いんだけど。

そうするとspringしらない技術者がヘルプで入ってきたときに
DIっていうのはねっていうところから説明するより全然
教育コストも低いんですよ。

起動が遅くなるのはEclipseでデバッグ時にちょっとした修正で
いちいち時間かかって精神衛生上よくないっていうだけで根本的な
問題ではないけど。

64 ：デフォルトの名無しさん：2008/08/31(日) 23:57:13 .net

AOPによるログ出力はブレークポイントつけてステップ実行が当たり前に
なった今存在意義が薄いし、ソースの骨格が自動生成でこみいったとこだけ
手で実装なので、むしろうまく行っているところはトレースログとりたくないし。

トランザクションは昔から使ってるDBコネクションプールがThreadLocalで
好きなとこでstart()/commit()させてくれるのでこれをService内に
明示的に書いてある方が問題があったときにどこでcommit()/rollback()
されてるかわかりやすいと思うんだけど、もう俺の考えが古いのかなあ。
デバッグ担当する人間が全員springのxmlの仕様を知っていないと
「どこでコミットされているかすぐに把握できない」のはめんどくない？
ずっと少数精鋭主義のプロジェクトでやっていけるなら別だけど

65 ：デフォルトの名無しさん：2008/09/01(月) 00:04:32 .net

自己レスだけど
>bean idとクラス名結びつけるファクトリは枯れたxml読み込み
>クラスを利用して1クラスで完結してるんですわ。

結局DIしてるわけだからこのスレとは違っちゃうか

66 ：デフォルトの名無しさん：2008/09/01(月) 00:29:30 .net

>>63
それでうまくプロジェクトが回ってるならそれでいいと思う。

教育コストはDIがどうこうよりも、
テストファーストがどうこう、
ステートレスがなんやら、
疎結合だとあれこれ・・の説明に苦心しない？
「ふーん、面倒なんですね」の一言で片づけられた日には悲しくなったよ。
で、今日もまたテストケース書かないコードをコミットしやがる・・・

67 ：デフォルトの名無しさん：2008/09/01(月) 00:40:51 .net

＞AOPによるログ出力
俺もこれは例示のための例示にしか過ぎないと思う。
通常、AOPはメソッド境界で作用するけど
このレベルで横断的にログ取りたいものなんて殆どないし。
メソッド内部の動作で不審な動きがないかチェックしたいとは思うけど、
取得したい情報なんて処理ごとに異なるし、そもそもAOPでは制御不能。
AOP使う話であれば、トランザクションと認証回りが適切な例だと思う。

＞少数精鋭主義のプロジェクトでやっていけるなら
別に精鋭じゃなくても設定くらい読めるから。
トランザクションが何か分かってるなら、書き方・読み方教えて終了。
いろんな場所でトランザクションの開始・終了が出来れば
きっと効率が良いのだろうけど、少数精鋭ならともかく
現実の開発でそれやるとロクなことにならんですよ。
好き勝手に開始して放置して、もうグダグダ。
多分、今まで少数精鋭でやってきて、そういう事態に陥らなかったんだと思う。

68 ：デフォルトの名無しさん：2008/09/01(月) 01:09:29 .net

正直テストファーストはどうかなあと思ってる。
昔みたいにウォーターフォールで仕様変更したら別料金とりますよっていうなら
いいけど、仕様が変わる度にテストケースも保守していくのは
常に詳細設計ドキュメントを保守し続ける位面倒。んで最後にまとめて
作ろうと思って納期迫ってカバレッジ低いテストケース書いてるから
それも駄目なんだけどね。

AOPは結局ログくらいしか思いつかなかったんだよね。Webばっかりだから
認証はそれこそBaseActionかInterceptor(struts2)で入り口でやってあげれば
済むし。

springだけを教えてるなら設定くらいすぐ覚えるだろうけど、
プロジェクト参加当初は業務もプログラムも教えることいっぱいだし、
問題があったときにデバッガで追ってればすぐわかる方がいいと思うけどなあ。
トランザクションの開始・終了はServiceクラス内の同一メソッドでとルールで
縛ってるので、というかdaoも自動生成で複数テーブルに対するトランザクション
管理をしたいと思ったらこれしか書きようが無いんだ
try{
　DBManager.startTransaction();
　dao1.insert(obj1);
　dao2.insert(obj2);
　DBManager.commit();
}catch(...){
DBManager.rollback();
}
daoが自動生成なせいで、複雑なDBも処理もdaoに書いて
serviceから呼び出す、daoでトランザクション管理しない
っていうのが徹底されてるのが効いてるのかな。

69 ：デフォルトの名無しさん：2008/09/01(月) 09:45:29 .net

横道にそれるけど、なんか同情したのでいきなりレス。

>>66
Unitテストが義務化されていないからだな。
これはかなり大変。「テストを楽にする」は
意外に動機として大きいから。

仕様書が明確に落ちて無いと末端の子に
テストファーストは難しいけど、デグレードを
未然に防ぐ為のテストセカンド（造語）くらいから
やるのはどうだろう。
自分のコードにバグが無いことの証明だから
ホントはやってて当たり前なんだけど。

70 ：69：2008/09/01(月) 09:47:40 .net

続き。

疎結合は再利用性。
「ほら、別のプロジェクトでも簡単に使いまわし
できただろ？」
って言える例を作ってやれればどうにか。

ようは教える側がメリットを示すのが良いと思う
（デグレードが減る。使いまわしが楽など）。

ただし、教えられる側が
・時間内手を動かしてさえいれば金が貰える
・バグで人に迷惑をかけてもかまわない
そんな思想だと哲学から変えないとダメ。

71 ：デフォルトの名無しさん：2008/09/01(月) 10:06:33 .net

いろいろ経験して
「newを直に書きたくない」
という思想にいたる事が出来れば
DIコンテナのメリットが説明しやすい。

結局ある程度抽象化の概念に
同意していない人には無用の長物かも。

72 ：デフォルトの名無しさん：2008/09/02(火) 00:22:13 .net

>>70
疎結合でサービスクラスやアクションを使いまわしたりしないし
その説明では納得できん。ただ共通関数を増やしていくだけでいいだろうに

73 ：デフォルトの名無しさん：2008/09/02(火) 00:29:44 .net

個人的なDIの欠点はデバッガでなければソースを追えないって点だな。
interfaceベースで作ってたら、当たり前の現象なんだが、IDEのパワーをないがしろにしてる。
それでもDI自体は分業に向いてると思うし、俺は好きだ。

74 ：デフォルトの名無しさん：2008/09/02(火) 01:30:45 .net

原理主義者はDIとかアスペクト好きなんだよ
もうほんと、それだけ

問題は、Javaがそもそも原理主義的なコーディングに不向きなことと
現実世界(特にビジネスまわり)がちっとも原理主義に根差してないことが原因で、
DIから得られる現実的なメリットが、ほとんど実感できないくらい
小さくなってしまっていること

75 ：デフォルトの名無しさん：2008/09/02(火) 01:59:43 .net

現実世界も整理すればそれなりにスッキリしてるんだが
現実を現実のまま処理しようとして
ステートフルな世界に走ろうとして失敗してる人が多数居る。

ところで原理主義って何？

76 ：デフォルトの名無しさん：2008/09/02(火) 03:03:42 .net

ジャヴァはブルーカラーからのラングエジじゃなかったか？

77 ：デフォルトの名無しさん：2008/09/02(火) 03:40:53 .net

DIはログとかトランザクションの管理に便利。
共有リソースの管理に便利。

78 ：デフォルトの名無しさん：2008/09/02(火) 04:39:25 .net

なんと言う後付けユーティリティ

79 ：デフォルトの名無しさん：2008/09/02(火) 04:53:57 .net

なにか問題でも？
逆に、共有リソースの管理がスタティック変数でまかなえる場合や、ログ・トランザクションをそこまで徹底しない場合は、DIコンテナ不要。

80 ：デフォルトの名無しさん：2008/09/02(火) 04:54:48 .net

ログ・トランザクションは徹底というか、単純なルールが適用できる場合にDIが有効か。

81 ：69：2008/09/02(火) 09:21:14 .net

>>72
ごめんね。俺が思ってた疎結合の話に
君が思うようなサービスクラスやアクションを
含んでいなかった。
そしてDIにたどり着く前の段階の前提なんだ。

>>66の言う教育の時に自分がどう行動するかを
書いてみた。
サービスとかアクションならモックを引き合いに
出すかなぁ。モックの意味を理解する人ならわかって
くれるかもと思う。

>>72を説き伏せようとは思っていないから
けんか腰にならないでね。

82 ：デフォルトの名無しさん：2008/09/02(火) 09:30:42 .net

>>73
同じ事がインターフェースを
たくさん使ったソースコード（非DI）を
新人さんが読んでいる時に起こっていた。

あるメソッドが呼ばれているはずなんだけど
呼び元にEclipseで飛んでもインターフェース
にしか辿り着けないという形。

力技でもどうにかできるようにしたければ
インターフェース使わずに書くのも良いと思う。
どこで切るのかの問題かもしれないけど。

83 ：デフォルトの名無しさん：2008/09/02(火) 12:15:15 .net

つctrl+t
俺もDIは好かんけど
eclipseもまともに使えないヤツには無理

84 ：デフォルトの名無しさん：2008/09/02(火) 16:36:26 .net

なんですとぉ！？

85 ：デフォルトの名無しさん：2008/09/02(火) 23:56:13 .net

POJOってどうよ。アレを実現するための設定も
面倒に感じるんだが。

86 ：デフォルトの名無しさん：2008/09/03(水) 00:43:13 .net

>>85
あまりに漠然としすぎててどの話をしてるのか分からん。

>>68
ネストしたトランザクションがスマートに記述できない時点で
もう面倒だと思いますよ、俺は。
それでもなお俺様フレームワーク最高ですか？そうですか。

87 ：デフォルトの名無しさん：2008/09/03(水) 01:11:41 .net

トランザクションのネストってどんなケース？
外側トランザクションの中に内トランザクションがいくつかあるの？
内トランザクション1がコミット成功して内トランザクション2で
失敗したらどうなるの？

88 ：デフォルトの名無しさん：2008/09/03(水) 01:32:12 .net

内1のトランザクション状態を内2で引き継いで
内2で失敗した時点で内1もひっくるめてロールバックされる。
コミットが行われるのは外のトランザクションが成功した時。

89 ：デフォルトの名無しさん：2008/09/03(水) 01:37:24 .net

外側で宣言してれば内側のコミットは無視されて、
内1だけ呼びたい時は内1のコミットをアテにして、
内1、内2って呼びたいときは内1の中に書いてあるトランザクション処理を
無視できるから楽ってこと？

90 ：デフォルトの名無しさん：2008/09/03(水) 22:57:52 .net

>>85
POJO と abstract class タイプフレームワークの綱引きがあって、
睡眠不足で寝ぼけてると、見当違いのところに abstract class タイプのフレームワークを適応しちゃったりする。
使い分けは、きっちりやりたいね。
ちゃんと睡眠とって、すっきり脳味噌で POJO を書こう。
今大人気だから覚えといて損はないよ

91 ：デフォルトの名無しさん：2008/09/04(木) 00:20:52 .net

POJOはフレームワークに依存、
StrutsクラスはStrutsに依存。

おまえらバカなんじゃね？

92 ：デフォルトの名無しさん：2008/09/04(木) 00:35:08 .net

意味不明

93 ：デフォルトの名無しさん：2008/09/04(木) 00:38:06 .net

>>91
依存してるかどうかじゃなくて依存をコントロールできることが重要なのに、何言ってんだおまえは。

94 ：デフォルトの名無しさん：2008/09/04(木) 00:46:32 .net

たかが Bean Builder に御大層な名前が付いただけ。

95 ：デフォルトの名無しさん：2008/09/04(木) 01:57:13 .net

長くこの業界にいて思うこと。
構造化プログラミングの時だってごく少数の優秀な人は
わかりやすくて綺麗な構造化をしていた。OOPの時代になっても
優秀な人の割合は変わってない。凡人がソースを書くときの
汚さが、構造化の時よりちょっとマシになっただけ。
でもその恩恵はインターネットの普及により情報が得やすく
なったせいかもしれない。

96 ：デフォルトの名無しさん：2008/09/04(木) 02:20:31 .net

根幹部分は自分で書いて、ビジネスロジックだけ構造化OOP使いに書かせるから問題なし。
DIなら上流PGの実装が間に合わない時はDAOの具体実装をダミーにしとくとか調整も出来るよ。

97 ：デフォルトの名無しさん：2008/09/04(木) 03:18:44 .net

>>89
このケースに限ってはそう。

でも本質はコードに横断的情報が含まれないことが
多くの利益をもたらすって話なんだけど。

そのロジックの処理の本質にトランザクション管理が関与するのかって話。
必要ないのに手続きのために書いてるのなら、
ノイズが乗ってるのと同じこと。
追い出せるなら追い出したいと、なぜ考えないのか。

>>95
情報が得やすくなったのは確かだけど
情報を得ようとする人がたいして増えてないのもまた事実で。
成長待ってても埒があかないから、いろいろな話をしてみるけど徒労に終わる。

探せば情報が得られる分、スキルの格差はむしろ広がってるのでは。

98 ：デフォルトの名無しさん：2008/09/04(木) 05:21:34 .net

>なぜ考えないのか。

なぜそんな上から目線なのか

どこからどこまでを同じトランザクションにまとめないといけないのか、
は本質的な処理だろ。マーチンファウラーの提唱するような薄いサービス層の
ポリシーを守っていれば、トランザクション管理をxmlに置くのか
Serviceメソッド内に置くのかの違いでしかない。トランザクションの
範囲を確認するのに設定ファイルを別に開くよりは見やすい。

注文と残高を同時更新する場合と、残高だけを更新する場合で
Serviceを分けなくても良い(前者の場合でも残高だけ更新Serviceを呼び出しても
よい)というのは確かにメリットだと思う。

99 ：デフォルトの名無しさん：2008/09/04(木) 11:32:30 .net

今はネットで回答だけ得られるからね。
昔は本とか読むしかなかったから、いきなり答えが得られることは少なかった。
だからどうしても書いてあることを理解して自分で応用する必要があった。

100 ：デフォルトの名無しさん：2008/09/04(木) 15:02:30 .net

宣言的トランザクションは実装としてAOPを利用しているけど、
特定のメソッドから特定のメソッドの間でトランザクションを定義することは
横断的な情報、つまりAOPじゃないよね

101 ：デフォルトの名無しさん：2008/09/04(木) 15:53:23 .net

うんそう思う。
ただしトランザクションをどう実装するかはコードの本質ではない。

102 ：デフォルトの名無しさん：2008/09/05(金) 01:27:42 .net

どこからどこまでをトランザクションの範囲にするかってことが
必ずしも本質的な処理とは思えないんだが・・・
むしろ「モデルの状態を元あった状態に戻す」ためのひとつの実装パターンに
すぎないのでは？

103 ：デフォルトの名無しさん：2008/09/05(金) 10:31:45 .net

そうじゃなくて、少なくともこのメソッドのスコープ内は
トランザクション処理しなきゃならないとかそういう話。

104 ：デフォルトの名無しさん：2008/09/05(金) 23:02:14 .net

>>103はだれにレスしてんだ？

105 ：デフォルトの名無しさん：2008/09/06(土) 01:42:18 .net

オライリーのインターフェイス指向設計を読み終えた。
わりと良書だったが、悲しいかなDIの話題はなかった。
(チラッと名前だけ出る程度。)
代わりにサービスをルックアップするコードが記述されていた。

今時どうかと思った。

106 ：デフォルトの名無しさん：2008/09/06(土) 20:42:33 .net

>>95
普通の人が書いた汚いコードなら、構造化プログラミングとかのほうがよっぽどマシ。
OOPわかってない奴が書いたOOPっぽいコードなんて、汚な過ぎて見てると吐きそうになるだろ？

107 ：デフォルトの名無しさん：2008/09/06(土) 20:52:30 .net

>>106
なる。
ドメインオブジェクトに関わりの薄いロジックが入っていたり、
固有のクラスでしか行われない処理が基底クラスに入っていたり

ス○ー○ジッ○のソースはひどかった

108 ：デフォルトの名無しさん：2008/09/06(土) 21:30:18 .net

スターロジック？
聞いたことねえや

> OOPわかってない奴が書いたOOPっぽいコード
ああ、見てるとイラッと来る
自分も一度は通った道ではあるものの

109 ：デフォルトの名無しさん：2008/09/07(日) 00:55:05 .net

Struts知ってる俺がS2Strutsを触ったが全然動かない・・・
おまいらコレすっと動いた？

110 ：デフォルトの名無しさん：2008/09/07(日) 02:25:30 .net

激しくスレ違い

111 ：デフォルトの名無しさん：2008/09/07(日) 11:46:30 .net

>>107
恨みでもあるの？
そこで名前を出す意味が分からないな

112 ：デフォルトの名無しさん：2008/09/07(日) 21:13:24 .net

>>109
ずっとうごいたけど

113 ：デフォルトの名無しさん：2008/09/14(日) 21:08:26 .net

DIって、フレームワークを提供する側や、業務パッケージを作成する場合なんか
には有効かもだけど、１から作るような業務アプリではメリット感じない。
大体、１から作るような業務アプリという時点で泥くさいことやらなきゃいけない
ケースが多いし、インターフェースが有効なケースもあんましない。
(パッケージ使用しない時点で、客は泥くさい対応を求めてくる。)
1インターフェースで1パターンだったら、密結合でも疎結合でもどっちゃでもいいん
じゃない。影響極少だし。

まぁ設計力の問題かもしれない。業務アプリでうまく交通整理できた具体例なんかが
あれば、ほんと具体的に教えてほしい。

114 ：デフォルトの名無しさん：2008/09/14(日) 21:11:59 .net

>>113
その業務は未来永劫仕様が変らないの？

115 ：デフォルトの名無しさん：2008/09/14(日) 21:15:24 .net

こんなわかりやすくて便利なもんがこの評価か・・・VBerを思いだす

116 ：デフォルトの名無しさん：2008/09/14(日) 21:22:13 .net

>>114
そんなことはない。ただ小変更の場合は実装クラス内の変更にとどまる
ことが多い。大きな変更の場合は、設計の根幹を揺るがすようなことが
ままある。実際客にとり、メリットあるのは、大きな変更のほうなん
だが、その場合は残念ながら、DIは無力だと思う。

117 ：デフォルトの名無しさん：2008/09/14(日) 21:44:38 .net

正直AOPやDIがJavaの限界に思う。
下位互換にこだわりすぎる言語の宿命だよ。
明らかに無理し過ぎてる。

118 ：デフォルトの名無しさん：2008/09/14(日) 22:02:49 .net

>>115
今はそういうのはPHPerが担ってるよ

119 ：デフォルトの名無しさん：2008/09/14(日) 23:04:57 .net

一から作るならGuiceあたり使っておけばいい。
JavaEEはJSF+Faceletsを使って、WebBeansは出たら採用する。
正直SpringだのS2だのへの投資は無駄な投資。

120 ：デフォルトの名無しさん：2008/09/14(日) 23:22:56 .net

>>117
DIなんて実行時に今までやっていたことを設計時に限定する代わりに
設定ファイルで簡単に記述できるようにしただけだよね。
言語使用でサポートするとしたらどうなるのかな。

121 ：デフォルトの名無しさん：2008/09/15(月) 07:00:32 .net

>>113
に一票だなぁ。
>>114
とかは、微笑ましく思える。

122 ：デフォルトの名無しさん：2008/09/15(月) 15:50:28 .net

業務自体の変更はDIの範疇じゃないと思うが、
業務の本体じゃない横断的な事象を切り出すには便利に使えると思うよ。
ただの道具として利用するレベルでも。
横断的関心事を業務の本体から切り離すってのはまあ、AOPの範疇かもしれんが。

123 ：デフォルトの名無しさん：2008/09/15(月) 15:56:50 .net

業務プログラムがテンプレートメソッドパターンに落とせないのであれば、
インタフェースベースの設計をする価値はないだろうね。

124 ：デフォルトの名無しさん：2008/09/15(月) 18:19:23 .net

？

125 ：デフォルトの名無しさん：2008/09/15(月) 18:23:01 .net

なんらかの業務処理をプログラムに落とし込む必要があって、
それに対してインターフェイスを書かない状況ってのは、ちょっと分からないな。

そもそも、それって Java使う必要あんの？
LLの方が向いてない？

126 ：デフォルトの名無しさん：2008/09/15(月) 19:10:18 .net

ソフトウェアカスタマイズなら割とある。

127 ：デフォルトの名無しさん：2008/09/15(月) 22:05:04 .net

そりゃ、〜〜業務を1メソッドや1クラスにだらだら書いているなら、
DIなんて何の意味もないだろうさ。

128 ：デフォルトの名無しさん：2008/09/15(月) 22:53:41 .net

何か頭の悪い誇張野郎が沸いてるな。

129 ：デフォルトの名無しさん：2008/09/16(火) 00:12:09 .net

AOPやDIで業務システム作ったけど大した恩恵は受けてない。画面や検索条件。業務ロジックの修正がほとんど。結局LLでやればよかったと思ってる

130 ：デフォルトの名無しさん：2008/09/16(火) 02:18:19 .net

>>129
本質的な部分の修正だけですむのはDIの恩恵を受けてるんじゃないか？

131 ：デフォルトの名無しさん：2008/09/16(火) 02:39:07 .net

>>130
なんでもDIのおかげにしたいんですね。

132 ：デフォルトの名無しさん：2008/09/16(火) 02:48:59 .net

>>130
それ言うなら、どっちかっつうとAOPの恩恵なんじゃね？

133 ：デフォルトの名無しさん：2008/09/16(火) 20:40:32 .net

>>130,132
それはMVCをきちっとわけてれば出来ることだし、
OO以前の構造化設計でもきちんと設計が出来ていればできること

134 ：デフォルトの名無しさん：2008/09/16(火) 21:24:30 .net

その「きちんと」を楽にするためにOO言語なりツールがあるわけで。
「楽したい」と考えないエンジニアは碌なもんじゃないと思うんです。

135 ：デフォルトの名無しさん：2008/09/16(火) 23:27:14 .net

別にDIとかAOPによって不可能だったことが可能になったわけじゃないんだから。
より楽な、より便利な使える道具ができたってだけのことだろう。

136 ：デフォルトの名無しさん：2008/09/17(水) 01:14:46 .net

本質以外のことはやりたくないからどんどん外に出した。
外出ししたオブジェクトをルックアップするコードを書くのも面倒になった。
何使うかだけ書いといて、あとは外から勝手に注入してもらえば楽くね？

これだけだぞ、DIコンテナの本質は。

これがどういう意味を持つか分かる人以外には
どれだけ触っても全くの時間の無駄だ。

137 ：デフォルトの名無しさん：2008/09/17(水) 01:45:51 .net

楽くね？
くねくね？

138 ：デフォルトの名無しさん：2008/09/17(水) 05:05:33 .net

DIって普通はリンカが自動的にやってることを、手動で設定してるようなイメージ。

139 ：デフォルトの名無しさん：2008/09/17(水) 12:32:29 .net

退化

140 ：デフォルトの名無しさん：2008/09/17(水) 12:41:16 .net

DIで楽が出来るのはわかってる。学習コストとメリットを天秤にかけた時に
業務アプリで使うのはどうかって話だ。今のspring他の実装はまだ過渡期で、
5年後には設定方法やデファクトのDIツールすら変わってる可能性が
大いにある。Apache Torqueなんてまだ使ってるやついるか？
いたらゴメンね。でメインの開発者がとっくに退社してる場合、
今更Torqueなんてメンテし続けたくねーとか、Apache ECSなんて
jsp出てきた時点で終わってんだろ、とか思う訳じゃない。
それを繰り返したくない。ちょっとファクトリクラス書くのが
楽になる程度の使い方なら、後の人がすぐ追えるようにシンプルな
ファクトリを書いておいたいいんじゃないか、と悩んだ事は何度もある。

いい加減springなら平気だろと思って使ってるわけだけど

141 ：デフォルトの名無しさん：2008/09/17(水) 14:07:48 .net

Guiceくらい便利に使って欲しいところだけど、俺の周囲じゃ正直無理だと思った。
設計思想というものが前提的に存在しない層とはJavaは相容れないな。

142 ：デフォルトの名無しさん：2008/09/17(水) 14:34:53 .net

開発者の質が悪いからってのも、本末転倒な話だな。
むしろ、低レベルな開発者を排除すべきだと思うんだが。

優秀な人間だけ集めると、開発ペースがメチャメチャ速くなるぞ。
無駄なドキュメントは作らなくてすむし、くだらないバグも仕込まれないし。

143 ：デフォルトの名無しさん：2008/09/17(水) 14:37:24 .net

そんなことが簡単に出来たら苦労はないわ

144 ：デフォルトの名無しさん：2008/09/17(水) 14:53:38 .net

100人月とかの開発をやったこと無いんだろう

145 ：デフォルトの名無しさん：2008/09/17(水) 15:02:53 .net

Guiceいいかもと思ってGuiceスレに行ったら泣けてきた。
あんまし使われとらんの？

146 ：デフォルトの名無しさん：2008/09/17(水) 17:15:04 .net

日本人が作ってないからヲチネタが少ないだけ

147 ：デフォルトの名無しさん：2008/09/17(水) 21:51:04 .net

>>143
そりゃ、簡単には出来ないよ。

>>144
普通の会社が100人月かけるところを、30人月とかでやってしまうってことだよ。

148 ：デフォルトの名無しさん：2008/09/17(水) 22:22:50 .net

開発ペースが速くなるのは良いが、人的リスクはどうなるのかね？
少数精鋭だと事故や病気で欠員が出ると途端に回らなくなるが。
後メンテナンスにも「優秀な」人材が必要になったりしないよな？
ノウハウが属人化して「Aさんじゃないと判らない」なんてよく聞く死亡フラグだ。

（もちろん>>147は、そんな奴は優秀とは言わないとか
優秀な人材ならすぐ対応できるとか言うんだろうが）

普通の会社ではどうするかって？
そこそこの能力で替えが効く人間を大勢揃えるのさ。
もちろん、人間の替えが効くようにメジャーな言語や技術を選択して
必要なスキルレベルも最低ランクの人材に合わせる。
これならメンテナンスする人材もすぐ都合がつくしな。

100人月とかの開発で必要な「優秀な」人材ってのは、
こういった面も見据えて適切な技術を選択したり
必要であれば独自フレームワークを設計したり
開発チーム全体のスキルレベルの底上げを行ったりできる開発者だろな。

なんて超アタリマエな事を偉そうに語ってすまん。

149 ：デフォルトの名無しさん：2008/09/17(水) 22:39:27 .net

長いから1段目しか見てないが、
うちも少数精鋭で立て続けに二人居なくなって
あばばばばってなったよｗ

150 ：デフォルトの名無しさん：2008/09/17(水) 22:50:30 .net

優秀な人間だけ30人も集められるわけがなかろう。

151 ：デフォルトの名無しさん：2008/09/17(水) 22:51:49 .net

あいや上は無視してorz

まいずれにしても優秀な人間だけ集めるってのはやっぱり現実には無理がある。
優秀な人間は各プロジェクトに分散させるもんだからな。

152 ：デフォルトの名無しさん：2008/09/17(水) 23:08:57 .net

30人月って、3人x10ヶ月のことじゃないのか。

153 ：デフォルトの名無しさん：2008/09/17(水) 23:10:32 .net

30人月だと普通は5人×6ヶ月くらいじゃね？

154 ：デフォルトの名無しさん：2008/09/17(水) 23:17:40 .net

今の現場は人ばかりいてダラダラ1000人月は消化してるな。
プロジェクト管理？
決まってるじゃないか、エクセルだよ！

155 ：デフォルトの名無しさん：2008/09/18(木) 00:19:09 .net

知らないうちにヘンなインスタンスと会話してたりするとコワイよなぁ・・・

DIコンテナってある意味、人間関係の希薄な現代社会みたい。

156 ：デフォルトの名無しさん：2008/09/18(木) 00:41:51 .net

妹だと思ってお尻なでてたらお袋だった、みたいな？

157 ：デフォルトの名無しさん：2008/09/18(木) 00:52:58 .net

>>148
欠員リスクはあるね。そこまで大きな仕事になると受けられないな。

で、引継ぎのほうなんだけど、運用保守要員のトレーニングも引き受けたり、
社内標準化と込みでやったりする。それに、そもそも特殊な技術を使うわけでもないし。

あと、俺の主張は「無能は使うな」であって、「優秀な人だけでやれ」ではないよ。

158 ：デフォルトの名無しさん：2008/09/18(木) 11:03:38 .net

それすらも難しいのが結構現実…

159 ：デフォルトの名無しさん：2008/09/18(木) 17:50:47 .net

ホントホント

2chに書き込んでるような俺らみたいなヤカラでさえ、
より良い設計に興味があるだけマシで
普通のPGは会社引けたら知らんぷりだもんな

160 ：デフォルトの名無しさん：2008/09/18(木) 20:43:51 .net

まあ中にはPGには余計な知恵をつけて欲しくないとかで
DIコンテナとかの話するだけで目の敵にするような奴もいるしな。

…それはそれで正しいのか？そうは思いたくないが。

161 ：デフォルトの名無しさん：2008/09/18(木) 20:56:26 .net

作業者(制御構造を書くだけ一般PG)にまでDIなんて意識させるか？
DIなんて裏方だし、骨組み作る人間だけが意識してれば良いじゃん。

162 ：デフォルトの名無しさん：2008/09/18(木) 21:06:49 .net

そしてさらにPGの二極化が進むのであった。

163 ：デフォルトの名無しさん：2008/09/18(木) 21:19:46 .net

日本って人材に甘すぎるのか、分からない分からないを繰り返して
残業しまくって成果物がゼロに近い奴が首にならないんだよな。
しばしば年収を意識しちゃって鬱になるよｗ

>>160
費用対効果だわな。
DIはOJTの範囲外なのでちょっと投資する必要がある。

164 ：デフォルトの名無しさん：2008/09/19(金) 00:43:31 .net

>>161
実装者が理解できてないままだと
interface 使わないコードを平気で持ってくるわけだが。
お前さんのレビューのコストがバカになんねえよ。
実例挙げて教育した方が絶対早い。
分からないやつは切り捨てたらいいから。

165 ：デフォルトの名無しさん：2008/09/19(金) 20:35:47 .net

>>164
理解させずとも「規約違反」で片付ければいいだろ。

ガチガチの規約ずくめのプロジェクトなら
そもそもPGが勝手にinterfaceを作ることすら「規約違反」だしな。

166 ：デフォルトの名無しさん：2008/09/19(金) 20:46:29 .net

クラスの追加が承認制というようなこともするけどね。
レイヤ構成と機能毎の箱だけ用意しておいて、後はそこに
処理を書いてください、みたいな。

馬鹿にしているとも思うけど、悲しいかな、そうしないと
最低限の品質を保てないということもある。

167 ：デフォルトの名無しさん：2008/09/19(金) 23:10:35 .net

>>166
それやっちゃうと3000行のメソッドや10000行のクラスが湧いて出たりしない?
そうならないように適切に分割したクラスやインターフェース書いて渡すの?
でもそういうのが判断できるとこまで設計したら、
中身も自分で書いた方がはるかに少ない工数で作れるよね……。

168 ：デフォルトの名無しさん：2008/09/19(金) 23:48:26 .net

3000行のメソッドや10000行のクラスはさすがに無い。
レイヤ、機能までをそれなりに分割したものを渡すけど、
それでなくても今時3000行のメソッドは無いだろう(ﾟдﾟ )？

むしろ気をつける必要があるのは、重複する処理が作られること。
これはチェックして交通整理する必要有り。

工数というか効率に関しては、少数精鋭の方が良いのは勿論だけど、
1人で単位時間当たり1の成果を出すのではなく、10人かき集めて
単位時間当たり2の成果(効率は1/5)を求められることもある(´・ω・`)

169 ：デフォルトの名無しさん：2008/09/20(土) 11:51:27 .net

優秀な人とそうでない人の差は生産性だけじゃない。
実際生産性自体は大きなな差はないこともある。
特に業務処理みたいなのの実装では。
しかし品質や保守性にはかなり差が出る。

業務処理とかじゃなくてもっと基盤よりの実装だったりして難度が高い部分だと
生産性にも品質にも保守性にもそれを使う側への影響にも大きな差がでる。
そもそも優秀じゃないと出来ないものもある。

170 ：デフォルトの名無しさん：2008/09/20(土) 12:27:40 .net

>>168
1メソッド3000行はさすがに見たことないけど。

1000行のメソッドAの一部処理を別の1000行のメソッドBにしてあり、
メソッドBの一部処理をまた別の1000行のメソッドCにしてある、とかなら普通に見る。

ちなみに10000行どころか70000行程度のクラスまでなら普通に見る。
VB.NETのForm継承クラスに業務処理まで突っ込んだやつ。

171 ：デフォルトの名無しさん：2008/09/20(土) 14:07:32 .net

まじかよ

172 ：デフォルトの名無しさん：2008/09/20(土) 15:21:57 .net

ま〜なんだ。
DIの有用さが理解出来ない奴は、これまでテストをきちんとやって来なかった奴だな

173 ：デフォルトの名無しさん：2008/09/20(土) 18:30:26 .net

組織を改善したければOJTという思考停止剤を経営者から奪わないといけない。

174 ：デフォルトの名無しさん：2008/09/20(土) 22:18:01 .net

テスト以外に何かに使えねえかなあ。>DI

175 ：デフォルトの名無しさん：2008/09/20(土) 23:12:38 .net

疎結合最高だよな、いやまじで。な人と
疎結合って何？食えるの？な人の振り分けに使える。

インターフェースと実装は分けるだろ、普通。な人と
実装継承最高!オブジェクト指向って継承しまくることだろ？な人の振り分けに使える。

ステートレスが基本だが場合によってはステートフルなロジックも必要か、な人と
メンバ変数ってクラス内グローバルで最強だよな。スレッドセーフ？わけわかんねえ横文字口走るなよ、な人の振り分けに使える。

100行超えるとキモいからクラスなりメソッドなりにして意味のある名前付けようぜ、な人と
3000行超えるメソッドや10000行超えるクラス作っても動けばそれでいいだろ、な人の振り分けに使える。

なんでコードをコピペすんだよ。3回同じこと書いたら首吊って死ね！な人と
コピペのどこが悪いんだよ、動けばそれでいいだろ、このタコが！な人の振り分けに使える。

なんでテストコード書かないの？馬鹿なの？な人と
テスト書く時間でコード書けばいいでしょ？早く帰りたいでしょ？な人の振り分けに使える。

用途はたくさんあるぞ。

176 ：デフォルトの名無しさん：2008/09/21(日) 09:43:26 .net

インタフェースを実装したクラスを継承してる奴らは多いけどな。

177 ：デフォルトの名無しさん：2008/09/23(火) 01:45:47 .net

＞ｽﾃｰﾄﾚｽが基本だが場合によってはｽﾃｰﾄﾌﾙなﾛｼﾞｯｸも必要か
自分も、業務ロジッククラスであっても値としてのプロパティを持たす事は少ないんだけど
(基本的にインターフェースだけプロパティに持たす)
これって普通なの？
状態を持たないクラスばかりであまりオブジェクト指向っぽくないかなと思ってた

178 ：デフォルトの名無しさん：2008/09/23(火) 02:17:20 .net

一般的に対話型アプリは重厚なセッションを持つものだよ。
Webアプリがそうなるのはオブジェクトライフサイクルの都合かな。
スケーラビリティの都合と言い換えてもいいと思う。

179 ：デフォルトの名無しさん：2008/09/23(火) 06:00:48 .net

>>175
DI の問題点というのはまさにそこで、
その振り分けを生き延びた精鋭にしか保守できないシステムを作りまくるわけですよね。

業務システムの開発という場面では、保守担当者を選ぶコードなど糞です。

180 ：デフォルトの名無しさん：2008/09/23(火) 12:02:46 .net

>>179
一般的に >>175の内容で振り落とされた奴のコードはメンテし難いと思うんだが…

それからステートレス，ステートフル云々はwebアプリ実装する上では必須の知識でしょう。
まあ、それ以外でも必要だと思うけど。

OOP勉強すりゃ、DIなんて難しいこと何も無いと思うけどね。
スレッドプログラミング初心者にマルチスレッドサーバのメンテをさせることで金貰おうとしてないか？OOPも同じことだと思うんだが。
それで苦労するんなら、金貰って勉強できる分有り難いと思え。
それで勉強しないのなら諦めて辞めろと言いたい。

181 ：デフォルトの名無しさん：2008/09/23(火) 12:17:25 .net

>>179は
「業務システムに適用するスキルレベルを引き下げないと保守要員が確保しづらい」という話をしてるのに
なんで>>180では
「保守したきゃスキルあげてこい」って話になるのかな？なるのかな？

182 ：デフォルトの名無しさん：2008/09/23(火) 12:26:54 .net

OOP以前に、>>175で振り落とされるような人間はまともな構造化分析も出来ないだろうし。

業務による垂直方向の機能分割と、レイヤによる水辺方向の機能分割。
DIってのはそれを補助する仕組みにすぎないんだから。

あって困るものでないというものであって、精鋭でないと使えないなんていうのは
大きくな勘違いだと思うよ。

それが理解できないなら、煽りでなく、職業を変えた方が良いと思う。

183 ：デフォルトの名無しさん：2008/09/23(火) 12:43:56 .net

DIのインフラを作ってしまえば後は誰が保守してもかまわんでしょ
初期設計にまともなプログラマが居れば良いだけ。

184 ：デフォルトの名無しさん：2008/09/23(火) 12:55:21 .net

>>182
俺の言いたいこと全部言ってくれて助かったんだが、

＞それが理解できないなら、煽りでなく、職業を変えた方が良いと思う。
これ実践すると、日本のプログラマ人口は1/100以下になるよな。多分。

185 ：デフォルトの名無しさん：2008/09/23(火) 12:59:34 .net

まあ理解力うんぬんより「OOP勉強するくらいなら業務知識仕入れるわ」な奴のが一般的だしな。

186 ：デフォルトの名無しさん：2008/09/23(火) 13:50:10 .net

PGが業務知識云々を言い出すと負け犬みたいなイメージがあるな。

187 ：デフォルトの名無しさん：2008/09/23(火) 14:08:12 .net

>>186
いや、それはむしろそっちの方が正しいだろ。

一般的な業務アプリの世界では、99/100の作業者PGには
テクニカルな事よりも業務知識を覚えさせて。

アーキテクチャとかは1/100な人間が決めて、作業者PGは
その枠組みの中で制御構造だけ書いていた方が効率が良い
…っというか、現実的ではあるから。

テクニカルな仕事がしたいのであれば、インフラ系、
製品開発、Web系、組込み系へいくべきだろう。

188 ：デフォルトの名無しさん：2008/09/23(火) 15:39:34 .net

>>184
>これ実践すると、日本のプログラマ人口は1/100以下になるよな。多分。
でも残った人の仕事は逆に楽になっちゃう、みたいな。

189 ：デフォルトの名無しさん：2008/09/23(火) 15:45:40 .net

ないない。

190 ：デフォルトの名無しさん：2008/09/23(火) 16:01:27 .net

まあ、下の方の人間が多少減ったところで
結果として出る成果に違いは無いとも思うし、
居ても居なくても同じどころか、
むしろ居ない方が良い人間が居るのにも
同意はするが。

でも、矢面に立って無駄死にしてくれる人間が居ないと、
こっちにまで変なおはちが回ってくるので、
まあ、居ても良いよというか、そんなかんじかな。

191 ：デフォルトの名無しさん：2008/09/23(火) 21:45:03 .net

漏れは普通(?)に「悪貨は良貨を駆逐する」と思うが。

業務知識も知らないよりは知っていた方がいいだろうけど、
それは最低限のエンジニアとしての力量があってから初めて役に立つのであって、
上（アーキテクトする人）の言う事も理解できんアフォが「業務知識」とか言うと胡散臭ぇ。

192 ：デフォルトの名無しさん：2008/09/23(火) 21:55:39 .net

アーキテクトが「上」だとか、さらっと言っちゃう？

193 ：デフォルトの名無しさん：2008/09/23(火) 22:01:51 .net

アーキテクトはむしろ「横」。

194 ：デフォルトの名無しさん：2008/09/23(火) 22:22:03 .net

正直、PG程度に求められる業務知識なんて、
そんなたいしたもんじゃないけどな。
誰でもしばらくやっていれば身につく程度の内容で。

本当に業務知識があると思うのなら、
PGなんかやめて、それ専門で飯を食ったほうが
良いと思うし。

35歳で定年になったり、PG→SE(笑)→無能なPMと
ジョブチェンジして、現場に迷惑をかけたい奴は
技術より業務知識でもなんでも良いと思うが。

よく、転職情報とかにも業務知識がある人間が
不足しているみたいな事が書いてあるけど、
俺の感覚としては、本当に足りてないのは、
技術的なバックボーンを持って、意志決定できる
人間だと思うがな。

195 ：デフォルトの名無しさん：2008/09/23(火) 22:33:43 .net

なんかスレ違いな話題が増えてきたけど、「業務知識」を言い出すＰＧは
信用しない方がいい、ってのは共通認識みたいだな。

196 ：デフォルトの名無しさん：2008/09/24(水) 11:24:48 .net

そんな極論
修正してやる！

197 ：デフォルトの名無しさん：2008/09/24(水) 11:28:12 .net

PGで優秀じゃなかったやつは大概ロクなSE/PMにならないけど
時々いるよね、顧客との折衝がうまくてSE向きの人とか、
人間関係調整するのがうまくてPM向きの人とか。
例え人差し指だけでキーボードを打ってても

198 ：デフォルトの名無しさん：2008/09/24(水) 11:29:02 .net

ごめんスレとなんの関係もなかった

199 ：デフォルトの名無しさん：2008/09/24(水) 20:43:18 .net

プログラムができないから、業務知識とか言い出す奴は困りものよね。

顧客の言うことをオウム返しするだけの無意味な存在になったり、
技術的背景が無いせいでにアホな設計をして、無駄な工数をかけて
デスマを引き起こしたりと、ろくなもんじゅない。

顧客と技術がわかる人間が差し向かいでやったときの生産性の高さを
一度経験してしまうと、そういうのって本当に馬鹿らしくてやって
いられない。

さらにスレ違いすまそ。

200 ：デフォルトの名無しさん：2008/09/24(水) 22:05:12 .net

なんだこりゃ愚痴スレか。

偉そうにスレ違いな会話を続けるくらいだったらDIをもっと広める方法でも語ってくれよ。
業務知識とか言い出すPG（よほど恨みでもあるのか？）の説得方法とかさ。

201 ：デフォルトの名無しさん：2008/09/24(水) 22:15:02 .net

DIコンテナ自体はもう十分コモディティ化していると思う。

コンテナ自体を布教したりDependency Injectionパターンを
どうこう語るよりも、DIを使ったプロダクトを盛り上げた方が
嬉しいんじゃないかな。

202 ：デフォルトの名無しさん：2008/09/25(木) 01:19:27 .net

というより初期開発にアーキテクト役を置こうとしない組織をなんとかすべき。
いったんDIを無理矢理導入すれば、後は使い込むにつれ説明不要で依存し出す。

203 ：デフォルトの名無しさん：2008/09/25(木) 01:25:12 .net

確かにキラーアプリがあると嬉しいところなんだが。

情熱と時間がないと無理よね。俺には無理。

204 ：デフォルトの名無しさん：2008/09/25(木) 01:34:19 .net

>いったんDIを無理矢理導入すれば、後は使い込むにつれ説明不要で依存し出す。
無理。
オブジェクト指向言語使っても構造化以前の
スパゲティコード書くやついるでしょ。あれと同じ。

DI使ってるはずなのに、オブジェクトを名前で探し出してたり、
あるいはなんでもかんでも new してたりするから。

あなたが然るべき立場の人間で、現場でそれを強制するだけの発言力があれば話は別。

205 ：デフォルトの名無しさん：2008/09/25(木) 01:42:50 .net

OO言語＝オブジェクト内グローバル変数の持てる言語
という導入から入っても俺は迷うことなくDIまで辿り着いたなぁ。
保守思考が高いか否かで、個人差が出るのかなと思ってる。

206 ：デフォルトの名無しさん：2008/09/27(土) 01:32:33 .net

実際のところ、仕事で何か使ってる？

Springは「困ったら英語のドキュメントを読む人」でなければ使えない
Seasarは「困ったらソースコードを読む人」でなければ使えない

という印象。
少なくとも、チームリーダーがしっかりしてるレベルの部隊でないと
現状ではどちらも厳しいと思うのだが。

207 ：デフォルトの名無しさん：2008/09/27(土) 01:44:44 .net

設定の外部化が善という宗教
記述量の削減が善という宗教

208 ：デフォルトの名無しさん：2008/09/27(土) 04:07:26 .net

>>206
それくらいできない奴は、いなくなった方が楽になる

209 ：デフォルトの名無しさん：2008/09/27(土) 07:26:39 .net

>>208
それは組織力のないチーム(=一匹狼の寄り合い所帯)の言い訳

210 ：デフォルトの名無しさん：2008/09/27(土) 08:15:02 .net

それくらいもできなくて、できるようになろうとしない奴らは
それですむ仕事をすればいいのに、なんで開発者になるんだろうか？

211 ：デフォルトの名無しさん：2008/09/27(土) 09:33:43 .net

まあダメダメSIer だと、良いプロジェクト == 儲かるプロジェクト == Hello World Javaモンキー１００匹突っ込めるプロジェクト
だったりするんで、実は心の奥底から生産性なんか求めてなかったりする。
組織力ってのも Javaモンキー１００匹集められるか否か、ただそれだけだったりもする。

212 ：デフォルトの名無しさん：2008/09/27(土) 10:18:41 .net

なるほど、それに浸かりきったバカが自分のバカさすら忘れて
>>209みたいなことを言うんだね

213 ：デフォルトの名無しさん：2008/09/27(土) 15:50:54 .net

なぜすぐ煽り合いになるのか？

214 ：デフォルトの名無しさん：2008/09/27(土) 16:14:50 .net

だってここ2chだし

215 ：デフォルトの名無しさん：2008/09/27(土) 19:28:29 .net

むしろ本当の少数精鋭チームならJava使わないだろもう

216 ：デフォルトの名無しさん：2008/09/27(土) 20:37:02 .net

むしろ本当の少数精鋭チームならDI使わないだろもう

217 ：デフォルトの名無しさん：2008/09/27(土) 20:38:44 .net

逆々

218 ：デフォルトの名無しさん：2008/09/27(土) 20:50:31 .net

Javaを使っていないのであれば、DIを使っていなくてもおかしくは無いが

219 ：デフォルトの名無しさん：2008/09/27(土) 20:55:15 .net

spring以外に選択肢が無いのが問題
s2はhackerのオモチャ

220 ：デフォルトの名無しさん：2008/09/27(土) 21:01:51 .net

guiceは？

221 ：デフォルトの名無しさん：2008/09/27(土) 21:03:38 .net

藁

222 ：デフォルトの名無しさん：2008/09/28(日) 18:56:38 .net

http://d.hatena.ne.jp/higayasuo/20080928/1222594738

223 ：デフォルトの名無しさん：2008/09/28(日) 19:34:28 .net

Seasar2は慣れればサクサクなのだろうがそこまでの道程は結構険しい

問題なのは、真剣に学習コストをかけて展開するほど
今後長持ちするとは思われていないところじゃないかな

224 ：デフォルトの名無しさん：2008/09/28(日) 19:36:44 .net

一部のローカルグループのサークル活動に
人件費を裂くような馬鹿はいないだろ。
うちはWebBeansがJavaEEに載っかったら、
without EJBな連中とは決別する予定。

225 ：デフォルトの名無しさん：2008/09/28(日) 19:49:13 .net

そのサークルの人、みんな飽きるのが早いからね…
仕事ではリスクが高くて採用できない
(請負で作っちゃって納品ﾊｲｻﾖﾅﾗなPJなら採用できるのはﾅｲｼｮ)

226 ：デフォルトの名無しさん：2008/09/28(日) 20:29:42 .net

Javaはそういうのはまだマシな部類だと思うけどなー。
COBOLなんか大昔の極一部の俺流フレームワークが神扱いされてるから･･･。

それに比べればSeasar系はまだマシだろう。

227 ：デフォルトの名無しさん：2008/09/28(日) 20:40:46 .net

タイミングと内容から言って本人による宣伝なのかなあ


キモ

228 ：デフォルトの名無しさん：2008/09/29(月) 02:30:39 .net

>>224
without EJBっていつの時代だよ

229 ：デフォルトの名無しさん：2008/09/29(月) 20:12:09 .net

>>226
自分より下を見てまだマシだ安心する訳ですね。

230 ：デフォルトの名無しさん：2008/09/29(月) 20:46:28 .net

>>228
ロッド・ジョンソンは今でもwithout EJBだよ

231 ：デフォルトの名無しさん：2008/09/30(火) 00:56:51 .net

声が大きいのはひが氏だろ・・

232 ：デフォルトの名無しさん：2008/09/30(火) 01:33:11 .net

>>230
もうロッドのいうことを無条件に賛同してるやつはいないだろ。

233 ：デフォルトの名無しさん：2008/09/30(火) 01:55:47 .net

とりあえずよりよいプログラムを目指してここで情報収集してる
少数派がいがみあってもしょうがない

234 ：デフォルトの名無しさん：2008/10/02(木) 07:33:34 .net

こんだけ盛り上がるってことはまだまだ微妙なんだろうな
seasarも全然さくさくじゃねーしなｗ

235 ：デフォルトの名無しさん：2008/10/19(日) 21:03:33 .net

Springどこいったよｗ

236 ：名無し募集中。。。：2008/10/20(月) 01:28:40 .net

SAStrutsかなり最強だと思うけどなー
DIとは関係ない部分でだけど

237 ：デフォルトの名無しさん：2008/10/20(月) 03:18:26 .net

DIと関係ある話してくれよ

238 ：名無し募集中。。。：2008/10/20(月) 03:30:53 .net

DIを意識させないようにしてあるって所でいいなってさ

239 ：デフォルトの名無しさん：2008/10/20(月) 06:56:59 .net

SAStrutsはSeaserに依存しまくりでしょ？
SAStrutsをパクってコンテナに依存しないStruts拡張を作るのが吉。

240 ：デフォルトの名無しさん：2008/10/20(月) 07:14:32 .net

Sersarに依存してたらなんか悪いことあるのか？
Strutsに依存してることはOKなのか？

241 ：デフォルトの名無しさん：2008/10/20(月) 07:47:49 .net

本人が前にこういう事を言っていたけど。
ttp://d.hatena.ne.jp/higayasuo/20080613/1213326209
まあ、S2でいい人は別にSAStrutsで良いんじゃね。

242 ：デフォルトの名無しさん：2008/10/20(月) 07:53:13 .net

いまやSpring死亡してS2浮上中だけどな
今はその時とは事情が全く違う

243 ：デフォルトの名無しさん：2008/10/20(月) 11:44:06 .net

いやあのサポートポリシーはコミュニティが黙ってないだろうと思ったら
あっさり変更したじゃないか。springはまだまだ死亡しないだろ。

244 ：デフォルトの名無しさん：2008/10/20(月) 13:24:25 .net

よくわからんけど、プロダクトがコンテナに依存して
嬉しいことってあるの？
プロダクトを作る側ではなくて、使う側の話だけど。

非依存や切り替え可能にできるなら、その方が良くね？
特にSpringのゴタゴタとか見ていると。

T2はコンテナ非依存とか言ってるけどさ。よくわからんけど、プロダクトがコンテナに依存して
嬉しいことってあるの？
プロダクトを作る側ではなくて、使う側の話だけど。

非依存や切り替え可能にできるなら、その方が良くね？
特にSpringのゴタゴタとか見ていると。

T2はコンテナ非依存とか言ってるけどさ。

245 ：デフォルトの名無しさん：2008/10/20(月) 16:41:54 .net

大事なことだから・・・・？

246 ：デフォルトの名無しさん：2008/10/20(月) 20:04:47 .net

それこそ使う側だと選択肢が少ない方が脳を使わなくて済むと言う
メリットがあると言えなくもないが。

むしろ、作る側が非依存で切り替え可能だと、影響調査やバージョンの互換性
やらテスト項目がてんこ盛りで泣けてくるとだろうし。

247 ：デフォルトの名無しさん：2008/10/20(月) 20:59:50 .net

>>244
なんで2回繰り返してんだ？

依存するとコンテナの機能をフルに使える。
それで使う側に有益な機能が実現されればメリットになる。
DB依存のSQLも同じだろ。

248 ：デフォルトの名無しさん：2008/10/20(月) 21:13:31 .net

コンテナに依存して、その機能をフルに使うプロダクトを作るも良し。

別にコンテナ固有の処理に依存する必要もないので、コンテナの部分を
抽象化して、切り替え可能にしたプロダクトを作っても良し。

コンテナに依存しているプロダクトを別のコンテナと使いたいので、
そのプロダクトのコピー版を作っても良し。

249 ：デフォルトの名無しさん：2008/11/01(土) 16:39:33 .net

s2がやってるような処理は、プリプロセッサレベルで
dicon→javaのコード変換としてやってもらって、
後は普通にseasar2要らずでコンパイル→実行
みたいな枠組みは作れないのかなあ…
使う側としてはその方が嬉しいんだけどね。
プロダクトよりもseasar2の耐用年限を気にしないといけない今の状況だとチョット

250 ：デフォルトの名無しさん：2008/11/01(土) 17:19:13 .net

自分で作ればいいじゃない

251 ：デフォルトの名無しさん：2008/11/01(土) 18:02:03 .net

作れるなら作ってるさ

252 ：デフォルトの名無しさん：2008/11/01(土) 19:25:38 .net

dicon→Javaで生成したコードをメンテするよりも、Seasar2自体のコードをメンテしたほうが楽だと思われる。

253 ：デフォルトの名無しさん：2008/11/02(日) 16:04:21 .net

POJOのおかげで機能ではなくドメイン主体で継承作れるのはいいけど、
「なにがDIされるか」を知ってないと自分の書いたコードで
実行時になにが起こるかわかりにくいよねえ。継承ならまだ階層追えば
調べられるけど。

フレームワークのDIはほどほどにしてコード内で明示的に
委譲するようにしたい。でもspring利用しといて一部のクラスの生成だけ
サービス管理クラスを呼び出すのもわかりにくいし、難しいなあ

254 ：デフォルトの名無しさん：2008/11/03(月) 20:24:21 .net

>>253
ドメイン主体で継承とか。。
DIを良くわかってないようだな。
勉強し直してきた方がいいぞ

255 ：デフォルトの名無しさん：2008/11/03(月) 21:33:33 .net

>>254
君こそ勉強し直した方がいいぞ。DI以前にOOもな。

256 ：デフォルトの名無しさん：2008/11/03(月) 21:41:05 .net

タイプセーフを壊す過度なDIは不毛。
Guiceみたいな形式が一番スマートだと思う。

257 ：デフォルトの名無しさん：2008/11/03(月) 21:52:57 .net

253はいろいろ分かってなさそう

258 ：デフォルトの名無しさん：2008/11/03(月) 23:07:13 .net

>>253と>>256は同一人物っぽいな
タイプセーフを壊す過度なDIってw

259 ：デフォルトの名無しさん：2008/11/04(火) 19:41:26 .net

コンパイルするときはキャストとDIは別問題だし
注入する実装クラスが違ってたらコンテナが起動時に教えてくれるから
DIでタイプセーフ云々を問題視したことないんだが

260 ：デフォルトの名無しさん：2008/11/04(火) 23:30:27 .net

>>256
>タイプセーフを壊す過度なDIは不毛。
あんたはきっと実装に依存しすぎだと思う

261 ：デフォルトの名無しさん：2008/11/05(水) 00:01:17 .net

>>253の一段落目はその通りだと思うんだけどおかしいの？

262 ：デフォルトの名無しさん：2008/11/05(水) 00:52:35 .net

253だけど継承にしたって結局フレームワーク側がどうやって
継承元のメソッドを呼び出してるかは継承関係追っかけるだけじゃ
わからないから、DIも継承も関係ないや、と思った。まる。

263 ：デフォルトの名無しさん：2008/11/05(水) 23:23:27 .net

>>253
そりゃあんましイミないけど
気持ちは分かる

264 ：デフォルトの名無しさん：2008/11/06(木) 02:10:35 .net

>>253
>実行時になにが起こるかわかりにくいよねえ。

そもそもDependency Injectionというのは
「分からないでもいい」という粗結合を実現するためのもの。
呼び出し側はインターフェースだけを知っていればよい。
理想論ではあるけれども。

おそらく実装に過度に依存したコードを書いているんだろうなと思う。

265 ：デフォルトの名無しさん：2008/11/06(木) 05:30:53 .net

いやあ、デバッグの時に処理が追いにくいのがなんかなあって。
フレームワークのドキュメント調べてる時間で自分で書いた方が
早かったじゃんって思ったり。フレームワークの全機能使う訳じゃ
ないからさ。

266 ：デフォルトの名無しさん：2008/11/07(金) 00:43:44 .net

>>265
DIコンテナに限らない話だな

267 ：デフォルトの名無しさん：2008/11/08(土) 16:22:02 .net

技術的な話として便利かどうかと言えば明らかに便利
ただし、便利なら採用できるかといえば、それは次元の違う話
それだけ

268 ：デフォルトの名無しさん：2008/11/08(土) 18:56:25 .net

まぁでもSpringやSeasar2採用してるプロジェクト多いでしょ
と思ったら1割くらいか…

269 ：デフォルトの名無しさん：2008/11/08(土) 19:07:59 .net

DI支持派の主張で疑問なのは、

インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
そこでDI登場、と素っ飛ぶところ。

DIという考えが生まれるよりも遥か昔から、プログラマはインタフェースと実装を分離していたわけだが。

270 ：デフォルトの名無しさん：2008/11/08(土) 19:43:28 .net

それやってる奴って多分DI使ってる奴の100分の1以下だろ
だったら俺は昔からMVCに分けてたとかORマッピングやってたとかなっちゃうぜ

271 ：デフォルトの名無しさん：2008/11/08(土) 19:49:21 .net

昔からインタフェースと実装の分離をしているような奴なら、
自前のサービスロケータやDIコンテナモドキも作っているわけで。

だったら、そこでDI登場、と素っ飛んでしまっても何も
問題は無いと思う。

272 ：デフォルトの名無しさん：2008/11/08(土) 19:53:27 .net

俺はJavaなんて登場する前から仮想マシンを作って型に厳格な言語を構想していたが

273 ：デフォルトの名無しさん：2008/11/08(土) 21:43:11 .net

>>269
>インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
この｢インタフェースと実装の分離｣を聞きながら、
｢はあ？その理想論をどーやって現場で使えっつうんだよ！！｣
って思ってたところに
>そこでDI登場、と素っ飛ぶところ
DIが出てきて、
｢あーなるほどね、そーやるのね｣
って感じでナットクされたってこと。

インターフェイスとインプリメンテーション
みたいに
理論と実践をやってみせたのがDI。

274 ：デフォルトの名無しさん：2008/11/09(日) 06:08:42 .net

>>インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
>この｢インタフェースと実装の分離｣を聞きながら、
>｢はあ？その理想論をどーやって現場で使えっつうんだよ！！｣
>って思ってたところに

そういう人のための道具ということでよろしいですか？

275 ：デフォルトの名無しさん：2008/11/09(日) 12:29:57 .net

>>269
それまではService Locatorをつかってた。
昔のEJBとかね。
だから、最初はDIじゃなくてInversion of Control（制御の反転）コンテナとか軽量コンテナとか呼ばれてたんだよ。

276 ：デフォルトの名無しさん：2008/11/09(日) 12:42:13 .net

DIって自動テストツールを使った、単体テストの時めちゃくちゃ便利
むしろDIが無いと出来ないといってもいいな

277 ：デフォルトの名無しさん：2008/11/09(日) 15:36:38 .net

>>274
お前は独自フレームワーク(笑)でも作って一人で頑張って

278 ：269：2008/11/09(日) 20:25:58 .net

>>275
流石にファウラーの記事くらいは読んで言ってるよ。日本語訳もあるんだし

そもそもファウラー自身がメリットデメリットの話を書いているのに
素人が何の検討もなしに流行に乗っているだけという感じが。

巷が騒がしいから俺も遊んでみる→なんかコード書かなくて楽じゃね？→DIﾜｼｮｰｲ
という狂宴

279 ：デフォルトの名無しさん：2008/11/09(日) 21:11:19 .net

>>275
なんだ「自分は分かってる」君か。
臭いよ。

280 ：デフォルトの名無しさん：2008/11/10(月) 00:36:54 .net

ループの御燗

281 ：デフォルトの名無しさん：2008/11/10(月) 19:44:31 .net

めんどくせー。
AOPが簡単にできるだけで良いじゃねーか。

282 ：デフォルトの名無しさん：2008/11/11(火) 20:30:12 .net

半端に知ってる人が詰まっても知識の押し付けあいになっちゃうのですね。
あんたらばかぁ？

283 ：デフォルトの名無しさん：2008/11/11(火) 23:53:04 .net

人が詰まるw

284 ：デフォルトの名無しさん：2008/11/11(火) 23:57:24 .net

詰まらないスレだな。

285 ：デフォルトの名無しさん：2008/11/12(水) 00:27:39 .net

> DIコンテナって本当に便利か？

ひがちゃんに聞いてみれば？
たぶん「ホットデプロイが！！！」しか言わないと思うが。

286 ：デフォルトの名無しさん：2008/11/12(水) 00:29:46 .net

DIコンテナ要らないからホットデプロイだけくれよ。

287 ：デフォルトの名無しさん：2008/11/12(水) 00:32:52 .net

>>286
javarebel

288 ：デフォルトの名無しさん：2008/11/13(木) 17:00:25 .net

あると便利だけどねー

289 ：デフォルトの名無しさん：2008/11/22(土) 23:40:00 .net

俺みたいな古いＰＣしか持ってないと「軽量」ってことが、すごーく高価値なんだよね。
GlassFishやJBossやら動いちゃくれても、現実問題耐えられんのよｗ画面真っ白けにしてお休みしちょうし。
かと言ってxmlヘルへの逆行もごめんだしで、もうS2アディクティブですよ。

290 ：デフォルトの名無しさん：2008/11/24(月) 22:44:02 .net

>>289
J2EEコンテナ(GlassFish , JBoss vs Tomcat , jetty) と
フレームワークの違いを混ぜてないか?

DI コンテナは、フレームワーク(ライブラリ)であって、J2EE コンテナではないだろう。

291 ：デフォルトの名無しさん：2008/11/24(月) 22:50:43 .net

依存性注入(DI)は成功したか？
http://www.infoq.com/jp/news/2007/12/does-di-pay-off

この記事でも、DIはテストする際の有利さ(便利さ)が語られている。
(逆に言えば、それしかない、という意見も紹介されている)

292 ：デフォルトの名無しさん：2008/11/25(火) 01:12:27 .net

比較的導入が進んでる海外でも
この手のしょうもない議論がまだ繰り返されてるんだな。
OOPも初期は無駄な議論多かったよな。
今は自明だから議論が発生しないか、
あるいは分かってふりして黙ってるかの二択だが。

293 ：デフォルトの名無しさん：2008/11/27(木) 00:25:49 .net

だが実際問題、XMLは自動記述してくれないと嫌にならないか？結局というかRubyonRailのようなのが人気なのもJavaにはこんな問題もあるからだと思う。

294 ：デフォルトの名無しさん：2008/11/27(木) 01:30:13 .net

XML書くのが嫌ならguice使えばいいじゃん

295 ：デフォルトの名無しさん：2008/11/27(木) 02:19:09 .net

クラス図書くコストの1/3でクラス間の相関が記述出来る。
XML書くことの何が面倒なのか理解不能。

296 ：デフォルトの名無しさん：2008/11/27(木) 02:30:09 .net

実際XML地獄が深刻なので回避しようというのがトレンド

297 ：デフォルトの名無しさん：2008/11/27(木) 08:42:29 .net

今時のSeasar2プロダクトは規約で縛ってよっぽどのことがないとXML書かないけどな
SAStrutsとか

298 ：デフォルトの名無しさん：2008/11/27(木) 21:00:58 .net

Seasar２はいいな。確かに楽をさせてくれる。

299 ：デフォルトの名無しさん：2008/11/27(木) 21:18:39 .net

XMLヘルはHibernateやSpringやantのせいだろ。
あいつらは設定ファイルやデータファイルの域を逸脱してる。
web.xmlとstruts-config or faces-configだけなら大して難しくない。

300 ：デフォルトの名無しさん：2008/11/27(木) 23:07:03 .net

antを責めるのは筋違い

301 ：デフォルトの名無しさん：2008/11/28(金) 02:24:15 .net

>>299
つか、いまどきHibernateやらSpringやらもアノテーションだろ。

302 ：デフォルトの名無しさん：2008/11/28(金) 02:24:51 .net

>>300
antの、XMLで条件分岐や繰り返しや変数代入ってプログラム書かされるのはイヤになんない？

303 ：デフォルトの名無しさん：2008/11/28(金) 07:34:04 .net

XML地獄とか、いつの時代の話をしているんだよ、っという感はある。

304 ：デフォルトの名無しさん：2008/11/29(土) 09:15:28 .net

例え自動生成してたとしても、XML地獄がそこに存在してるんだよ。

305 ：デフォルトの名無しさん：2008/11/29(土) 09:26:57 .net

今はXML地獄ではなくて、アノテーション地獄だろ。

306 ：デフォルトの名無しさん：2008/11/29(土) 10:14:29 .net

ＸＭＬよりはマシっしょ、とつられてみる。

307 ：デフォルトの名無しさん：2008/11/29(土) 10:49:33 .net

アノテーションはその場に書いてある
XMLは違うファイルをいちいち開いてみなければならない

308 ：デフォルトの名無しさん：2008/11/29(土) 12:18:43 .net

Javaは複雑化し過ぎ。

309 ：デフォルトの名無しさん：2008/11/29(土) 16:30:43 .net

>>307
俺は逆だと思う。
XML地獄は、設定をすべて一箇所にまとめておける。
アノテーションは、ソース開いてみないとわからない。

トランザクションなどの挙動を変えるときに、アノテーションはソースコードを編集しないといけないが、
XMLの場合は、設定ファイルをいじるだけ。

DIコンテナが登場した初期の思想、「設定をソースから追い出す」を、アノテーションは壊してしまっていると思う。

※アノテーションがすべて悪いといっているわけではない

310 ：デフォルトの名無しさん：2008/11/29(土) 21:06:32 .net

>>309
言いたい事を俺はどこまで理解できるか覚束ないレベルなんだが、
たとえばO/Rマッピングが一切のSQL文の排除を理想とするなら、SQL文定義ファイルは邪道になっちゃうよね。
設計思想に理想はあるべきでも、ほどよく妥協させてくれる仕組みがあるのが一番と思うんだが。
設定を一切合切ソースから追い出すのに、時間をかけすぎるくらいなら少しあってもいいんじゃ。コードの形式美を追求するためだけに書く人間が人生を浪費させられるんじゃねｗ
最後のひと言※があるからわかっちゃもらえると思う。俺はもうXMLオンリーの世界に帰りたくないｗ
なーんて。

311 ：デフォルトの名無しさん：2008/11/30(日) 05:31:11 .net

eclipseみたいなIDEで編集してwarに固めてデプロイするのに
ソースいじったらコンパイルが必要とかはもうデメリットじゃないと思う。
ロジックの階層に応じてxmlなりアノテーションなりにまとめておければ
いいんじゃないの？設定ファイルにif文や変数いれたりアノテーションに
ビジネスロジック入れるようになるとやりすぎだと思う。
アノテーションでvalidateするのもvalidate処理が分散してちょっと嫌。

ORMはSQLを排除するんじゃなくて、速度を気にしないでいいところは
自動生成しちゃおうよって事だと思う。チューニングが必要なSQLだけ
外部ファイル書き出しでいいでしょ。つかみんなそうやってない？

312 ：デフォルトの名無しさん：2008/11/30(日) 13:46:22 .net

>>309
トランザクションの挙動みたいにアプリケーション横断なものは、それはそれでまとめておけばいいだろ。

313 ：デフォルトの名無しさん：2008/11/30(日) 15:05:23 .net

開発中の一覧性というなら、アノテーションの使用状況みればいい。
Seamみたいにカスタムアノテーションで共通設定をまとめれれば、設定を一箇所にまとめておける。
>>309 はアノテーションの使い方や、設定とアプリケーション構成記述の違いをわかってないだけではないか？

314 ：デフォルトの名無しさん：2008/11/30(日) 23:34:11 .net

派生開発や保守対応での既存ソースコード変更には厳格な手続きが必要で神経質になる客先が多いし、
アノテーションが散らばったソースコードを元にライブラリマイグレーションする事を考えると鬱になる。
5年前に良いと言われていたものを今見てみるとひどいだろ？ 5年後はどう？って感じるのも事実。

315 ：デフォルトの名無しさん：2008/12/01(月) 01:15:16 .net

で、それがXMLで設定なら解決できるというのは、能天気すぎやしないか？

316 ：デフォルトの名無しさん：2008/12/01(月) 07:21:26 .net

XMLで設定すれば解決できるなんて一言も言ってないが？

317 ：デフォルトの名無しさん：2008/12/04(木) 14:45:42 .net

>>291
>これは実際Strategyパターンなのです。 依存性注入は（私の見るところ）基本的にひとまとめに使われるStrategyパターンです。

同意。

318 ：デフォルトの名無しさん：2008/12/07(日) 17:52:43 .net

自動テストツール使わないなら、
DI使ってる意味が無いという事が分からない低能が多くて困る
流行ってるらしいからとかって理由だけでDI導入すんな！

319 ：デフォルトの名無しさん：2008/12/07(日) 18:25:47 .net

（　ﾟдﾟ）ﾎﾟｶｰﾝ

320 ：デフォルトの名無しさん：2008/12/07(日) 19:21:05 .net

まぁこんなもんだろ・・
一般のプログラマの能力なんて。

321 ：デフォルトの名無しさん：2008/12/07(日) 21:38:30 .net

318はどう見ても釣り

322 ：デフォルトの名無しさん：2008/12/07(日) 23:24:37 .net

全部のクラスに頑張ってログ出力書いたりログインチェック書いたりしたいんだろう

323 ：デフォルトの名無しさん：2008/12/07(日) 23:36:21 .net

>>322
それは、AOPの機能じゃん。
まぁ、AOPのためにDIがあるといってもいいのかもしれないけど。

324 ：デフォルトの名無しさん：2008/12/07(日) 23:47:49 .net

まぁ純粋にDIだけ使ってるのって無いよね
SeasaもSpringも
EJBは知らんけど

325 ：デフォルトの名無しさん：2008/12/08(月) 00:41:32 .net

今どきトレースログとか書くの？
サービスクラスだけじゃなくて？

326 ：デフォルトの名無しさん：2008/12/08(月) 01:51:40 .net

まあ、書くこともあるんじゃない？
俺は書かんけど。

327 ：デフォルトの名無しさん：2008/12/10(水) 12:40:10 .net

Ｎ１マッピングがめんどい。



めんどい。

328 ：デフォルトの名無しさん：2008/12/10(水) 15:43:35 .net

ログインチェックだってDI使わなくても
filter挟んだりベースクラスでやるよね。
全部のクラスにコピペする人なんてさすがに見たこと無い

329 ：デフォルトの名無しさん：2008/12/10(水) 17:26:32 .net

いやそれAOPでやることだし。DIじゃないよ

330 ：デフォルトの名無しさん：2008/12/10(水) 17:29:43 .net

>>328
filter は HttpServlet に依存するが、
DI にすることで、HttpServlet に依存しない環境でもログインチェックをすることができる。

たとえば、業務機能は、web 画面でもバッチでも Service クラス の execute() を実装する、
みたいな方針になっているとき。

バッチにも実行ユーザという概念があったときは、filter にせず DI でのやり方にすることで、
web画面でもバッチでも処理方式を統一することができる。

こうしておくと、web 画面の Service クラスのテストを、
Servlet コンテナを立ち上げずに JUnit 等から単体駆動することもできる。

331 ：デフォルトの名無しさん：2008/12/10(水) 18:18:38 .net

いやだから
DI以前だってベースクラスの一カ所に実装しておくから、
全クラスにコピペするような馬鹿は見たこと無いんだけど、
という事が言いたいんだけど理解してくり

332 ：デフォルトの名無しさん：2008/12/11(木) 01:58:01 .net

各メソッドを同じ前後処理でつつむときどうするんの？
AOPでできるとか言うが、AOPの実現手段としてDIがいいってことじゃねぇの？

333 ：デフォルトの名無しさん：2008/12/11(木) 02:02:12 .net

ぶっちゃけDIの中にあるPOJO信仰は異常だと思う。
EJB3.0はバランスがよくて好感が持てる。
DAOパターン信者の俺にJPAは少しきついが。

334 ：デフォルトの名無しさん：2008/12/11(木) 13:08:10 .net

>>331
処理対象クラスを柔軟に変えたり、
複数の横断的処理をそれぞれ別の対象クラス群に対して実装したいとき
多重継承が出来ないJavaでは限界がある
それを一気に解決出来るのがAOP
AOPがある今では、ベースクラスでそういう処理を実装するのはメンテナンス性が激しく下がるので
なるべく避けるようにしている

335 ：デフォルトの名無しさん：2008/12/11(木) 14:53:32 .net

AOPの便利さはわかったけどさ
AOP/DI以前でも>>322が言うように
>全部のクラスに頑張ってログ出力書いたりログインチェック書いたり
するやつがいたのか？って聞いてるんだけど

まあログ出力はステップ実行の無い昔は全部書いたけどさ

336 ：デフォルトの名無しさん：2008/12/11(木) 15:45:46 .net

>>335
ログインチェックしないのか？
サーブレットフィルタはAOPじゃないという話か？
運用のためのログ出力は不要か

337 ：デフォルトの名無しさん：2008/12/11(木) 17:34:54 .net

自分はやらないって奴に他の奴は殆どやってると説いても無駄なんじゃね？

338 ：デフォルトの名無しさん：2008/12/11(木) 17:37:25 .net

>>335
だからAOPが無い時代にベースクラスでそれをやろうとして
StrutsのActionクラスの継承づくしみたいなボロボロな形になったんだよw
それを今でも続けたいのならずっとそうしてれば？
一緒に仕事をする人は迷惑なだけだろうけど

339 ：デフォルトの名無しさん：2008/12/11(木) 17:51:31 .net

だからログインチェックはするし
ベースのexecute()でチェックしてからdoExecute()するだけだから
「Actionクラスの継承づくし」みたいなことにはならなかったし
（なったとしても別の問題だし）、Struts/2以降ならfilter/interceptorだし。

それをやらないなんて一度も言ってないだろ。
AOP/DI以前には全クラスにコピペなんてしてたのか？そんなやついないだろって
言ってるだけじゃないか。ま、どうでもいい話題だしどうでもよかとにあん

340 ：デフォルトの名無しさん：2008/12/11(木) 18:04:48 .net

ごめんfilterはログインチェックには使ってないわ
visitor系Actionがあるから
interceptorはAction毎にどれを使用するか指定できるけど

341 ：デフォルトの名無しさん：2008/12/11(木) 22:50:41 .net

てかfilterは典型的なAOPじゃん

342 ：デフォルトの名無しさん：2008/12/12(金) 00:40:43 .net

interceptorって、名前からしてAOPっぽいんだが

343 ：デフォルトの名無しさん：2008/12/12(金) 00:44:08 .net

interceptorインタフェイスはアスペクト指向だよねー

344 ：デフォルトの名無しさん：2008/12/17(水) 22:43:49 .net

AOP以前からAOPちっくな設計は普通のオブジェクト指向設計の一環としてやってたよ。
AOPを喧伝する人を見かけたら、マトモなOO設計出来ない人なんじゃないかと警戒する。

345 ：デフォルトの名無しさん：2008/12/18(木) 02:00:12 .net

なんだ、単なるOO自慢か。

346 ：デフォルトの名無しさん：2008/12/18(木) 08:24:22 .net

おや・・・酔った勢いで変な事書いた。ごめん。

347 ：デフォルトの名無しさん：2008/12/18(木) 08:35:56 .net

誰でも簡単に使える仕組みを作ってそれを宣伝したらアホってどんな感覚だよｗ
>>344は自分しか理解できない仕組みしか作れなかったと言ってるようなもんじゃん

348 ：デフォルトの名無しさん：2008/12/18(木) 08:51:04 .net

宣伝(せんでん)ではなくて喧伝(けんでん)ね。
「盛んに言いふらすこと。世間でやかましく言いたてること。」
酔った勢いとはいえ、申し訳ない。では！

349 ：デフォルトの名無しさん：2008/12/18(木) 10:22:59 .net

>>344
そういうオレオレシステムをフレームワークとして汎用的に提供したと思えばいいんじゃないか？
それすらも嫌なのなら、ご自慢のシステムwもフレームワーク化して世に出してみれば？

350 ：344：2008/12/18(木) 20:34:35 .net

>>346と>>348は俺。
AOP自体は別に否定してないよ。他の言語なら言語の仕組みとして提供されていたりもするし。

351 ：デフォルトの名無しさん：2008/12/19(金) 00:10:37 .net

>>291
以前から分散アプリサーバ系の構築をやってきた者からすると、
DIではじめて何かできるようになったというより、以前からできてたことを、
コンテナなしでテストできるようになって便利になったという感想になるのだと思う。

352 ：デフォルトの名無しさん：2009/03/10(火) 08:40:15 .net

>>352
(´･ω･｀)ｼｮﾎﾞｰﾝ
http://imepita.jp/20090124/089930

353 ：デフォルトの名無しさん：2009/04/19(日) 18:20:24 .net

こやつめｗ

354 ：デフォルトの名無しさん：2009/05/17(日) 14:07:47 .net

>>352
ｵﾔｽﾐ…
　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣

355 ：デフォルトの名無しさん：2009/05/17(日) 20:35:36 .net

開発が減ったのか
ものすごい過疎っぷりだな

356 ：デフォルトの名無しさん：2009/05/19(火) 18:08:08 .net

>>354
　Z
　 z
　　z
　＜⌒／ヽ-､_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣

357 ：デフォルトの名無しさん：2009/06/10(水) 18:10:00 .net

話すことがないんだなぁ
やっぱり製品作ってなんぼだな

358 ：デフォルトの名無しさん：2009/06/11(木) 08:51:30 .net

もうDIコンテナは当たり前になって、便利かどうかという話ではなくなってるからな。

359 ：デフォルトの名無しさん：2009/06/13(土) 04:22:18 .net

前にDIコンテナ使ってないプロジェクトで、開発用DBのトリガの引数が変更されて
本番DBとズレが生じて、仕方なく設定ファイルで読み込むクラスが変わるような
仕組みを作ったけど、常に必要ってわけじゃないな。

DIコンテナが喜ばれてるのはDI以外の部分だよね？
インスタンス管理とかトランザクション管理とか。

360 ：デフォルトの名無しさん：2009/06/13(土) 04:26:54 .net

DI以外の部分がDIに立脚してる件

361 ：デフォルトの名無しさん：2009/06/15(月) 02:15:29 .net

まあそうだけどさ

362 ：デフォルトの名無しさん：2009/07/17(金) 02:07:27 .net

結局、結論として、使った方がいいんですか？
使わない方がいいんですか？

そこんとこ教えて下さい。

363 ：デフォルトの名無しさん：2009/07/17(金) 02:17:18 .net

てめぇ、Springスレにも書き込んだ奴だな！

364 ：デフォルトの名無しさん：2009/07/17(金) 02:23:18 .net

はい、そうなんです。

流行ってるのはなんとなく分かるんですが、色んなサイト見ても何が
いいんだかさっぱり分からないんですよ。

フレームワークを使う事が目的になってる気がしてなりません。

それ以上の価値は、一体どこにあるんでしょう？？

365 ：デフォルトの名無しさん：2009/07/17(金) 02:28:09 .net

>>364
お前みたいな屑を兵隊として使えるようになると分かる

366 ：デフォルトの名無しさん：2009/07/17(金) 03:55:48 .net

あはは(笑)

まあそれは俺を使ってみてから言ってください(笑)

で、何がよくなるんですか？

367 ：デフォルトの名無しさん：2009/07/17(金) 04:38:35 .net

>>366
使えるかどうか判断してやるからスペック晒してみろ

368 ：デフォルトの名無しさん：2009/07/17(金) 05:52:51 .net

>>367
24歳 ♀
165センチ
45キロ
胸はC
顔は うちの総務の高山さんの若い頃に似てるそうです。

つかえますか？

369 ：デフォルトの名無しさん：2009/07/17(金) 06:28:27 .net

俺より背が高いから却下

370 ：デフォルトの名無しさん：2009/07/17(金) 12:18:41 .net

165cm/45kgでCカップってありえないと思う…

371 ：デフォルトの名無しさん：2009/07/17(金) 12:42:09 .net

>>367
まぁスペックなんて晒しても無駄ですよ。

そんなもん所詮こけ脅しにしかならないし。
実力とか応用力とか本当に使えるかどうかなんて実際に
仕事やらしてみるしかないんすよ。

人事なんてそんなもんだと思ってます。

372 ：デフォルトの名無しさん：2009/07/17(金) 12:48:58 .net

必要ないなら使うな。お前みたいな屑がblogでspringって
何するもん? 使う必要あんの?　フレームワークを使うことが
目的になってない? とか訳分からんチラ裏ばっか書くから
google先生がゴミばっか拾って汚染されていく。

373 ：デフォルトの名無しさん：2009/07/17(金) 13:05:42 .net

そんなもん書いてねーっすよ（笑）

必要ないなら使わないのは当然ですが、必要性をお教え頂きたいのです。

依存性の注入とか言いますが、結局は設定ファイルを簡単に読み込む
ためのものなんですか？
それを単純に文字列の値からオブジェクトにまでしたもの？？

374 ：デフォルトの名無しさん：2009/07/17(金) 14:07:17 .net

>>371
> 実力とか応用力とか本当に使えるかどうかなんて実際に
> 仕事やらしてみるしかないんすよ。

もう十分わかったよ。お前は使えないから消えろ。

375 ：デフォルトの名無しさん：2009/07/17(金) 14:21:13 .net

やだぴょーん（笑）

DI にこだわる意味を教えてもらうまではいるぴょーん

376 ：デフォルトの名無しさん：2009/07/17(金) 14:23:29 .net

ああもう夏休みか
ヌルーの季節ですな

377 ：デフォルトの名無しさん：2009/07/17(金) 14:27:05 .net

誰もこだわってないだろ。便利だから使ってるだけ。
何が便利かは人によって違う。
スパコンの計算能力が不要な人にスパコンの価値は理解できない。
DIも同じ。HelloWorldしか作ってないやつにDIの価値は理解できない。

378 ：デフォルトの名無しさん：2009/07/17(金) 14:45:19 .net

>>377
いや…なんて言うんですかね、つまり、特定の状況では DI コンテナ
なしで開発するよりも DI コンテナありで開発した方が効率がいいと
皆さん考えている訳ですよね？

その状況を知りたいのです。

どういう時ですか？？　もうプロジェクト全部？文句なしで？
だったら、次のプロジェクトで試しに使ってみようと思ってます。

379 ：デフォルトの名無しさん：2009/07/17(金) 15:03:10 .net

横から口を挟むが、DIそのものが便利かっていうと単体テストの時の
クラス入れ替えが便利になる程度。真正面からDIを勉強するとそういう説明ばっかで
あまりメリットが見えてこない。

みんなが便利に使ってるのはDIコンテナが持ってる機能で、例えばオブジェクトを
インジェクトするときにちょこっと書き換えてAOPでトランザクション管理やらせたり、
インスタンスの生成管理をコンテナにさせてソースの記述量が減ったり、そういうこと。

380 ：デフォルトの名無しさん：2009/07/17(金) 20:58:42 .net

目的がない奴が使っても意味ない
マネジメントできずに下手なPGになんでもインジェクションされて終わり

381 ：デフォルトの名無しさん：2009/07/17(金) 22:12:14 .net

ＤＩコンテナのデスクトップ番のようなものってありますか？

382 ：デフォルトの名無しさん：2009/07/17(金) 22:50:45 .net

springもseasarもデスクトップで使えるだろ。
guiceくらいが一番バランスいいかもしれんが。

383 ：デフォルトの名無しさん：2009/07/18(土) 00:01:22 .net

>>379
ふむふむ…。
なんだか複雑な事情ですね。

まぁ一回使ってみりゃ分かるんですかねぇ。
でも納期が８月末のプロジェクトなんで、ちょっと冒険する気に
ならないな…………。

384 ：デフォルトの名無しさん：2009/07/18(土) 00:35:27 .net

DIコンテナの利点が分からないってことは、利用しても使いこなせないって事。
だから、使わないほうがいいと思うよ。

385 ：デフォルトの名無しさん：2009/07/18(土) 00:56:15 .net

>>384
でもそれって「フレームワーク」の思想に反するんじゃないんですかね？

フレームワークの上に乗っかって作業してりゃあバカでも恩恵に与れる
のがフレームワークってもんなのでは？？

386 ：デフォルトの名無しさん：2009/07/18(土) 01:22:32 .net

馬鹿のまわりが恩恵に預かるのでは・・・

387 ：デフォルトの名無しさん：2009/07/18(土) 01:41:45 .net

どんなFWであっても、馬鹿がFWの上に乗っかって作業すると、平気でFWを無視し続けてグダグダになる法則。

388 ：デフォルトの名無しさん：2009/07/18(土) 02:38:43 .net

DIコンテナはフレームワークじゃない。その上でフレームワークを構築するんだよ。

389 ：デフォルトの名無しさん：2009/07/18(土) 04:04:54 .net

struts1.3 + spring2.5でdelegatingactionproxyで連携
しようと思っています。
この場合、DIするためにActionクラスにインスタンス変数を
持たなければならないのですが、この変数はスレッドセーフで
動作するのでしょうか？
しないならば、どのような解決策が考えられるでしょうか？
どなたかお知恵のある方、ご解答よろしくお願いします。

390 ：デフォルトの名無しさん：2009/07/18(土) 13:50:17 .net

>>389
Actionにステートフルなコンポーネントをインジェクトしたいと言うこと？
それは設計としてまずいような気がするが。

391 ：390：2009/07/18(土) 13:52:44 .net

あ、マルチポストだったのか...

392 ：389：2009/07/19(日) 00:30:18 .net

389です。マルチポストしてすみませんでした。
期日が迫っている作業なのであせっていました。
どうやら変数のスコープをプロトタイプにしたところ
hashCodeが異なる値で取得出来たので問題なさそうです。
ありがとうございました。

393 ：tor1.digineo.de：2009/08/17(月) 17:46:52 .net

自動焼人 ★　＝　自動保守 ◆KAWORUKOFI　＝　自動保守#K9K?_D[L

名言集　その２
『お前が規制系キャップ取れるか審査してやるよ』

http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/　ID:PVAf+dux0　＝　自動焼人 ★

> 36 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:31:30.02 ID:PVAf+dux0
> >>33
> キャップとコテハンの違いは何？

> 46 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:38:05.34 ID:PVAf+dux0
> >>45
> その回答では落ちるなｗ
> 答えは教えないがｗ

> 50 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:41:29.96 ID:PVAf+dux0
> Q.キャップとコテハンの違いは何？
> A.２ちゃんねるのボランティアの登録制度

> それがお前の答えかｗ

> 52 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:43:10.06 ID:PVAf+dux0
> まぁ、どうせ正解が出るわけもないし、次の問題。
> 君が思う面白いスレはどんなの？
----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください

394 ：デフォルトの名無しさん：2009/11/29(日) 18:23:57 .net

2009年に入ってからの過疎進行が半端ない

395 ：デフォルトの名無しさん：2010/01/03(日) 13:48:33 .net

>>394
おそらく、2010年も過疎進行でいくと思う。

396 ：デフォルトの名無しさん：2010/01/06(水) 04:21:39 .net

CDIの話題も出ないなんて

397 ：デフォルトの名無しさん：2010/01/06(水) 21:20:18 .net

ＧＤＩなら…

398 ：デフォルトの名無しさん：2010/01/07(木) 10:17:34 .net

三菱GDIエンジン

399 ：デフォルトの名無しさん：2010/01/07(木) 22:44:22 .net

>>396
WebBeansの頃から空気だろ

400 ：デフォルトの名無しさん：2010/01/09(土) 05:03:49 .net

CDIは、Tomcatとか各サーバーが標準装備するようになったら他のDIコンテナいらなくなりそう。
CDIのせいで一番最初に滅びるのはEJBだが。

401 ：デフォルトの名無しさん：2010/01/09(土) 08:54:16 .net

@TransactionAttributeはjavax.ejbだから滅びないよ

402 ：デフォルトの名無しさん：2010/01/09(土) 13:53:11 .net

>>400
CDIはTomcat6で今でも動いてるよ
JavaSEでも動いてSwingのコンポーネントに使えるサンプル付属してるくらい

403 ：デフォルトの名無しさん：2010/01/09(土) 14:42:50 .net

>>402
Tomcatが「標準装備」するようになったら、だろ
自分でライブラリ突っ込めば動くってんじゃ誰も使わんよ
俺はTomcatが標準装備してもCDIが流行るとは思わんけどな

404 ：デフォルトの名無しさん：2010/01/09(土) 15:33:46 .net

SpringもGuiceもSeasar2も標準装備はしてないよね？

405 ：デフォルトの名無しさん：2010/01/09(土) 15:47:34 .net

後発が同じ条件で流行ると思ってるのか？
EJB3だって流行ってないだろ？3.1だって流行らないよ
理由なきJavaEEアレルギーはまだまだ根強い

406 ：デフォルトの名無しさん：2010/01/09(土) 16:01:54 .net

EJBはサーブレットコンテナだけで動かないでしょ

407 ：デフォルトの名無しさん：2010/01/09(土) 16:11:06 .net

OpenEJB突っ込めば動く

408 ：デフォルトの名無しさん：2010/01/17(日) 11:42:25 .net

CDI手軽すぎ。でもトータルで見るとSeasarが勝る。

409 ：デフォルトの名無しさん：2010/01/18(月) 06:45:59 .net

学習コストでまける

410 ：デフォルトの名無しさん：2010/01/19(火) 17:07:41 .net

FFY最強！

411 ：デフォルトの名無しさん：2010/10/04(月) 04:35:34 .net

EE6でJavaは完成された感がある。
気に入らない人はまだまだ居そうだけど。

412 ：ななし。：2011/07/27(水) 19:32:41.18 .net

カ　オ　ス　ラ　ウ　ン　ジ　ゆ　る　せ　な　ぁ　い　ー

413 ：デフォルトの名無しさん：2011/10/26(水) 20:17:30.57 .net

仕様と実装を切り離す

414 ：デフォルトの名無しさん：2012/01/02(月) 07:03:20.58 .net

DIコンテナって2種類に分類されると思うんだ。以下あってる？

1. 型（inteface）に対するIOC(Guice)
2. 保有クラスに対するIOC(Spring)

(1)はinterfaceの保有クラスを区別せず1種類の実装が提供される。
(2)はinterfaceの保有クラスによって実装クラスが違う可能性がある。

415 ：デフォルトの名無しさん：2012/01/02(月) 07:11:26.86 .net

たとえば以下のような例の場合、
Guice系の場合にはインターフェースに対する実装の提供を１つだけ書いて
全てのIServiceに同じ実装が渡される。
Spring系の場合にはインターフェースに対する実装の提供を
コンテナからHogeを生成した場合、Mogeを、Kogeを生成した場合と3種書いて
保有クラス(Hoge,Moge,Koge)によってIServiceに違う実装が渡される。

class Hoge {
IService service;
}

class Moge {
IService service;
}

class Koge {
IService service;
}

416 ：デフォルトの名無しさん：2012/01/02(月) 10:23:11.80 .net

意味がよくわからん
guiceはintefaceと実装が一対一の関係「専用」のDIであるということを言ってる？
そういう意味なら違う
その場合は実装をアノテーションで指示するようになってる

417 ：デフォルトの名無しさん：2012/01/02(月) 13:10:41.09 .net

>>416
＞guiceはintefaceと実装が一対一の関係「専用」のDIであるということを言ってる？
うん、そういうこと。@Namedを使う抜け穴があるけど、それはguice系DIの思想的に
望ましくないと思うんだ。

intefaceと実装が一対一の関係だから実装を変更するときは
アプリケーション中でそのinterfaceに対する実装が一括で変更される。
そんなinterface単位の一括管理がguice系の方向性だと思うんだ。

418 ：デフォルトの名無しさん：2012/01/02(月) 13:15:58.26 .net

>>417
抜け穴ってｗ
一対一じゃ使い物になんないだろ
それ実装だけで開発するのと同じ事じゃんｗ

419 ：デフォルトの名無しさん：2012/01/02(月) 13:23:52.18 .net

続き

対してspringなどはinterfaceを使っているクラス単位で管理すると思うんだ。
例えば実装クラスを入れ替える場合、interfaceをフィールドに持っていたり
使っているクラス(bean)毎に設定を変更する。
抜け穴があるにしろ、基本的にDI箇所が増えるほど
設定が増える代わりに１つ１つ細かく指定できるのが利用クラス(bean)単位のDI

420 ：デフォルトの名無しさん：2012/01/02(月) 13:31:53.96 .net

>>418
説明がよくなかったかな。。。
例えばモックから完成クラスへ入れ替える、
あるいはMySQLからOracleDBに入れ替えるような、
そのインターフェースに対してアプリケーション中が一気に入れ替える
リソースの変更的な入れ替えのためにはGuiceは向いてるけど、

Buttonインターフェースに対してGreenButton, RedButtton, BlueButton
どれかを生成するストラテジーパターンみたいなものには向いていなくて、
仮にそれをするならわざわざIGreenButton, IRedButton, IBlueButtonみたいに
別々のインターフェースを作るのがGuice系の正しい使い方なんじゃないかな？

421 ：デフォルトの名無しさん：2012/01/02(月) 13:37:47.57 .net

>>420
いやーアノテーションでやるでしょそれは
IGreenButton等々はかなりまずいスタイルだよね・・・
インターフェイスに対してプログラミングするスタイルを完全にスポイルしちゃう
springはよく知らないけど、
あるinterfaceに対するデフォルトのバインディングを指定することもできないの？

422 ：デフォルトの名無しさん：2012/01/02(月) 13:48:16.33 .net

すると単なるIoCのFactoryクラス、つまりinterfaceなんか別に必須ではなくて
注入される側のクラスから見えないだけのFactoryクラスとして側面をもつのが
spring系DIで、

interface必須でinterfaceによる固い設計、実装クラス一括管理が
guice系DIの特徴に見えると思います。

423 ：デフォルトの名無しさん：2012/01/02(月) 13:59:52.82 .net

＞あるinterfaceに対するデフォルトのバインディングを指定すること
Guiceにとってはこちらが「基本」ですが、
Springにとっては「そういうのもできる」という立場ではないかと。

逆にGuiceで@Namedを使うようなパターンに対しては
Springにとってはこちらが「基本」ですが、
Guiceにとっては「そういうのもできる」という立場ではないでしょうか。

424 ：デフォルトの名無しさん：2012/01/03(火) 10:54:33.00 .net

DIはユニットテストのモック差し替えぐらいにしか使えないという記事を読んで、
やはりそういう用途にDIの概念が特化するならば、Guiceの@Namedみたいなiocコンテナ
の使い方はDIとは別の概念として切り分けられるべきではないかなと思た。

425 ：デフォルトの名無しさん：2012/01/03(火) 13:32:47.27 .net

DIよりもAOPがメインだよな
DIコンテナの用途って

426 ：デフォルトの名無しさん：2012/01/03(火) 16:35:15.29 .net

DIの方がメインでは？

427 ：デフォルトの名無しさん：2012/01/03(火) 23:14:35.03 .net

俺もあくまでDIの方がメインだと思う。

428 ：デフォルトの名無しさん：2012/01/04(水) 08:38:37.47 .net

実装の切り離し以外の役割を背負いすぎてるのが
学習時の混乱をもたらしてると思う

DIコンテナっぽいものをJavassistの練習で作ろうとしたところ
DIってどうあるべきだ？と考え出したところで停滞してしまったｗ

429 ：デフォルトの名無しさん：2012/01/22(日) 19:01:48.77 .net

やっぱDIコンテナ使う人って、とりあえずなんかクラス作るときは
例外なしにインタフェースかぶせとくもんなの？

今のプロジェクトはそうなってるけど、ユニットテストもないし
実装もすべて一個なんだから、もう密結合でもよくね？って気がすごくしてるんだけど

430 ：デフォルトの名無しさん：2012/01/22(日) 19:38:29.82 .net

そりゃ、ただの思い込みor実装上(AOPの方式とか)の制約じゃねーの？

俺は本当にプロバイダーモデルが必要な所しかInterfaceの分離はしないし、
テストに関しては黒魔術で対応してる。

431 ：デフォルトの名無しさん：2012/01/23(月) 14:44:29.86 .net

>>429
自分はいわゆるコントローラ(サービス)クラスとかDaoクラスであれば、
最初は実装クラスが1つしかなくても、例外なくインターフェースかぶせておくようにしている。

あとから、実装クラスを変えたくなった時や複数のバリエーションの実装クラスを作りたくなったとき、
context.xml で切り替えるだけで、プログラムを修正しないですむので、
プロジェクトの終盤で大きな変更を加えなければならなくなったときに、だいぶ助かったことがある。

例：
たとえば Dao で、インターフェース FooDao があったとして、
最初は iBatis で作っていたが(FooDaoIbatisImpl)、
一部独自に実装したくなった時は、FooDaoHogeImpl というように、FooDao を使った
別の実装クラスを作る。

context.xml で、bean id="fooDao" class=".." のところを FooDaoHogeImpl に変更すればいいので、
サービスオブジェクト側からは、変更を気にしなくて済む。

これでパフォーマンスチューニングをやったり、Dao の取得先を RDB から KVS とかに切り替えたりした。

432 ：デフォルトの名無しさん：2012/01/24(火) 19:58:47.06 .net

>やっぱDIコンテナ使う人って、とりあえずなんかクラス作るときは
>例外なしにインタフェースかぶせとくもんなの？

そうしてもいいぐらい粒の大きいクラスにしかDIしないこと

433 ：デフォルトの名無しさん：2012/01/25(水) 19:44:03.96 .net

何十とあるControllerやService、Daoに対して、例外無しに全てIFを用意するのか？、っとい疑問が生まれること自体は、まあ普通だと思う。

434 ：デフォルトの名無しさん：2012/02/16(木) 17:08:25.22 .net

必要なところをinterfaceに変えるのって手間掛かるか？
IDEのリファクタリング機能とか、無くても一旦コンパイルエラーにして
置換掛けていけばいいだけだし

必要になってからinterfaceにしても別によくね

435 ：デフォルトの名無しさん：2012/02/17(金) 10:16:39.50 .net

DIの利点ってやっぱテスト部分なのかね

436 ：デフォルトの名無しさん：2012/02/17(金) 20:52:25.87 .net

インジェクション設定が増えすぎるアンチパターンを懸念すると
テストの設計とDIでセットにするのが良いかもしれん

437 ：デフォルトの名無しさん：2012/02/23(木) 01:44:38.83 .net

interfaceを書きながら設計していく感じが多いかな
implするクラスも同時に書いていくと、設計が終わる頃にはスケルトン＋モックにもなるクラスができてる

438 ：デフォルトの名無しさん：2012/02/23(木) 13:50:41.31 .net

>何十とあるControllerやService、Daoに対して
なんで一対一でinterface用意する必要があるの…？
根本的にわかってないとしか言いようがない

439 ：デフォルトの名無しさん：2012/02/23(木) 21:53:45.88 .net

一対一にしないならDIやる意味なくない？

440 ：デフォルトの名無しさん：2012/02/23(木) 22:21:45.78 .net

インターフェイスをDIのタグとして使ってるってことかｗ

441 ：デフォルトの名無しさん：2012/02/24(金) 18:50:12.83 .net

DIって言葉も、なんかMVCと同じでぼくの使ってる最強のDIみたいなのが十人十色で意思疎通難しいし
もうNGワードにしたほうがいいんじゃないか

442 ：431：2012/02/26(日) 21:41:06.65 .net

>>439
開発当初は1対1しかないかもしれないけど、
あとから増える場合もあるので、そういった時には、インターフェースと実装クラスを分けておいてよかったと思うよ。

まぁ、これから作ろうとしているシステムが、使い捨て(寿命が短い)であまり変更を考慮しなくていい場合と、
ある程度長くなりそうな場合とで、手間とのトレードオフもあると思うけど。

443 ：デフォルトの名無しさん：2012/02/26(日) 21:53:56.03 .net

流れを誤読しとる？

444 ：デフォルトの名無しさん：2012/02/26(日) 22:05:10.19 .net

>>442
使い捨てがどうのともっともらしいことを言っているけど、
単に実装をIFを分離すべきポイントをちゃんと設計出来る能力が無いから
とりあえずなんでも分離しておく、っと言っているようにしか聞こえない。

そんなんで良いのか？

445 ：デフォルトの名無しさん：2012/02/27(月) 08:57:55.64 .net

DIのために一対一にするくらいならクラスを指定してDIすればいいだろってこと

446 ：431：2012/02/27(月) 15:49:00.65 .net

>>444
そう言われると反論できない。
突貫工事が多いから、とりあえず *Dao と *Service は
インターフェースと実装クラスに分けとけ、というルールを決めて、
開発に着手していたことは多かったな。

いちいち
・こういうケースは分離しましょう
・こういうケースは分離しなくていいです
というルールを考えている余裕がなかったので。

447 ：デフォルトの名無しさん：2012/02/27(月) 16:39:07.27 .net

そういう機械的な設計でいいと思うけどね。
堅実というか無難というか。

448 ：デフォルトの名無しさん：2012/02/27(月) 19:59:53.91 .net

実装クラスでメソッド追加した際に
インターフェイス側に宣言コピペするだけだしな

ファイル分けるもの面倒臭い
public interface A {
　　void f();
　　public static class Imp implements A {
　　　　public void f(){}
　　}
}

449 ：デフォルトの名無しさん：2012/02/27(月) 23:02:03.47 .net

なんかよくわからんなー
DIとなんの関係がある話なのかすらよくわかんない
Cのプロトタイプ宣言の話聞いてるみたいだ

450 ：デフォルトの名無しさん：2012/02/27(月) 23:09:58.39 .net

DIで注入される側
FooServiceImplならFooService型の定義になってて
BarServiceImplならBarService型の定義…みたいなことやってるってこと言ってるの？

451 ：デフォルトの名無しさん：2012/02/27(月) 23:15:39.88 .net

いや例がよくないｗごめん

452 ：デフォルトの名無しさん：2012/02/27(月) 23:18:58.00 .net

もうDaoでインターフェイスを分離する意味ないだろ
昔ならモックに差し替えるのに必要だったが

453 ：デフォルトの名無しさん：2012/02/28(火) 23:46:53.79 .net

intra-martの人達ってまだS2押してんの？

454 ：デフォルトの名無しさん：2012/04/19(木) 00:58:00.99 .net

>>140
>>351
>>444
話が合いそうだ

・直列化とビルダーパターン使うべきポイント
・マクロやジェネレータ使えばいいんじゃね？ってポイント
・なぜプログラムの修正をそんなに怖がる？ってポイント
・なぜファクトリの数行を面倒臭がる？（コード書けば言語解析による依存関係調査が可能だし、可読性も高まるのに）

って、結構どうでもいいところでDI使ってる人が沢山いる。

結局、普通のオブジェクト指向に対するシンタックスシュガーに過ぎないので、
経験のない人間が下手に使うと、どう再利用すればいいのか分からない、ゴミ山のような小さいクラス群と
環境によって内容が違う定義ファイルに道を迷わされる。。。

労働集約型産業やりたいのなら、COBOLとか実は良い言語だぜ？

455 ：デフォルトの名無しさん：2012/08/18(土) 05:07:00.19 .net

DIコンテナ使ってるのに結局ダウンキャストしてるとか、
それを避けるために（？）インターフェースと実装を１：１にして、同時にメンテしていくとか
そんな使われ方をしている所にしか出会ったことがないんで、考察が足りないかもしれないけど

DIコンテナって、上手く使えば便利なのは分かるんだけど、
publicメソッドの一つも足すことができないし、拡張性が落ちる気がするんだよね。
上の例みたいに、インターフェースと実装を１：１にすればできるけど、
その状況って単に、DIコンテナ使いたいからインターフェースと実装を分離してる感じになっちゃってるし、きもい。

作って終わりならいいけど、拡張をしていく可能性を残すなら、
そう簡単に導入できるものじゃない気がするんだよなぁ。

456 ：デフォルトの名無しさん：2013/02/08(金) 12:54:44.22 .net

DBfluteだのJBossだのJava界隈はまともに動かなかったりやる事増やしたりするゴミばっかだな

457 ：デフォルトの名無しさん：2013/02/08(金) 13:10:11.56 .net

http://event.seasarfoundation.org/sc2009white/viewAttachment.do?_pageName_=Session&_fileName_=sc2009white_s406_4_hot.pdf

これ読んでると色々馬鹿馬鹿しくなるね

458 ：デフォルトの名無しさん：2013/02/24(日) 16:07:14.97 .net

DIってsetter使えば要らないよね？
AOP目的で使ってる人いるみたいだけど、ならsetter+AOPで良くてDI不要じゃん

459 ：デフォルトの名無しさん：2013/02/24(日) 16:40:11.43 .net

DIすることとDIコンテナを使うことは区別するべきだと思う。

「setter使えば」が何を意味しているのかイマイチ判然としないけれども、setter使って
サービス等の実装オブジェクトをセットするという意味ならそれは他でもないDIだと思う。

DI自体はDIコンテナの使用の有無に関わらず有用な設計パターンの一つだと思うよ。

あとはブートストラップに実装のsetを列挙するかそれともDIコンテナ使うかの、注入作業
の実装方法の違いに過ぎないと思う。
注入するものとされるものが増えてきて、autowireなど規約による自動注入の類を使い
始めるとDIコンテナも便利だと思う。

460 ：457：2013/02/24(日) 20:24:51.85 .net

理解が深まりましたm(__)m

461 ：デフォルトの名無しさん：2013/02/24(日) 20:25:24.35 .net

457 -> 458

462 ：デフォルトの名無しさん：2013/12/28(土) 23:07:01.79 .net

うん

463 ：デフォルトの名無しさん：2014/03/02(日) 07:19:45.70 .net

DIでインジェクションするクラスってさ
基本的にシングルトンになると思ってるんだけど
あってる？

464 ：デフォルトの名無しさん：2014/03/05(水) 21:59:28.30 .net

>>463
何で？親インスタンス1に対して子インスタンス一つ出来るよね？

465 ：デフォルトの名無しさん：2014/03/06(木) 20:13:38.55 .net

その親インスタンスも一個でしょ？

466 ：デフォルトの名無しさん：2014/03/06(木) 20:28:00.99 .net

謎が深まりましたm(__)m

467 ：デフォルトの名無しさん：2014/03/06(木) 22:54:00.97 .net

たいていのDIの実装が、シングルトンをデフォルトにしているっていうだけの話ではなくて？

インスタンス管理がHTTPコンテキストのものだと、シングルトンに見えて実際はDynamic Proxyが
インジェクションされていて、本当の処理はHTTPコンテキストに格納された個々のインスタンスへ
デリゲートされている、なんてものもあるし。

468 ：デフォルトの名無しさん：2014/03/15(土) 12:31:18.68 ID:4evGY2gy.net

jmockit使えるようになってからは、主だったビジネスロジック部分でのDIはなくてもいいんじゃないかという結論に辿り着いた。
もちろん全部不要って意味じゃないけど、自前でnewすることは怖いことじゃない。

なんていうか、今後を考えてもまず必要のないことが明確にわかるような、
意味のないDIの使い方をしているプロジェクト、多すぎると思う。

469 ：デフォルトの名無しさん：2014/03/15(土) 12:51:07.19 ID:eSop4WYi.net

普通はデータベース・ファイルIO・外部システム連携部やAPI等をインターフェースにして
単体テスト時はモック、動作時にはDIで実装クラス注入というパターンだな

勘違いした人が全てのクラスに対してインターフェースを用意してDIとかやり始めると、
複雑度が跳ね上がって困ったことになる

470 ：デフォルトの名無しさん：2014/03/18(火) 08:14:10.97 ID:tRXj2H8I.net

やっぱり使える場所ってかなり少ないはずなんだよな
その辺はマルチスレッドを使うときのパターンに近似していると思う

DIコンテナの開発元や布教者がむやみにあちこち使わせるような
悪質なチュートリアルや宣伝をしているのが原因ではないだろうか

471 ：デフォルトの名無しさん：2014/03/18(火) 11:02:39.52 ID:SyPosiOD.net

使える場所は限られるが、ありがちなWebアプリだと、
手続き的に何度も書かなきゃいけないとこはだいたいカバーできるから、
普及してるんだと思われる。

勿論、何でもかんでもDIでというのはおかしいが。

472 ：デフォルトの名無しさん：2014/09/21(日) 11:50:29.01 ID:QmbMYAkp.net

おちんぽインジェクション！

473 ：デフォルトの名無しさん：2014/11/04(火) 12:10:06.56 ID:tJPjGfpS.net

>>469
難易度って意味だと、
自動テストって何ですか、単体テストは画面から動かしました！
ってなのが蔓延ってて、
○○機能サービスってクラスに
viewの状態から、SQLIDを含んだ発行メソッドや、ユーティリティ以外の全メソッドが乗ってる

そんな現場だと、例外なく全てである
って言い切っちゃった方がすんなり行きそう
それが新しいルールだってことにして

474 ：デフォルトの名無しさん：2015/12/19(土) 10:22:39.99 ID:TihVvVxJ.net

プログラマはMacを使ってるってマジ？
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/

475 ：デフォルトの名無しさん：2015/12/19(土) 15:44:40.26 ID:HaKKFtRZ.net

どこの部分をポリモる必要があるかちゃんと線引きしておかないと、DI導入してもただうっとうしいだけになるんだよな。

476 ：デフォルトの名無しさん：2016/01/26(火) 21:19:13.12 ID:96cI6c2/.net

仕様がふわふわしてる時には自衛の為にDIしたほうがいい

477 ：デフォルトの名無しさん：2016/03/29(火) 08:59:52.53 ID:/c8bAcK4.net

サッカーブッシュ日本代表日程ぷあたん（しゅっちょうまいくろ教育長交代）春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ２４チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン（販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート

478 ：デフォルトの名無しさん：2016/04/29(金) 22:34:59.65 ID:h96wBy+l.net

Unityでdecoratorパターンしたい場合はどういう風に設定を書けばいいんでしょうか
例えばコードで書くとこんな感じです
var co = new UnityContainer();
co.RegisterType<ILogger, Logger>();
co.RegisterType<IFoo>(new InjectionFactory(
c => new LoggingFoo(new Foo(), c.Resolve<ILogger>()
));
これをコードではなく設定ファイルで定義したいです

479 ：デフォルトの名無しさん：2016/07/08(金) 23:15:32.94 ID:oeqNGrjL.net

39 仕様書無しさん 2016/07/08(金) 23:11:07.46
Oracle、Java EEから手を引く可能性も

http://s.news.mynavi.jp/news/2016/07/04/261/

480 ：デフォルトの名無しさん：2016/09/23(金) 00:09:39.76 ID:wN+HuPEq.net

そもそもClass定義自体がファクトリのはず
なのに何故、いちいちフレームワークの助けが必要なのか。

DIは今後の言語で言語仕様自体に組み込まれ
消えていくだろう

481 ：デフォルトの名無しさん：2016/09/23(金) 12:46:27.71 ID:pEruE6c3.net

汎化が過剰だからフレームワークの助けが必要になるんじゃないかと
コードを自動生成したほうがマシな気がする

482 ：デフォルトの名無しさん：2018/05/23(水) 23:01:01.60 ID:Au5e7VGg.net

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

6IEJF

483 ：デフォルトの名無しさん：2018/07/04(水) 23:07:25.92 ID:gFgZc5FG.net

9WT

484 ：デフォルトの名無しさん：2018/10/12(金) 17:13:29.26 ID:5jm0P0/q.net

保守