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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2008/08/20(水) 23:23:26
インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどｗ
73デフォルトの名無しさん
垢版 |
2008/09/02(火) 00:29:44
個人的なDIの欠点はデバッガでなければソースを追えないって点だな。
interfaceベースで作ってたら、当たり前の現象なんだが、IDEのパワーをないがしろにしてる。
それでもDI自体は分業に向いてると思うし、俺は好きだ。
2008/09/02(火) 01:30:45
原理主義者はDIとかアスペクト好きなんだよ
もうほんと、それだけ

問題は、Javaがそもそも原理主義的なコーディングに不向きなことと
現実世界(特にビジネスまわり)がちっとも原理主義に根差してないことが原因で、
DIから得られる現実的なメリットが、ほとんど実感できないくらい
小さくなってしまっていること
2008/09/02(火) 01:59:43
現実世界も整理すればそれなりにスッキリしてるんだが
現実を現実のまま処理しようとして
ステートフルな世界に走ろうとして失敗してる人が多数居る。

ところで原理主義って何？
76デフォルトの名無しさん
垢版 |
2008/09/02(火) 03:03:42
ジャヴァはブルーカラーからのラングエジじゃなかったか？
2008/09/02(火) 03:40:53
DIはログとかトランザクションの管理に便利。
共有リソースの管理に便利。
2008/09/02(火) 04:39:25
なんと言う後付けユーティリティ
2008/09/02(火) 04:53:57
なにか問題でも？
逆に、共有リソースの管理がスタティック変数でまかなえる場合や、ログ・トランザクションをそこまで徹底しない場合は、DIコンテナ不要。
2008/09/02(火) 04:54:48
ログ・トランザクションは徹底というか、単純なルールが適用できる場合にDIが有効か。
8169
垢版 |
2008/09/02(火) 09:21:14
>>72
ごめんね。俺が思ってた疎結合の話に
君が思うようなサービスクラスやアクションを
含んでいなかった。
そしてDIにたどり着く前の段階の前提なんだ。

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

>>72を説き伏せようとは思っていないから
けんか腰にならないでね。
2008/09/02(火) 09:30:42
>>73
同じ事がインターフェースを
たくさん使ったソースコード（非DI）を
新人さんが読んでいる時に起こっていた。

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

力技でもどうにかできるようにしたければ
インターフェース使わずに書くのも良いと思う。
どこで切るのかの問題かもしれないけど。
83デフォルトの名無しさん
垢版 |
2008/09/02(火) 12:15:15
つctrl+t
俺もDIは好かんけど
eclipseもまともに使えないヤツには無理
2008/09/02(火) 16:36:26
なんですとぉ！？
85デフォルトの名無しさん
垢版 |
2008/09/02(火) 23:56:13
POJOってどうよ。アレを実現するための設定も
面倒に感じるんだが。
2008/09/03(水) 00:43:13
>>85
あまりに漠然としすぎててどの話をしてるのか分からん。

>>68
ネストしたトランザクションがスマートに記述できない時点で
もう面倒だと思いますよ、俺は。
それでもなお俺様フレームワーク最高ですか？そうですか。
2008/09/03(水) 01:11:41
トランザクションのネストってどんなケース？
外側トランザクションの中に内トランザクションがいくつかあるの？
内トランザクション1がコミット成功して内トランザクション2で
失敗したらどうなるの？
2008/09/03(水) 01:32:12
内1のトランザクション状態を内2で引き継いで
内2で失敗した時点で内1もひっくるめてロールバックされる。
コミットが行われるのは外のトランザクションが成功した時。
2008/09/03(水) 01:37:24
外側で宣言してれば内側のコミットは無視されて、
内1だけ呼びたい時は内1のコミットをアテにして、
内1、内2って呼びたいときは内1の中に書いてあるトランザクション処理を
無視できるから楽ってこと？
2008/09/03(水) 22:57:52
>>85
POJO と abstract class タイプフレームワークの綱引きがあって、
睡眠不足で寝ぼけてると、見当違いのところに abstract class タイプのフレームワークを適応しちゃったりする。
使い分けは、きっちりやりたいね。
ちゃんと睡眠とって、すっきり脳味噌で POJO を書こう。
今大人気だから覚えといて損はないよ
91デフォルトの名無しさん
垢版 |
2008/09/04(木) 00:20:52
POJOはフレームワークに依存、
StrutsクラスはStrutsに依存。

おまえらバカなんじゃね？
2008/09/04(木) 00:35:08
意味不明
2008/09/04(木) 00:38:06
>>91
依存してるかどうかじゃなくて依存をコントロールできることが重要なのに、何言ってんだおまえは。
2008/09/04(木) 00:46:32
たかが Bean Builder に御大層な名前が付いただけ。
2008/09/04(木) 01:57:13
長くこの業界にいて思うこと。
構造化プログラミングの時だってごく少数の優秀な人は
わかりやすくて綺麗な構造化をしていた。OOPの時代になっても
優秀な人の割合は変わってない。凡人がソースを書くときの
汚さが、構造化の時よりちょっとマシになっただけ。
でもその恩恵はインターネットの普及により情報が得やすく
なったせいかもしれない。
2008/09/04(木) 02:20:31
根幹部分は自分で書いて、ビジネスロジックだけ構造化OOP使いに書かせるから問題なし。
DIなら上流PGの実装が間に合わない時はDAOの具体実装をダミーにしとくとか調整も出来るよ。
2008/09/04(木) 03:18:44
>>89
このケースに限ってはそう。

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

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

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

探せば情報が得られる分、スキルの格差はむしろ広がってるのでは。
2008/09/04(木) 05:21:34
>なぜ考えないのか。

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

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

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

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

2008/09/04(木) 15:02:30
宣言的トランザクションは実装としてAOPを利用しているけど、
特定のメソッドから特定のメソッドの間でトランザクションを定義することは
横断的な情報、つまりAOPじゃないよね
2008/09/04(木) 15:53:23
うんそう思う。
ただしトランザクションをどう実装するかはコードの本質ではない。
2008/09/05(金) 01:27:42
どこからどこまでをトランザクションの範囲にするかってことが
必ずしも本質的な処理とは思えないんだが・・・
むしろ「モデルの状態を元あった状態に戻す」ためのひとつの実装パターンに
すぎないのでは？
2008/09/05(金) 10:31:45
そうじゃなくて、少なくともこのメソッドのスコープ内は
トランザクション処理しなきゃならないとかそういう話。
2008/09/05(金) 23:02:14
>>103はだれにレスしてんだ？
2008/09/06(土) 01:42:18
オライリーのインターフェイス指向設計を読み終えた。
わりと良書だったが、悲しいかなDIの話題はなかった。
(チラッと名前だけ出る程度。)
代わりにサービスをルックアップするコードが記述されていた。

今時どうかと思った。
2008/09/06(土) 20:42:33
>>95
普通の人が書いた汚いコードなら、構造化プログラミングとかのほうがよっぽどマシ。
OOPわかってない奴が書いたOOPっぽいコードなんて、汚な過ぎて見てると吐きそうになるだろ？
2008/09/06(土) 20:52:30
>>106
なる。
ドメインオブジェクトに関わりの薄いロジックが入っていたり、
固有のクラスでしか行われない処理が基底クラスに入っていたり

ス○ー○ジッ○のソースはひどかった
2008/09/06(土) 21:30:18
スターロジック？
聞いたことねえや

> OOPわかってない奴が書いたOOPっぽいコード
ああ、見てるとイラッと来る
自分も一度は通った道ではあるものの
109デフォルトの名無しさん
垢版 |
2008/09/07(日) 00:55:05
Struts知ってる俺がS2Strutsを触ったが全然動かない・・・
おまいらコレすっと動いた？
2008/09/07(日) 02:25:30
激しくスレ違い
2008/09/07(日) 11:46:30
>>107
恨みでもあるの？
そこで名前を出す意味が分からないな
112デフォルトの名無しさん
垢版 |
2008/09/07(日) 21:13:24
>>109
ずっとうごいたけど
113デフォルトの名無しさん
垢版 |
2008/09/14(日) 21:08:26
DIって、フレームワークを提供する側や、業務パッケージを作成する場合なんか
には有効かもだけど、１から作るような業務アプリではメリット感じない。
大体、１から作るような業務アプリという時点で泥くさいことやらなきゃいけない
ケースが多いし、インターフェースが有効なケースもあんましない。
(パッケージ使用しない時点で、客は泥くさい対応を求めてくる。)
1インターフェースで1パターンだったら、密結合でも疎結合でもどっちゃでもいいん
じゃない。影響極少だし。

まぁ設計力の問題かもしれない。業務アプリでうまく交通整理できた具体例なんかが
あれば、ほんと具体的に教えてほしい。
2008/09/14(日) 21:11:59
>>113
その業務は未来永劫仕様が変らないの？
115デフォルトの名無しさん
垢版 |
2008/09/14(日) 21:15:24
こんなわかりやすくて便利なもんがこの評価か・・・VBerを思いだす
2008/09/14(日) 21:22:13
>>114
そんなことはない。ただ小変更の場合は実装クラス内の変更にとどまる
ことが多い。大きな変更の場合は、設計の根幹を揺るがすようなことが
ままある。実際客にとり、メリットあるのは、大きな変更のほうなん
だが、その場合は残念ながら、DIは無力だと思う。
117デフォルトの名無しさん
垢版 |
2008/09/14(日) 21:44:38
正直AOPやDIがJavaの限界に思う。
下位互換にこだわりすぎる言語の宿命だよ。
明らかに無理し過ぎてる。
2008/09/14(日) 22:02:49
>>115
今はそういうのはPHPerが担ってるよ
2008/09/14(日) 23:04:57
一から作るならGuiceあたり使っておけばいい。
JavaEEはJSF+Faceletsを使って、WebBeansは出たら採用する。
正直SpringだのS2だのへの投資は無駄な投資。
2008/09/14(日) 23:22:56
>>117
DIなんて実行時に今までやっていたことを設計時に限定する代わりに
設定ファイルで簡単に記述できるようにしただけだよね。
言語使用でサポートするとしたらどうなるのかな。
121デフォルトの名無しさん
垢版 |
2008/09/15(月) 07:00:32
>>113
に一票だなぁ。
>>114
とかは、微笑ましく思える。
2008/09/15(月) 15:50:28
業務自体の変更はDIの範疇じゃないと思うが、
業務の本体じゃない横断的な事象を切り出すには便利に使えると思うよ。
ただの道具として利用するレベルでも。
横断的関心事を業務の本体から切り離すってのはまあ、AOPの範疇かもしれんが。
2008/09/15(月) 15:56:50
業務プログラムがテンプレートメソッドパターンに落とせないのであれば、
インタフェースベースの設計をする価値はないだろうね。
2008/09/15(月) 18:19:23
？
2008/09/15(月) 18:23:01
なんらかの業務処理をプログラムに落とし込む必要があって、
それに対してインターフェイスを書かない状況ってのは、ちょっと分からないな。

そもそも、それって Java使う必要あんの？
LLの方が向いてない？
2008/09/15(月) 19:10:18
ソフトウェアカスタマイズなら割とある。
2008/09/15(月) 22:05:04
そりゃ、〜〜業務を1メソッドや1クラスにだらだら書いているなら、
DIなんて何の意味もないだろうさ。
2008/09/15(月) 22:53:41
何か頭の悪い誇張野郎が沸いてるな。
129デフォルトの名無しさん
垢版 |
2008/09/16(火) 00:12:09
AOPやDIで業務システム作ったけど大した恩恵は受けてない。画面や検索条件。業務ロジックの修正がほとんど。結局LLでやればよかったと思ってる
2008/09/16(火) 02:18:19
>>129
本質的な部分の修正だけですむのはDIの恩恵を受けてるんじゃないか？
2008/09/16(火) 02:39:07
>>130
なんでもDIのおかげにしたいんですね。
2008/09/16(火) 02:48:59
>>130
それ言うなら、どっちかっつうとAOPの恩恵なんじゃね？
2008/09/16(火) 20:40:32
>>130,132
それはMVCをきちっとわけてれば出来ることだし、
OO以前の構造化設計でもきちんと設計が出来ていればできること
2008/09/16(火) 21:24:30
その「きちんと」を楽にするためにOO言語なりツールがあるわけで。
「楽したい」と考えないエンジニアは碌なもんじゃないと思うんです。
2008/09/16(火) 23:27:14
別にDIとかAOPによって不可能だったことが可能になったわけじゃないんだから。
より楽な、より便利な使える道具ができたってだけのことだろう。
2008/09/17(水) 01:14:46
本質以外のことはやりたくないからどんどん外に出した。
外出ししたオブジェクトをルックアップするコードを書くのも面倒になった。
何使うかだけ書いといて、あとは外から勝手に注入してもらえば楽くね？

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

これがどういう意味を持つか分かる人以外には
どれだけ触っても全くの時間の無駄だ。
2008/09/17(水) 01:45:51
楽くね？
くねくね？
138デフォルトの名無しさん
垢版 |
2008/09/17(水) 05:05:33
DIって普通はリンカが自動的にやってることを、手動で設定してるようなイメージ。
139デフォルトの名無しさん
垢版 |
2008/09/17(水) 12:32:29
退化
2008/09/17(水) 12:41:16
DIで楽が出来るのはわかってる。学習コストとメリットを天秤にかけた時に
業務アプリで使うのはどうかって話だ。今のspring他の実装はまだ過渡期で、
5年後には設定方法やデファクトのDIツールすら変わってる可能性が
大いにある。Apache Torqueなんてまだ使ってるやついるか？
いたらゴメンね。でメインの開発者がとっくに退社してる場合、
今更Torqueなんてメンテし続けたくねーとか、Apache ECSなんて
jsp出てきた時点で終わってんだろ、とか思う訳じゃない。
それを繰り返したくない。ちょっとファクトリクラス書くのが
楽になる程度の使い方なら、後の人がすぐ追えるようにシンプルな
ファクトリを書いておいたいいんじゃないか、と悩んだ事は何度もある。

いい加減springなら平気だろと思って使ってるわけだけど
2008/09/17(水) 14:07:48
Guiceくらい便利に使って欲しいところだけど、俺の周囲じゃ正直無理だと思った。
設計思想というものが前提的に存在しない層とはJavaは相容れないな。
2008/09/17(水) 14:34:53
開発者の質が悪いからってのも、本末転倒な話だな。
むしろ、低レベルな開発者を排除すべきだと思うんだが。

優秀な人間だけ集めると、開発ペースがメチャメチャ速くなるぞ。
無駄なドキュメントは作らなくてすむし、くだらないバグも仕込まれないし。
2008/09/17(水) 14:37:24
そんなことが簡単に出来たら苦労はないわ
2008/09/17(水) 14:53:38
100人月とかの開発をやったこと無いんだろう
2008/09/17(水) 15:02:53
Guiceいいかもと思ってGuiceスレに行ったら泣けてきた。
あんまし使われとらんの？
2008/09/17(水) 17:15:04
日本人が作ってないからヲチネタが少ないだけ
2008/09/17(水) 21:51:04
>>143
そりゃ、簡単には出来ないよ。

>>144
普通の会社が100人月かけるところを、30人月とかでやってしまうってことだよ。
2008/09/17(水) 22:22:50
開発ペースが速くなるのは良いが、人的リスクはどうなるのかね？
少数精鋭だと事故や病気で欠員が出ると途端に回らなくなるが。
後メンテナンスにも「優秀な」人材が必要になったりしないよな？
ノウハウが属人化して「Aさんじゃないと判らない」なんてよく聞く死亡フラグだ。

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

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

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

なんて超アタリマエな事を偉そうに語ってすまん。
2008/09/17(水) 22:39:27
長いから1段目しか見てないが、
うちも少数精鋭で立て続けに二人居なくなって
あばばばばってなったよｗ
2008/09/17(水) 22:50:30
優秀な人間だけ30人も集められるわけがなかろう。
2008/09/17(水) 22:51:49
あいや上は無視してorz

まいずれにしても優秀な人間だけ集めるってのはやっぱり現実には無理がある。
優秀な人間は各プロジェクトに分散させるもんだからな。
152デフォルトの名無しさん
垢版 |
2008/09/17(水) 23:08:57
30人月って、3人x10ヶ月のことじゃないのか。
2008/09/17(水) 23:10:32
30人月だと普通は5人×6ヶ月くらいじゃね？
2008/09/17(水) 23:17:40
今の現場は人ばかりいてダラダラ1000人月は消化してるな。
プロジェクト管理？
決まってるじゃないか、エクセルだよ！
2008/09/18(木) 00:19:09
知らないうちにヘンなインスタンスと会話してたりするとコワイよなぁ・・・

DIコンテナってある意味、人間関係の希薄な現代社会みたい。
2008/09/18(木) 00:41:51
妹だと思ってお尻なでてたらお袋だった、みたいな？
2008/09/18(木) 00:52:58
>>148
欠員リスクはあるね。そこまで大きな仕事になると受けられないな。

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

あと、俺の主張は「無能は使うな」であって、「優秀な人だけでやれ」ではないよ。
2008/09/18(木) 11:03:38
それすらも難しいのが結構現実…
2008/09/18(木) 17:50:47
ホントホント

2chに書き込んでるような俺らみたいなヤカラでさえ、
より良い設計に興味があるだけマシで
普通のPGは会社引けたら知らんぷりだもんな
2008/09/18(木) 20:43:51
まあ中にはPGには余計な知恵をつけて欲しくないとかで
DIコンテナとかの話するだけで目の敵にするような奴もいるしな。

…それはそれで正しいのか？そうは思いたくないが。
2008/09/18(木) 20:56:26
作業者(制御構造を書くだけ一般PG)にまでDIなんて意識させるか？
DIなんて裏方だし、骨組み作る人間だけが意識してれば良いじゃん。
2008/09/18(木) 21:06:49
そしてさらにPGの二極化が進むのであった。
2008/09/18(木) 21:19:46
日本って人材に甘すぎるのか、分からない分からないを繰り返して
残業しまくって成果物がゼロに近い奴が首にならないんだよな。
しばしば年収を意識しちゃって鬱になるよｗ

>>160
費用対効果だわな。
DIはOJTの範囲外なのでちょっと投資する必要がある。
2008/09/19(金) 00:43:31
>>161
実装者が理解できてないままだと
interface 使わないコードを平気で持ってくるわけだが。
お前さんのレビューのコストがバカになんねえよ。
実例挙げて教育した方が絶対早い。
分からないやつは切り捨てたらいいから。
2008/09/19(金) 20:35:47
>>164
理解させずとも「規約違反」で片付ければいいだろ。

ガチガチの規約ずくめのプロジェクトなら
そもそもPGが勝手にinterfaceを作ることすら「規約違反」だしな。
2008/09/19(金) 20:46:29
クラスの追加が承認制というようなこともするけどね。
レイヤ構成と機能毎の箱だけ用意しておいて、後はそこに
処理を書いてください、みたいな。

馬鹿にしているとも思うけど、悲しいかな、そうしないと
最低限の品質を保てないということもある。
2008/09/19(金) 23:10:35
>>166
それやっちゃうと3000行のメソッドや10000行のクラスが湧いて出たりしない?
そうならないように適切に分割したクラスやインターフェース書いて渡すの?
でもそういうのが判断できるとこまで設計したら、
中身も自分で書いた方がはるかに少ない工数で作れるよね……。
2008/09/19(金) 23:48:26
3000行のメソッドや10000行のクラスはさすがに無い。
レイヤ、機能までをそれなりに分割したものを渡すけど、
それでなくても今時3000行のメソッドは無いだろう(ﾟдﾟ )？

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

工数というか効率に関しては、少数精鋭の方が良いのは勿論だけど、
1人で単位時間当たり1の成果を出すのではなく、10人かき集めて
単位時間当たり2の成果(効率は1/5)を求められることもある(´・ω・`)
2008/09/20(土) 11:51:27
優秀な人とそうでない人の差は生産性だけじゃない。
実際生産性自体は大きなな差はないこともある。
特に業務処理みたいなのの実装では。
しかし品質や保守性にはかなり差が出る。

業務処理とかじゃなくてもっと基盤よりの実装だったりして難度が高い部分だと
生産性にも品質にも保守性にもそれを使う側への影響にも大きな差がでる。
そもそも優秀じゃないと出来ないものもある。
2008/09/20(土) 12:27:40
>>168
1メソッド3000行はさすがに見たことないけど。

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

ちなみに10000行どころか70000行程度のクラスまでなら普通に見る。
VB.NETのForm継承クラスに業務処理まで突っ込んだやつ。
2008/09/20(土) 14:07:32
まじかよ
2008/09/20(土) 15:21:57
ま〜なんだ。
DIの有用さが理解出来ない奴は、これまでテストをきちんとやって来なかった奴だな
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況