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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2008/08/20(水) 23:23:26
インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどｗ
2008/09/23(火) 12:17:25
>>179は
「業務システムに適用するスキルレベルを引き下げないと保守要員が確保しづらい」という話をしてるのに
なんで>>180では
「保守したきゃスキルあげてこい」って話になるのかな？なるのかな？
2008/09/23(火) 12:26:54
OOP以前に、>>175で振り落とされるような人間はまともな構造化分析も出来ないだろうし。

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

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

それが理解できないなら、煽りでなく、職業を変えた方が良いと思う。
2008/09/23(火) 12:43:56
DIのインフラを作ってしまえば後は誰が保守してもかまわんでしょ
初期設計にまともなプログラマが居れば良いだけ。
2008/09/23(火) 12:55:21
>>182
俺の言いたいこと全部言ってくれて助かったんだが、

＞それが理解できないなら、煽りでなく、職業を変えた方が良いと思う。
これ実践すると、日本のプログラマ人口は1/100以下になるよな。多分。
2008/09/23(火) 12:59:34
まあ理解力うんぬんより「OOP勉強するくらいなら業務知識仕入れるわ」な奴のが一般的だしな。
2008/09/23(火) 13:50:10
PGが業務知識云々を言い出すと負け犬みたいなイメージがあるな。
2008/09/23(火) 14:08:12
>>186
いや、それはむしろそっちの方が正しいだろ。

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

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

テクニカルな仕事がしたいのであれば、インフラ系、
製品開発、Web系、組込み系へいくべきだろう。
2008/09/23(火) 15:39:34
>>184
>これ実践すると、日本のプログラマ人口は1/100以下になるよな。多分。
でも残った人の仕事は逆に楽になっちゃう、みたいな。
2008/09/23(火) 15:45:40
ないない。
2008/09/23(火) 16:01:27
まあ、下の方の人間が多少減ったところで
結果として出る成果に違いは無いとも思うし、
居ても居なくても同じどころか、
むしろ居ない方が良い人間が居るのにも
同意はするが。

でも、矢面に立って無駄死にしてくれる人間が居ないと、
こっちにまで変なおはちが回ってくるので、
まあ、居ても良いよというか、そんなかんじかな。
2008/09/23(火) 21:45:03
漏れは普通(?)に「悪貨は良貨を駆逐する」と思うが。

業務知識も知らないよりは知っていた方がいいだろうけど、
それは最低限のエンジニアとしての力量があってから初めて役に立つのであって、
上（アーキテクトする人）の言う事も理解できんアフォが「業務知識」とか言うと胡散臭ぇ。
2008/09/23(火) 21:55:39
アーキテクトが「上」だとか、さらっと言っちゃう？
2008/09/23(火) 22:01:51
アーキテクトはむしろ「横」。
2008/09/23(火) 22:22:03
正直、PG程度に求められる業務知識なんて、
そんなたいしたもんじゃないけどな。
誰でもしばらくやっていれば身につく程度の内容で。

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

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

よく、転職情報とかにも業務知識がある人間が
不足しているみたいな事が書いてあるけど、
俺の感覚としては、本当に足りてないのは、
技術的なバックボーンを持って、意志決定できる
人間だと思うがな。
2008/09/23(火) 22:33:43
なんかスレ違いな話題が増えてきたけど、「業務知識」を言い出すＰＧは
信用しない方がいい、ってのは共通認識みたいだな。
2008/09/24(水) 11:24:48
そんな極論
修正してやる！
2008/09/24(水) 11:28:12
PGで優秀じゃなかったやつは大概ロクなSE/PMにならないけど
時々いるよね、顧客との折衝がうまくてSE向きの人とか、
人間関係調整するのがうまくてPM向きの人とか。
例え人差し指だけでキーボードを打ってても
2008/09/24(水) 11:29:02
ごめんスレとなんの関係もなかった
2008/09/24(水) 20:43:18
プログラムができないから、業務知識とか言い出す奴は困りものよね。

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

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

さらにスレ違いすまそ。
2008/09/24(水) 22:05:12
なんだこりゃ愚痴スレか。

偉そうにスレ違いな会話を続けるくらいだったらDIをもっと広める方法でも語ってくれよ。
業務知識とか言い出すPG（よほど恨みでもあるのか？）の説得方法とかさ。
2008/09/24(水) 22:15:02
DIコンテナ自体はもう十分コモディティ化していると思う。

コンテナ自体を布教したりDependency Injectionパターンを
どうこう語るよりも、DIを使ったプロダクトを盛り上げた方が
嬉しいんじゃないかな。
2008/09/25(木) 01:19:27
というより初期開発にアーキテクト役を置こうとしない組織をなんとかすべき。
いったんDIを無理矢理導入すれば、後は使い込むにつれ説明不要で依存し出す。
2008/09/25(木) 01:25:12
確かにキラーアプリがあると嬉しいところなんだが。

情熱と時間がないと無理よね。俺には無理。
2008/09/25(木) 01:34:19
>いったんDIを無理矢理導入すれば、後は使い込むにつれ説明不要で依存し出す。
無理。
オブジェクト指向言語使っても構造化以前の
スパゲティコード書くやついるでしょ。あれと同じ。

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

あなたが然るべき立場の人間で、現場でそれを強制するだけの発言力があれば話は別。
2008/09/25(木) 01:42:50
OO言語＝オブジェクト内グローバル変数の持てる言語
という導入から入っても俺は迷うことなくDIまで辿り着いたなぁ。
保守思考が高いか否かで、個人差が出るのかなと思ってる。
2008/09/27(土) 01:32:33
実際のところ、仕事で何か使ってる？

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

という印象。
少なくとも、チームリーダーがしっかりしてるレベルの部隊でないと
現状ではどちらも厳しいと思うのだが。
2008/09/27(土) 01:44:44
設定の外部化が善という宗教
記述量の削減が善という宗教
2008/09/27(土) 04:07:26
>>206
それくらいできない奴は、いなくなった方が楽になる
2008/09/27(土) 07:26:39
>>208
それは組織力のないチーム(=一匹狼の寄り合い所帯)の言い訳
2008/09/27(土) 08:15:02
それくらいもできなくて、できるようになろうとしない奴らは
それですむ仕事をすればいいのに、なんで開発者になるんだろうか？
2008/09/27(土) 09:33:43
まあダメダメSIer だと、良いプロジェクト == 儲かるプロジェクト == Hello World Javaモンキー１００匹突っ込めるプロジェクト
だったりするんで、実は心の奥底から生産性なんか求めてなかったりする。
組織力ってのも Javaモンキー１００匹集められるか否か、ただそれだけだったりもする。
2008/09/27(土) 10:18:41
なるほど、それに浸かりきったバカが自分のバカさすら忘れて
>>209みたいなことを言うんだね
2008/09/27(土) 15:50:54
なぜすぐ煽り合いになるのか？
2008/09/27(土) 16:14:50
だってここ2chだし
2008/09/27(土) 19:28:29
むしろ本当の少数精鋭チームならJava使わないだろもう
2008/09/27(土) 20:37:02
むしろ本当の少数精鋭チームならDI使わないだろもう
2008/09/27(土) 20:38:44
逆々
2008/09/27(土) 20:50:31
Javaを使っていないのであれば、DIを使っていなくてもおかしくは無いが
2008/09/27(土) 20:55:15
spring以外に選択肢が無いのが問題
s2はhackerのオモチャ
2008/09/27(土) 21:01:51
guiceは？
2008/09/27(土) 21:03:38
藁
2008/09/28(日) 18:56:38
http://d.hatena.ne.jp/higayasuo/20080928/1222594738
2008/09/28(日) 19:34:28
Seasar2は慣れればサクサクなのだろうがそこまでの道程は結構険しい

問題なのは、真剣に学習コストをかけて展開するほど
今後長持ちするとは思われていないところじゃないかな
2008/09/28(日) 19:36:44
一部のローカルグループのサークル活動に
人件費を裂くような馬鹿はいないだろ。
うちはWebBeansがJavaEEに載っかったら、
without EJBな連中とは決別する予定。
2008/09/28(日) 19:49:13
そのサークルの人、みんな飽きるのが早いからね…
仕事ではリスクが高くて採用できない
(請負で作っちゃって納品ﾊｲｻﾖﾅﾗなPJなら採用できるのはﾅｲｼｮ)
2008/09/28(日) 20:29:42
Javaはそういうのはまだマシな部類だと思うけどなー。
COBOLなんか大昔の極一部の俺流フレームワークが神扱いされてるから･･･。

それに比べればSeasar系はまだマシだろう。
2008/09/28(日) 20:40:46
タイミングと内容から言って本人による宣伝なのかなあ


キモ
2008/09/29(月) 02:30:39
>>224
without EJBっていつの時代だよ
2008/09/29(月) 20:12:09
>>226
自分より下を見てまだマシだ安心する訳ですね。
2008/09/29(月) 20:46:28
>>228
ロッド・ジョンソンは今でもwithout EJBだよ
2008/09/30(火) 00:56:51
声が大きいのはひが氏だろ・・
2008/09/30(火) 01:33:11
>>230
もうロッドのいうことを無条件に賛同してるやつはいないだろ。
2008/09/30(火) 01:55:47
とりあえずよりよいプログラムを目指してここで情報収集してる
少数派がいがみあってもしょうがない
234デフォルトの名無しさん
垢版 |
2008/10/02(木) 07:33:34
こんだけ盛り上がるってことはまだまだ微妙なんだろうな
seasarも全然さくさくじゃねーしなｗ
2008/10/19(日) 21:03:33
Springどこいったよｗ
236名無し募集中。。。
垢版 |
2008/10/20(月) 01:28:40
SAStrutsかなり最強だと思うけどなー
DIとは関係ない部分でだけど
2008/10/20(月) 03:18:26
DIと関係ある話してくれよ
238名無し募集中。。。
垢版 |
2008/10/20(月) 03:30:53
DIを意識させないようにしてあるって所でいいなってさ
2008/10/20(月) 06:56:59
SAStrutsはSeaserに依存しまくりでしょ？
SAStrutsをパクってコンテナに依存しないStruts拡張を作るのが吉。
2008/10/20(月) 07:14:32
Sersarに依存してたらなんか悪いことあるのか？
Strutsに依存してることはOKなのか？
2008/10/20(月) 07:47:49
本人が前にこういう事を言っていたけど。
ttp://d.hatena.ne.jp/higayasuo/20080613/1213326209
まあ、S2でいい人は別にSAStrutsで良いんじゃね。
2008/10/20(月) 07:53:13
いまやSpring死亡してS2浮上中だけどな
今はその時とは事情が全く違う
2008/10/20(月) 11:44:06
いやあのサポートポリシーはコミュニティが黙ってないだろうと思ったら
あっさり変更したじゃないか。springはまだまだ死亡しないだろ。
244デフォルトの名無しさん
垢版 |
2008/10/20(月) 13:24:25
よくわからんけど、プロダクトがコンテナに依存して
嬉しいことってあるの？
プロダクトを作る側ではなくて、使う側の話だけど。

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

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

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

T2はコンテナ非依存とか言ってるけどさ。
2008/10/20(月) 16:41:54
大事なことだから・・・・？
2008/10/20(月) 20:04:47
それこそ使う側だと選択肢が少ない方が脳を使わなくて済むと言う
メリットがあると言えなくもないが。

むしろ、作る側が非依存で切り替え可能だと、影響調査やバージョンの互換性
やらテスト項目がてんこ盛りで泣けてくるとだろうし。
2008/10/20(月) 20:59:50
>>244
なんで2回繰り返してんだ？

依存するとコンテナの機能をフルに使える。
それで使う側に有益な機能が実現されればメリットになる。
DB依存のSQLも同じだろ。
2008/10/20(月) 21:13:31
コンテナに依存して、その機能をフルに使うプロダクトを作るも良し。

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

コンテナに依存しているプロダクトを別のコンテナと使いたいので、
そのプロダクトのコピー版を作っても良し。
2008/11/01(土) 16:39:33
s2がやってるような処理は、プリプロセッサレベルで
dicon→javaのコード変換としてやってもらって、
後は普通にseasar2要らずでコンパイル→実行
みたいな枠組みは作れないのかなあ…
使う側としてはその方が嬉しいんだけどね。
プロダクトよりもseasar2の耐用年限を気にしないといけない今の状況だとチョット
2008/11/01(土) 17:19:13
自分で作ればいいじゃない
2008/11/01(土) 18:02:03
作れるなら作ってるさ
2008/11/01(土) 19:25:38
dicon→Javaで生成したコードをメンテするよりも、Seasar2自体のコードをメンテしたほうが楽だと思われる。
2008/11/02(日) 16:04:21
POJOのおかげで機能ではなくドメイン主体で継承作れるのはいいけど、
「なにがDIされるか」を知ってないと自分の書いたコードで
実行時になにが起こるかわかりにくいよねえ。継承ならまだ階層追えば
調べられるけど。

フレームワークのDIはほどほどにしてコード内で明示的に
委譲するようにしたい。でもspring利用しといて一部のクラスの生成だけ
サービス管理クラスを呼び出すのもわかりにくいし、難しいなあ
2008/11/03(月) 20:24:21
>>253
ドメイン主体で継承とか。。
DIを良くわかってないようだな。
勉強し直してきた方がいいぞ
2008/11/03(月) 21:33:33
>>254
君こそ勉強し直した方がいいぞ。DI以前にOOもな。
2008/11/03(月) 21:41:05
タイプセーフを壊す過度なDIは不毛。
Guiceみたいな形式が一番スマートだと思う。
2008/11/03(月) 21:52:57
253はいろいろ分かってなさそう
2008/11/03(月) 23:07:13
>>253と>>256は同一人物っぽいな
タイプセーフを壊す過度なDIってw
2008/11/04(火) 19:41:26
コンパイルするときはキャストとDIは別問題だし
注入する実装クラスが違ってたらコンテナが起動時に教えてくれるから
DIでタイプセーフ云々を問題視したことないんだが
2008/11/04(火) 23:30:27
>>256
>タイプセーフを壊す過度なDIは不毛。
あんたはきっと実装に依存しすぎだと思う
2008/11/05(水) 00:01:17
>>253の一段落目はその通りだと思うんだけどおかしいの？
2008/11/05(水) 00:52:35
253だけど継承にしたって結局フレームワーク側がどうやって
継承元のメソッドを呼び出してるかは継承関係追っかけるだけじゃ
わからないから、DIも継承も関係ないや、と思った。まる。

263デフォルトの名無しさん
垢版 |
2008/11/05(水) 23:23:27
>>253
そりゃあんましイミないけど
気持ちは分かる
2008/11/06(木) 02:10:35
>>253
>実行時になにが起こるかわかりにくいよねえ。

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

おそらく実装に過度に依存したコードを書いているんだろうなと思う。
2008/11/06(木) 05:30:53
いやあ、デバッグの時に処理が追いにくいのがなんかなあって。
フレームワークのドキュメント調べてる時間で自分で書いた方が
早かったじゃんって思ったり。フレームワークの全機能使う訳じゃ
ないからさ。
2008/11/07(金) 00:43:44
>>265
DIコンテナに限らない話だな
2008/11/08(土) 16:22:02
技術的な話として便利かどうかと言えば明らかに便利
ただし、便利なら採用できるかといえば、それは次元の違う話
それだけ
2008/11/08(土) 18:56:25
まぁでもSpringやSeasar2採用してるプロジェクト多いでしょ
と思ったら1割くらいか…
2008/11/08(土) 19:07:59
DI支持派の主張で疑問なのは、

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

DIという考えが生まれるよりも遥か昔から、プログラマはインタフェースと実装を分離していたわけだが。
2008/11/08(土) 19:43:28
それやってる奴って多分DI使ってる奴の100分の1以下だろ
だったら俺は昔からMVCに分けてたとかORマッピングやってたとかなっちゃうぜ
2008/11/08(土) 19:49:21
昔からインタフェースと実装の分離をしているような奴なら、
自前のサービスロケータやDIコンテナモドキも作っているわけで。

だったら、そこでDI登場、と素っ飛んでしまっても何も
問題は無いと思う。
2008/11/08(土) 19:53:27
俺はJavaなんて登場する前から仮想マシンを作って型に厳格な言語を構想していたが
273デフォルトの名無しさん
垢版 |
2008/11/08(土) 21:43:11
>>269
>インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
この｢インタフェースと実装の分離｣を聞きながら、
｢はあ？その理想論をどーやって現場で使えっつうんだよ！！｣
って思ってたところに
>そこでDI登場、と素っ飛ぶところ
DIが出てきて、
｢あーなるほどね、そーやるのね｣
って感じでナットクされたってこと。

インターフェイスとインプリメンテーション
みたいに
理論と実践をやってみせたのがDI。
2008/11/09(日) 06:08:42
>>インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
>この｢インタフェースと実装の分離｣を聞きながら、
>｢はあ？その理想論をどーやって現場で使えっつうんだよ！！｣
>って思ってたところに

そういう人のための道具ということでよろしいですか？
2008/11/09(日) 12:29:57
>>269
それまではService Locatorをつかってた。
昔のEJBとかね。
だから、最初はDIじゃなくてInversion of Control（制御の反転）コンテナとか軽量コンテナとか呼ばれてたんだよ。
2008/11/09(日) 12:42:13
DIって自動テストツールを使った、単体テストの時めちゃくちゃ便利
むしろDIが無いと出来ないといってもいいな
2008/11/09(日) 15:36:38
>>274
お前は独自フレームワーク(笑)でも作って一人で頑張って
278269
垢版 |
2008/11/09(日) 20:25:58
>>275
流石にファウラーの記事くらいは読んで言ってるよ。日本語訳もあるんだし

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

巷が騒がしいから俺も遊んでみる→なんかコード書かなくて楽じゃね？→DIﾜｼｮｰｲ
という狂宴
2008/11/09(日) 21:11:19
>>275
なんだ「自分は分かってる」君か。
臭いよ。
2008/11/10(月) 00:36:54
ループの御燗
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況