【Java】DIコンテナって本当に便利か？
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2008/08/20(水) 23:23:26かなりめんどくなってんだけどｗ
0002デフォルトの名無しさん
2008/08/20(水) 23:42:55いまどきXML地獄なんてどのFWにも無いぞ
0003デフォルトの名無しさん
2008/08/22(金) 00:40:410004デフォルトの名無しさん
2008/08/22(金) 01:57:47Spring2.5からはアノテーションインジェックションが
使えるようになったからXML地獄じゃなくなったよ。
0005デフォルトの名無しさん
2008/08/22(金) 05:09:45インタフェース作っても、実装クラス一つしかなかったり。
結局、特定の組み合わせでしか動かなかったり。
0006デフォルトの名無しさん
2008/08/22(金) 10:44:210007デフォルトの名無しさん
2008/08/23(土) 15:43:06インターフェース書くのが嫌ってことなら、そっちの方が大問題だね
まあ、そもそも DI するのにインターフェース書かなきゃいけないってことは無い訳だが
脱線するが、
interface と abstract class は全く違うものなんだけど、分かってるつもりでいて、実は分かってないやつは非常に多い
>>1 もそんなとこだろう
abstract class は拘束、interface は主体的な宣言とか言ったらヒントになるか…
共通点は勿論あるんだが、設計においては、これは全く違う意味を持ってくる
それが分からんと、 interface の価値が見出せなくなったりするようだ
なんと言うか、interface を拘束の意味でしか理解していないとでも言うか…
それから、実装クラスが一つしかないと、端折って直接実装を呼びたくなったりするらしいが、
その点 DI は interface の旨味を再確認させてくれる。
0008デフォルトの名無しさん
2008/08/23(土) 23:57:34お前が interface と abstract class の違いをよく理解していないことだけはわかった
0009デフォルトの名無しさん
2008/08/24(日) 02:25:07どうやら何かを判ったつもりになってひとりで納得しているの図
0010デフォルトの名無しさん
2008/08/24(日) 10:08:27俺ぁ余計なクラス、設定が増えまくる事自体が問題だと思う
0011デフォルトの名無しさん
2008/08/24(日) 10:39:570012デフォルトの名無しさん
2008/08/24(日) 12:41:17実装しかないと、常に密結合状態じゃん
サービスの実装に
new InitialContext();
とか直接書いたりしないでしょ？それと同じ
後から何か処理を加えたいと思った場合、インターフェースがあれば最初の実装に手を加えなくても済むケースがあるでしょ？
実装しかないと、そいつにドンドン追加する羽目になりがち
下に何か加えることは出来るけど、上に被せられないし
それに、インターフェース守れば良いんだから、却って自由に書けると思うんだが
ただ DI に関して、設定が増えまくるのは確かに苦痛
そこでアノテーション
でもこれって、テストとリリースでどうやって分けんのかとか、ちょっと混乱しそうな気もする
ルール付け徹底すりゃいい話なんだろうけど
0013デフォルトの名無しさん
2008/08/24(日) 12:58:040014デフォルトの名無しさん
2008/08/24(日) 13:05:54クラス図書くより全然楽だし。
アノテーションの方が地獄っぽくないか？
組み合わせ変更するのに、なんでコンパイル必要なんだよ。
何のために interface 書いたのか分からん。
もっとも DI 嫌ってる人は、そんな瑣末なことなんてどうでもいいんだよ。
本当は疎結合の良さが分かってないだけ。
自分がなんで DI 好きになれないのか、それすら分かってない。
DI なんてどうでもいいから、疎結合に慣れろ。
慣れた結果、密結合で十分かつ適当な場合と
そうではない場合が分けられるようになればそれでいい。
0015デフォルトの名無しさん
2008/08/24(日) 13:18:46DI使ってても密結合になってる例はたくさんあるし。
0016デフォルトの名無しさん
2008/08/24(日) 13:36:21確かに
結局は分かってるか分かってないかに落ち着いてしまうのかな
シングルトン強制ギプスとか思っても、分かってりゃ必要に合わせてシングルトンで書くわけだし
ただAOPは捨てがたいな
AOPを捨てれないとDIも捨てられないw
0017デフォルトの名無しさん
2008/08/24(日) 13:48:19>>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メソッドを持っていれば何でもいい)
となるので、リスナーみたいなインターフェースはまとめて削減できそう。
001816
2008/08/24(日) 13:49:560019デフォルトの名無しさん
2008/08/24(日) 15:00:05確かに。でもそれを言い始めたらキリがないのでは。
0020デフォルトの名無しさん
2008/08/24(日) 16:40:09Seasarのことも思い出してください＞＜
0021デフォルトの名無しさん
2008/08/24(日) 18:38:550022デフォルトの名無しさん
2008/08/24(日) 19:30:530023デフォルトの名無しさん
2008/08/24(日) 19:42:31「それがどうした、知らないお前が勉強不足」と開き直れるほど枯れた技術ではないし。
開発現場が全速力で短距離を走り抜けるための技術というか…
と感じながらも全速力で走らメシが食えないから使うんだけどな。
0024デフォルトの名無しさん
2008/08/24(日) 20:46:26いったいどんなコード書いてんだ？
ぶっちゃけ特定の「なんちゃら」への依存が弱まることはあっても、強くなるケースっていまいち想定できないな。
モジュール間の結合度を弱めてテストをし易くするのが利点と思いきや、”強く依存” とはこれ如何に？
もしそれでモデルにフレームワークへの依存が入り込んでるんなら、実装に問題があると思ったほうが良いのでは？
内製だったらモデルとフレームワークの強い依存関係が許される、なんてオチじゃないよね？
あと枯れてる枯れてないって、じゃ generics や annotation は枯れてないから使わねーと？
0025デフォルトの名無しさん
2008/08/24(日) 21:17:10それは RoR とかポトペタで画面作れますとか、
O/R mapper でウハウハだよもんとか、
そう言うレベルの話では。
DIコンテナが提供してくれるのは糊だけ。
既存のポトペタとくっつけたきゃそうするし、
フルスクラッチの俺様フレームワークとくっつけても良いし。
疎結合の利点を最大で活かすために糊に徹してるのが DI コンテナ。
0026デフォルトの名無しさん
2008/08/25(月) 01:06:47自分でファクトリ書かなくていい
テストコードが嫌でも書きやすくなる
下２つが特に有難い
短期開発でメンバのスキルが低いときは逆にDI使わないと品質は保てない
ファクトリ書いてる時間を他の作業に回せるし
0027デフォルトの名無しさん
2008/08/25(月) 08:03:17余裕あるんだな
0028デフォルトの名無しさん
2008/08/25(月) 21:35:10ファクトリ書かなくても良いってのが DI の利点の一つなわけだが、
そもそもなんでファクトリ書くべきなのか分からんようでは、その利点も分からん訳だ。
溝は深いね〜
0029デフォルトの名無しさん
2008/08/25(月) 22:17:32ファクトリとかソースが見にくくなるだけ。
0030デフォルトの名無しさん
2008/08/25(月) 22:59:07提供するAPIには必ずファクトリが含まれるわけだが
0031デフォルトの名無しさん
2008/08/26(火) 01:31:50って聞きたいのに、強がって
「DIコンテナって便利か？」
って聞いてるわけか。
0032デフォルトの名無しさん
2008/08/26(火) 03:55:28それが登場した背景の考え方が分かってない。
だからいつまで経っても話がかみ合わない。
モジュールの凝集度高めて疎結合目指すなんてのは
それこそ20年以上前から言われてることなのに
理解して実践してるのはごく少数なのが現実。
0033デフォルトの名無しさん
2008/08/26(火) 21:52:130034デフォルトの名無しさん
2008/08/26(火) 22:29:25全くもってそうらしいね
今途中から突っ込まれて行ってるプロジェクトは結構グダグダで火を吹いてるんだが、
ソースを見てビックリ呆れること多数。
所謂大規模開発で、結構な数の業者が入っていて、開発人員も多いんだけどね。
規模なんてソースの品質には関係ないらしいよ。
勿論 DI なんて使ってないんだが、更に残念な事に自分等でファクトリを書いてない。
おまけにベンダ製のツールが吐いたファクトリクラスがあるんだが、
そのファクトリを使うとき、getFactory() ってなスタティックメソッドがあるにも関わらず
毎 回 そ の フ ァ ク ト リ を new し て る 。 orz
てめぇー、インスタンスの取得方法を知らなくてもいいようにファクトリがあんのに、
そのファクトリを毎回 new してどーすんのよ！？ってな感じ orz orz
そんなコードがゴロゴロ
こんなんが某超大手元受の金融機関向けシステム開発だってんだから
残念な業界ですねって言いたくなるよ。
その残念な質の一画を自分の会社が占めている事実が更に残念。
早く辞めてぇ
（ﾏな内容でｽﾏｿ）
003534
2008/08/26(火) 22:38:15正：インスタンスの生成方法を
0036デフォルトの名無しさん
2008/08/26(火) 23:19:54お前も残念な会社の社員なんだろ？ｗｗｗ
0037デフォルトの名無しさん
2008/08/26(火) 23:59:18気持はわかるけど、ここマ板じゃないから。
0038デフォルトの名無しさん
2008/08/27(水) 00:18:53そんなつまらん会社辞めろ。
お前も残念な質の会社の一角を占めてるんだ。
辞める気がないならつまんない愚痴言わず、
会社、業界を良くする努力しろ。
0039デフォルトの名無しさん
2008/08/27(水) 00:24:480040デフォルトの名無しさん
2008/08/27(水) 00:28:08>ベンダ製のツール
そのベンダ製のツールの使用ガイドとかはちゃんとアナウンスされてるんだろうな？
「用意しました。後勝手に使ってね」ってのはマネジメントしてねぇ。
>規模なんてソースの品質には関係ないらしいよ
基本的には「ある」と思ってる
規模が大きくなればなるほど全体的なソースの品質は低下する
まあ上記のような問題を解決するための手段として
AOPやらDIみたいなのが出てきたのだけど
結局AOPやDIで何がやりたいかの理解が
実装者個人個人にまかされてしまってるのが問題な希ガス。
実装ガイドくらいではそこまでの統一はとりづらい。
で堂々巡りな状況に陥ってるような。
0041デフォルトの名無しさん
2008/08/27(水) 00:36:09興味ある人も取り立てて語る事なかったし。
気になって試して、気に入ったら使う。
ドキュメントが詳細だから疑問に持つこともない。
> 結局AOPやDIで何がやりたいかの理解が
テストとか便利にできるよ程度でいいんだけどね。
テスト極めようと思ってれば、気がつけば疎結合になってるだろうし、
適切なテストがきちんと通るなら品質には問題は出ない。
でも背景知らずにツールだけ知って、
使い方分からない、良さ分からないとか言ってる人が多数なわけで。
で、説明するのも面倒だから放置して
気が付くと自分しか使ってないとか、そんな感じ。
0042デフォルトの名無しさん
2008/08/27(水) 01:11:47004334
2008/08/27(水) 02:04:26笑いごっちゃーないですわ…
>>37
重々承知です。ご勘弁を
>>38
辞めるにしろ、対策するにしろ、具体策を考えてるところです。
ただ、このプロジェクトは今更どうこう出来る状態じゃないので、今ある部分は最後までそのままだと思われ。
>>40
そのベンダのツールは勿論マニュアル付きです。
つか、読まなきゃ使えないはず…
まあファクトリを理解せずに毎回 new しちゃってる、ってことなんだと思いますよ…
>>規模なんてソースの品質には関係ないらしいよ
>基本的には「ある」と思ってる
>規模が大きくなればなるほど全体的なソースの品質は低下する
…
次転職するときは面接で何を聞かなきゃいけないか良く分かった、ってことは最近痛感している。
0044デフォルトの名無しさん
2008/08/27(水) 02:27:13その事を理解してないプロジェクトの多いこと多いこと
チーム内で最低のレベルにいるメンバーにも
問題なく使わせられるようにしないといけないのになぁ
>>43
>そのベンダのツールは勿論マニュアル付きです
そのマニュアルの内容にもよるけど
上で語っているようなレベルのもの？
マニュアルを自分が理解できたから
他人も理解するべきってのは違うぞ。
ちとマ的とゆうかPM的になっちゃたな・・・
0045デフォルトの名無しさん
2008/08/27(水) 21:26:50ああ、落ちてる。せっかく立てたのに・・・。
0046デフォルトの名無しさん
2008/08/27(水) 22:58:15結局後で分かりやすいんだよな
0047デフォルトの名無しさん
2008/08/28(木) 00:32:17SpringMVC語ってくれる人あそこくらいだったんでよく見に行ってたんだが
0048デフォルトの名無しさん
2008/08/28(木) 01:32:59もはやS2の方が完全上位なんじゃね？
0049デフォルトの名無しさん
2008/08/28(木) 06:20:19無知こそ最強って感じだよorz
0050デフォルトの名無しさん
2008/08/28(木) 06:42:56利用するDIコンテナに強く依存
0051デフォルトの名無しさん
2008/08/28(木) 08:15:02相当流行ってからじゃないと勉強もイミないかも・・・
0052デフォルトの名無しさん
2008/08/28(木) 19:54:110053デフォルトの名無しさん
2008/08/28(木) 22:50:00せっかく覚えたのに。。。
0054デフォルトの名無しさん
2008/08/29(金) 01:48:31俺もSpringMVCが好きなんだけど、
じゃぁ毎日語ることがあるのかと言われると、そんなものはない。
Spring スレは3年くらいスレが保守されてたが、
1.2.x が安定したころから、特に話題もなくなった。
0055デフォルトの名無しさん
2008/08/30(土) 01:50:09SpringMVC悪くないんだけど、
あのControllerの深い継承具合はどうかと。
なんだよ、あのテンプレートメソッドの嵐。
せっかくDIコンテナなんだから、
ブリッジパターンとかもーちょっとすっきりできなかったのかよ。
0056デフォルトの名無しさん
2008/08/30(土) 19:32:220057デフォルトの名無しさん
2008/08/31(日) 14:28:160058デフォルトの名無しさん
2008/08/31(日) 16:20:22気持ちはわかる。なにも考えずにそういう事する奴は確かにいる。
メソッド全部publicとかと同レベル。
でもサービスクラスを書いてるときに、要素の入れ替えがあるから
LinkedListに使ってるよーとか、こいつは要素追加するとソートされるよ
とかを利用者に伝えるために戻り値の型を実装クラスで書いた方が
いいんじゃないかと思うこともある。
0059デフォルトの名無しさん
2008/08/31(日) 16:37:08起動時遅いとかメモリ喰うとかのデメリットもあるよね。
インジェクションするクラスを設定で簡単に切り替えられるのが
一番の目的だったと思うんだけど、本番環境にデプロイするのは
1パターンだけであまりメリットが感じられない。テスト用なら
こんな高機能いらなくて設定ファイルでObjectIdと実クラス名
の紐付けできるファクトリがあればいいだけだし。
似たようなシステムをちょこっとクラス入れ替えていくつも
リリースするような時には確かに有効。ソースツリーも
一つで管理できるし。でもそんなプロジェクト一回しか経験したこと無い。
Web側(jsp)は全然違うから別ソースだし。似たようなプロジェクトの時も
反省点を踏まえて作り直したりするし。
ファクトリのコード削減とAOPによるログ出力くらいなんでしょうか。
0060デフォルトの名無しさん
2008/08/31(日) 17:09:360061デフォルトの名無しさん
2008/08/31(日) 20:56:39起動遅いのはあまり問題にならんと言うか、
モジュールレベルで完璧に作れてれば
あとは組み合わせるだけなんで、別にどうでも・・
クライアントアプリなら問題にはなるけど
あまりそういう分野で使われてないだろうし。
逆に S2みたいな Hot-Deploy を売りにするセンスが俺には理解できない。
結局つながないと開発できないのかよ、それって DI かよって。
メモリってそんなに食う？これは実感したことないや。
日頃からテストがきちんとできる仕組み用意して
それを実践してるなら、別に DI コンテナ使う必要はないよ。
俺は自分で用意するの面倒だし、
自分のコードなんて全然信用してないから
十分にテストされたものを使うだけの話。
0062デフォルトの名無しさん
2008/08/31(日) 21:09:44>ファクトリのコード削減とAOPによるログ出力くらいなんでしょうか。
それって大きいと思うけど。
それから宣言的トランザクションは使わないの？
今のプロジェクトで DI，AOP 使えれば良いのに、ってかなり思うよ。
ログ出力のコード分量もかなりなもんだし、
トランザクション制御の為に、サービスクラスに abstract execute() みたいなの強制してて超汚ねーし、
必要ない new をやたらと書きまくるやつはいるし（これは別問題か…）
慣れてきてから、DI 使わないプロジェクトで同じ事やろうとしてごらん。
汚いの面倒くさいの… 馬鹿らしくなるよ。
0063デフォルトの名無しさん
2008/08/31(日) 23:50:23ServiceとDaoは自動生成でSinleton生成コード吐くし、
bean idとクラス名結びつけるファクトリは枯れたxml読み込み
クラスを利用して1クラスで完結してるんですわ。
private AnyService anyService;
と宣言してアクセッサ用意するより
private AnyService anyService = AnyService.getInstance();
で設定したクラスをインスタンス化できた方が若干楽だし
publicなget/setAnyService()があるとそれを利用側プログラムで
呼び出していいと思われても嫌だし。springでセットしたserviceが
入ってるからgetしても問題は無いんだけど。
そうするとspringしらない技術者がヘルプで入ってきたときに
DIっていうのはねっていうところから説明するより全然
教育コストも低いんですよ。
起動が遅くなるのはEclipseでデバッグ時にちょっとした修正で
いちいち時間かかって精神衛生上よくないっていうだけで根本的な
問題ではないけど。
0064デフォルトの名無しさん
2008/08/31(日) 23:57:13なった今存在意義が薄いし、ソースの骨格が自動生成でこみいったとこだけ
手で実装なので、むしろうまく行っているところはトレースログとりたくないし。
トランザクションは昔から使ってるDBコネクションプールがThreadLocalで
好きなとこでstart()/commit()させてくれるのでこれをService内に
明示的に書いてある方が問題があったときにどこでcommit()/rollback()
されてるかわかりやすいと思うんだけど、もう俺の考えが古いのかなあ。
デバッグ担当する人間が全員springのxmlの仕様を知っていないと
「どこでコミットされているかすぐに把握できない」のはめんどくない？
ずっと少数精鋭主義のプロジェクトでやっていけるなら別だけど
0065デフォルトの名無しさん
2008/09/01(月) 00:04:32>bean idとクラス名結びつけるファクトリは枯れたxml読み込み
>クラスを利用して1クラスで完結してるんですわ。
結局DIしてるわけだからこのスレとは違っちゃうか
0066デフォルトの名無しさん
2008/09/01(月) 00:29:30それでうまくプロジェクトが回ってるならそれでいいと思う。
教育コストはDIがどうこうよりも、
テストファーストがどうこう、
ステートレスがなんやら、
疎結合だとあれこれ・・の説明に苦心しない？
「ふーん、面倒なんですね」の一言で片づけられた日には悲しくなったよ。
で、今日もまたテストケース書かないコードをコミットしやがる・・・
0067デフォルトの名無しさん
2008/09/01(月) 00:40:51俺もこれは例示のための例示にしか過ぎないと思う。
通常、AOPはメソッド境界で作用するけど
このレベルで横断的にログ取りたいものなんて殆どないし。
メソッド内部の動作で不審な動きがないかチェックしたいとは思うけど、
取得したい情報なんて処理ごとに異なるし、そもそもAOPでは制御不能。
AOP使う話であれば、トランザクションと認証回りが適切な例だと思う。
＞少数精鋭主義のプロジェクトでやっていけるなら
別に精鋭じゃなくても設定くらい読めるから。
トランザクションが何か分かってるなら、書き方・読み方教えて終了。
いろんな場所でトランザクションの開始・終了が出来れば
きっと効率が良いのだろうけど、少数精鋭ならともかく
現実の開発でそれやるとロクなことにならんですよ。
好き勝手に開始して放置して、もうグダグダ。
多分、今まで少数精鋭でやってきて、そういう事態に陥らなかったんだと思う。
0068デフォルトの名無しさん
2008/09/01(月) 01:09:29昔みたいにウォーターフォールで仕様変更したら別料金とりますよっていうなら
いいけど、仕様が変わる度にテストケースも保守していくのは
常に詳細設計ドキュメントを保守し続ける位面倒。んで最後にまとめて
作ろうと思って納期迫ってカバレッジ低いテストケース書いてるから
それも駄目なんだけどね。
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でトランザクション管理しない
っていうのが徹底されてるのが効いてるのかな。
0069デフォルトの名無しさん
2008/09/01(月) 09:45:29>>66
Unitテストが義務化されていないからだな。
これはかなり大変。「テストを楽にする」は
意外に動機として大きいから。
仕様書が明確に落ちて無いと末端の子に
テストファーストは難しいけど、デグレードを
未然に防ぐ為のテストセカンド（造語）くらいから
やるのはどうだろう。
自分のコードにバグが無いことの証明だから
ホントはやってて当たり前なんだけど。
007069
2008/09/01(月) 09:47:40疎結合は再利用性。
「ほら、別のプロジェクトでも簡単に使いまわし
できただろ？」
って言える例を作ってやれればどうにか。
ようは教える側がメリットを示すのが良いと思う
（デグレードが減る。使いまわしが楽など）。
ただし、教えられる側が
・時間内手を動かしてさえいれば金が貰える
・バグで人に迷惑をかけてもかまわない
そんな思想だと哲学から変えないとダメ。
0071デフォルトの名無しさん
2008/09/01(月) 10:06:33「newを直に書きたくない」
という思想にいたる事が出来れば
DIコンテナのメリットが説明しやすい。
結局ある程度抽象化の概念に
同意していない人には無用の長物かも。
0072デフォルトの名無しさん
2008/09/02(火) 00:22:13疎結合でサービスクラスやアクションを使いまわしたりしないし
その説明では納得できん。ただ共通関数を増やしていくだけでいいだろうに
0073デフォルトの名無しさん
2008/09/02(火) 00:29:44interfaceベースで作ってたら、当たり前の現象なんだが、IDEのパワーをないがしろにしてる。
それでもDI自体は分業に向いてると思うし、俺は好きだ。
0074デフォルトの名無しさん
2008/09/02(火) 01:30:45もうほんと、それだけ
問題は、Javaがそもそも原理主義的なコーディングに不向きなことと
現実世界(特にビジネスまわり)がちっとも原理主義に根差してないことが原因で、
DIから得られる現実的なメリットが、ほとんど実感できないくらい
小さくなってしまっていること
0075デフォルトの名無しさん
2008/09/02(火) 01:59:43現実を現実のまま処理しようとして
ステートフルな世界に走ろうとして失敗してる人が多数居る。
ところで原理主義って何？
0076デフォルトの名無しさん
2008/09/02(火) 03:03:420077デフォルトの名無しさん
2008/09/02(火) 03:40:53共有リソースの管理に便利。
0078デフォルトの名無しさん
2008/09/02(火) 04:39:250079デフォルトの名無しさん
2008/09/02(火) 04:53:57逆に、共有リソースの管理がスタティック変数でまかなえる場合や、ログ・トランザクションをそこまで徹底しない場合は、DIコンテナ不要。
0080デフォルトの名無しさん
2008/09/02(火) 04:54:48008169
2008/09/02(火) 09:21:14ごめんね。俺が思ってた疎結合の話に
君が思うようなサービスクラスやアクションを
含んでいなかった。
そしてDIにたどり着く前の段階の前提なんだ。
>>66の言う教育の時に自分がどう行動するかを
書いてみた。
サービスとかアクションならモックを引き合いに
出すかなぁ。モックの意味を理解する人ならわかって
くれるかもと思う。
>>72を説き伏せようとは思っていないから
けんか腰にならないでね。
0082デフォルトの名無しさん
2008/09/02(火) 09:30:42同じ事がインターフェースを
たくさん使ったソースコード（非DI）を
新人さんが読んでいる時に起こっていた。
あるメソッドが呼ばれているはずなんだけど
呼び元にEclipseで飛んでもインターフェース
にしか辿り着けないという形。
力技でもどうにかできるようにしたければ
インターフェース使わずに書くのも良いと思う。
どこで切るのかの問題かもしれないけど。
0083デフォルトの名無しさん
2008/09/02(火) 12:15:15俺もDIは好かんけど
eclipseもまともに使えないヤツには無理
0084デフォルトの名無しさん
2008/09/02(火) 16:36:260085デフォルトの名無しさん
2008/09/02(火) 23:56:13面倒に感じるんだが。
0086デフォルトの名無しさん
2008/09/03(水) 00:43:13あまりに漠然としすぎててどの話をしてるのか分からん。
>>68
ネストしたトランザクションがスマートに記述できない時点で
もう面倒だと思いますよ、俺は。
それでもなお俺様フレームワーク最高ですか？そうですか。
0087デフォルトの名無しさん
2008/09/03(水) 01:11:41外側トランザクションの中に内トランザクションがいくつかあるの？
内トランザクション1がコミット成功して内トランザクション2で
失敗したらどうなるの？
0088デフォルトの名無しさん
2008/09/03(水) 01:32:12内2で失敗した時点で内1もひっくるめてロールバックされる。
コミットが行われるのは外のトランザクションが成功した時。
0089デフォルトの名無しさん
2008/09/03(水) 01:37:24内1だけ呼びたい時は内1のコミットをアテにして、
内1、内2って呼びたいときは内1の中に書いてあるトランザクション処理を
無視できるから楽ってこと？
0090デフォルトの名無しさん
2008/09/03(水) 22:57:52POJO と abstract class タイプフレームワークの綱引きがあって、
睡眠不足で寝ぼけてると、見当違いのところに abstract class タイプのフレームワークを適応しちゃったりする。
使い分けは、きっちりやりたいね。
ちゃんと睡眠とって、すっきり脳味噌で POJO を書こう。
今大人気だから覚えといて損はないよ
0091デフォルトの名無しさん
2008/09/04(木) 00:20:52StrutsクラスはStrutsに依存。
おまえらバカなんじゃね？
0092デフォルトの名無しさん
2008/09/04(木) 00:35:080093デフォルトの名無しさん
2008/09/04(木) 00:38:06依存してるかどうかじゃなくて依存をコントロールできることが重要なのに、何言ってんだおまえは。
0094デフォルトの名無しさん
2008/09/04(木) 00:46:320095デフォルトの名無しさん
2008/09/04(木) 01:57:13構造化プログラミングの時だってごく少数の優秀な人は
わかりやすくて綺麗な構造化をしていた。OOPの時代になっても
優秀な人の割合は変わってない。凡人がソースを書くときの
汚さが、構造化の時よりちょっとマシになっただけ。
でもその恩恵はインターネットの普及により情報が得やすく
なったせいかもしれない。
0096デフォルトの名無しさん
2008/09/04(木) 02:20:31DIなら上流PGの実装が間に合わない時はDAOの具体実装をダミーにしとくとか調整も出来るよ。
0097デフォルトの名無しさん
2008/09/04(木) 03:18:44このケースに限ってはそう。
でも本質はコードに横断的情報が含まれないことが
多くの利益をもたらすって話なんだけど。
そのロジックの処理の本質にトランザクション管理が関与するのかって話。
必要ないのに手続きのために書いてるのなら、
ノイズが乗ってるのと同じこと。
追い出せるなら追い出したいと、なぜ考えないのか。
>>95
情報が得やすくなったのは確かだけど
情報を得ようとする人がたいして増えてないのもまた事実で。
成長待ってても埒があかないから、いろいろな話をしてみるけど徒労に終わる。
探せば情報が得られる分、スキルの格差はむしろ広がってるのでは。
0098デフォルトの名無しさん
2008/09/04(木) 05:21:34なぜそんな上から目線なのか
どこからどこまでを同じトランザクションにまとめないといけないのか、
は本質的な処理だろ。マーチンファウラーの提唱するような薄いサービス層の
ポリシーを守っていれば、トランザクション管理をxmlに置くのか
Serviceメソッド内に置くのかの違いでしかない。トランザクションの
範囲を確認するのに設定ファイルを別に開くよりは見やすい。
注文と残高を同時更新する場合と、残高だけを更新する場合で
Serviceを分けなくても良い(前者の場合でも残高だけ更新Serviceを呼び出しても
よい)というのは確かにメリットだと思う。
0099デフォルトの名無しさん
2008/09/04(木) 11:32:30昔は本とか読むしかなかったから、いきなり答えが得られることは少なかった。
だからどうしても書いてあることを理解して自分で応用する必要があった。
0100デフォルトの名無しさん
2008/09/04(木) 15:02:30特定のメソッドから特定のメソッドの間でトランザクションを定義することは
横断的な情報、つまりAOPじゃないよね
0101デフォルトの名無しさん
2008/09/04(木) 15:53:23ただしトランザクションをどう実装するかはコードの本質ではない。
0102デフォルトの名無しさん
2008/09/05(金) 01:27:42必ずしも本質的な処理とは思えないんだが・・・
むしろ「モデルの状態を元あった状態に戻す」ためのひとつの実装パターンに
すぎないのでは？
0103デフォルトの名無しさん
2008/09/05(金) 10:31:45トランザクション処理しなきゃならないとかそういう話。
0104デフォルトの名無しさん
2008/09/05(金) 23:02:140105デフォルトの名無しさん
2008/09/06(土) 01:42:18わりと良書だったが、悲しいかなDIの話題はなかった。
(チラッと名前だけ出る程度。)
代わりにサービスをルックアップするコードが記述されていた。
今時どうかと思った。
0106デフォルトの名無しさん
2008/09/06(土) 20:42:33普通の人が書いた汚いコードなら、構造化プログラミングとかのほうがよっぽどマシ。
OOPわかってない奴が書いたOOPっぽいコードなんて、汚な過ぎて見てると吐きそうになるだろ？
0107デフォルトの名無しさん
2008/09/06(土) 20:52:30なる。
ドメインオブジェクトに関わりの薄いロジックが入っていたり、
固有のクラスでしか行われない処理が基底クラスに入っていたり
ス○ー○ジッ○のソースはひどかった
0108デフォルトの名無しさん
2008/09/06(土) 21:30:18聞いたことねえや
> OOPわかってない奴が書いたOOPっぽいコード
ああ、見てるとイラッと来る
自分も一度は通った道ではあるものの
0109デフォルトの名無しさん
2008/09/07(日) 00:55:05おまいらコレすっと動いた？
0110デフォルトの名無しさん
2008/09/07(日) 02:25:300111デフォルトの名無しさん
2008/09/07(日) 11:46:30恨みでもあるの？
そこで名前を出す意味が分からないな
0112デフォルトの名無しさん
2008/09/07(日) 21:13:24ずっとうごいたけど
0113デフォルトの名無しさん
2008/09/14(日) 21:08:26には有効かもだけど、１から作るような業務アプリではメリット感じない。
大体、１から作るような業務アプリという時点で泥くさいことやらなきゃいけない
ケースが多いし、インターフェースが有効なケースもあんましない。
(パッケージ使用しない時点で、客は泥くさい対応を求めてくる。)
1インターフェースで1パターンだったら、密結合でも疎結合でもどっちゃでもいいん
じゃない。影響極少だし。
まぁ設計力の問題かもしれない。業務アプリでうまく交通整理できた具体例なんかが
あれば、ほんと具体的に教えてほしい。
0114デフォルトの名無しさん
2008/09/14(日) 21:11:59その業務は未来永劫仕様が変らないの？
0115デフォルトの名無しさん
2008/09/14(日) 21:15:240116デフォルトの名無しさん
2008/09/14(日) 21:22:13そんなことはない。ただ小変更の場合は実装クラス内の変更にとどまる
ことが多い。大きな変更の場合は、設計の根幹を揺るがすようなことが
ままある。実際客にとり、メリットあるのは、大きな変更のほうなん
だが、その場合は残念ながら、DIは無力だと思う。
0117デフォルトの名無しさん
2008/09/14(日) 21:44:38下位互換にこだわりすぎる言語の宿命だよ。
明らかに無理し過ぎてる。
0118デフォルトの名無しさん
2008/09/14(日) 22:02:49今はそういうのはPHPerが担ってるよ
0119デフォルトの名無しさん
2008/09/14(日) 23:04:57JavaEEはJSF+Faceletsを使って、WebBeansは出たら採用する。
正直SpringだのS2だのへの投資は無駄な投資。
0120デフォルトの名無しさん
2008/09/14(日) 23:22:56DIなんて実行時に今までやっていたことを設計時に限定する代わりに
設定ファイルで簡単に記述できるようにしただけだよね。
言語使用でサポートするとしたらどうなるのかな。
0122デフォルトの名無しさん
2008/09/15(月) 15:50:28業務の本体じゃない横断的な事象を切り出すには便利に使えると思うよ。
ただの道具として利用するレベルでも。
横断的関心事を業務の本体から切り離すってのはまあ、AOPの範疇かもしれんが。
0123デフォルトの名無しさん
2008/09/15(月) 15:56:50インタフェースベースの設計をする価値はないだろうね。
0124デフォルトの名無しさん
2008/09/15(月) 18:19:230125デフォルトの名無しさん
2008/09/15(月) 18:23:01それに対してインターフェイスを書かない状況ってのは、ちょっと分からないな。
そもそも、それって Java使う必要あんの？
LLの方が向いてない？
0126デフォルトの名無しさん
2008/09/15(月) 19:10:180127デフォルトの名無しさん
2008/09/15(月) 22:05:04DIなんて何の意味もないだろうさ。
0128デフォルトの名無しさん
2008/09/15(月) 22:53:410129デフォルトの名無しさん
2008/09/16(火) 00:12:090130デフォルトの名無しさん
2008/09/16(火) 02:18:19本質的な部分の修正だけですむのはDIの恩恵を受けてるんじゃないか？
0131デフォルトの名無しさん
2008/09/16(火) 02:39:07なんでもDIのおかげにしたいんですね。
0132デフォルトの名無しさん
2008/09/16(火) 02:48:59それ言うなら、どっちかっつうとAOPの恩恵なんじゃね？
0133デフォルトの名無しさん
2008/09/16(火) 20:40:32それはMVCをきちっとわけてれば出来ることだし、
OO以前の構造化設計でもきちんと設計が出来ていればできること
0134デフォルトの名無しさん
2008/09/16(火) 21:24:30「楽したい」と考えないエンジニアは碌なもんじゃないと思うんです。
0135デフォルトの名無しさん
2008/09/16(火) 23:27:14より楽な、より便利な使える道具ができたってだけのことだろう。
0136デフォルトの名無しさん
2008/09/17(水) 01:14:46外出ししたオブジェクトをルックアップするコードを書くのも面倒になった。
何使うかだけ書いといて、あとは外から勝手に注入してもらえば楽くね？
これだけだぞ、DIコンテナの本質は。
これがどういう意味を持つか分かる人以外には
どれだけ触っても全くの時間の無駄だ。
0137デフォルトの名無しさん
2008/09/17(水) 01:45:51くねくね？
0138デフォルトの名無しさん
2008/09/17(水) 05:05:330139デフォルトの名無しさん
2008/09/17(水) 12:32:290140デフォルトの名無しさん
2008/09/17(水) 12:41:16業務アプリで使うのはどうかって話だ。今のspring他の実装はまだ過渡期で、
5年後には設定方法やデファクトのDIツールすら変わってる可能性が
大いにある。Apache Torqueなんてまだ使ってるやついるか？
いたらゴメンね。でメインの開発者がとっくに退社してる場合、
今更Torqueなんてメンテし続けたくねーとか、Apache ECSなんて
jsp出てきた時点で終わってんだろ、とか思う訳じゃない。
それを繰り返したくない。ちょっとファクトリクラス書くのが
楽になる程度の使い方なら、後の人がすぐ追えるようにシンプルな
ファクトリを書いておいたいいんじゃないか、と悩んだ事は何度もある。
いい加減springなら平気だろと思って使ってるわけだけど
0141デフォルトの名無しさん
2008/09/17(水) 14:07:48設計思想というものが前提的に存在しない層とはJavaは相容れないな。
0142デフォルトの名無しさん
2008/09/17(水) 14:34:53むしろ、低レベルな開発者を排除すべきだと思うんだが。
優秀な人間だけ集めると、開発ペースがメチャメチャ速くなるぞ。
無駄なドキュメントは作らなくてすむし、くだらないバグも仕込まれないし。
0143デフォルトの名無しさん
2008/09/17(水) 14:37:240144デフォルトの名無しさん
2008/09/17(水) 14:53:380145デフォルトの名無しさん
2008/09/17(水) 15:02:53あんまし使われとらんの？
0146デフォルトの名無しさん
2008/09/17(水) 17:15:040147デフォルトの名無しさん
2008/09/17(水) 21:51:04そりゃ、簡単には出来ないよ。
>>144
普通の会社が100人月かけるところを、30人月とかでやってしまうってことだよ。
0148デフォルトの名無しさん
2008/09/17(水) 22:22:50少数精鋭だと事故や病気で欠員が出ると途端に回らなくなるが。
後メンテナンスにも「優秀な」人材が必要になったりしないよな？
ノウハウが属人化して「Aさんじゃないと判らない」なんてよく聞く死亡フラグだ。
（もちろん>>147は、そんな奴は優秀とは言わないとか
優秀な人材ならすぐ対応できるとか言うんだろうが）
普通の会社ではどうするかって？
そこそこの能力で替えが効く人間を大勢揃えるのさ。
もちろん、人間の替えが効くようにメジャーな言語や技術を選択して
必要なスキルレベルも最低ランクの人材に合わせる。
これならメンテナンスする人材もすぐ都合がつくしな。
100人月とかの開発で必要な「優秀な」人材ってのは、
こういった面も見据えて適切な技術を選択したり
必要であれば独自フレームワークを設計したり
開発チーム全体のスキルレベルの底上げを行ったりできる開発者だろな。
なんて超アタリマエな事を偉そうに語ってすまん。
0149デフォルトの名無しさん
2008/09/17(水) 22:39:27うちも少数精鋭で立て続けに二人居なくなって
あばばばばってなったよｗ
0150デフォルトの名無しさん
2008/09/17(水) 22:50:300151デフォルトの名無しさん
2008/09/17(水) 22:51:49まいずれにしても優秀な人間だけ集めるってのはやっぱり現実には無理がある。
優秀な人間は各プロジェクトに分散させるもんだからな。
0152デフォルトの名無しさん
2008/09/17(水) 23:08:570153デフォルトの名無しさん
2008/09/17(水) 23:10:320154デフォルトの名無しさん
2008/09/17(水) 23:17:40プロジェクト管理？
決まってるじゃないか、エクセルだよ！
0155デフォルトの名無しさん
2008/09/18(木) 00:19:09DIコンテナってある意味、人間関係の希薄な現代社会みたい。
0156デフォルトの名無しさん
2008/09/18(木) 00:41:510157デフォルトの名無しさん
2008/09/18(木) 00:52:58欠員リスクはあるね。そこまで大きな仕事になると受けられないな。
で、引継ぎのほうなんだけど、運用保守要員のトレーニングも引き受けたり、
社内標準化と込みでやったりする。それに、そもそも特殊な技術を使うわけでもないし。
あと、俺の主張は「無能は使うな」であって、「優秀な人だけでやれ」ではないよ。
0158デフォルトの名無しさん
2008/09/18(木) 11:03:380159デフォルトの名無しさん
2008/09/18(木) 17:50:472chに書き込んでるような俺らみたいなヤカラでさえ、
より良い設計に興味があるだけマシで
普通のPGは会社引けたら知らんぷりだもんな
0160デフォルトの名無しさん
2008/09/18(木) 20:43:51DIコンテナとかの話するだけで目の敵にするような奴もいるしな。
…それはそれで正しいのか？そうは思いたくないが。
0161デフォルトの名無しさん
2008/09/18(木) 20:56:26DIなんて裏方だし、骨組み作る人間だけが意識してれば良いじゃん。
0162デフォルトの名無しさん
2008/09/18(木) 21:06:490163デフォルトの名無しさん
2008/09/18(木) 21:19:46残業しまくって成果物がゼロに近い奴が首にならないんだよな。
しばしば年収を意識しちゃって鬱になるよｗ
>>160
費用対効果だわな。
DIはOJTの範囲外なのでちょっと投資する必要がある。
0164デフォルトの名無しさん
2008/09/19(金) 00:43:31実装者が理解できてないままだと
interface 使わないコードを平気で持ってくるわけだが。
お前さんのレビューのコストがバカになんねえよ。
実例挙げて教育した方が絶対早い。
分からないやつは切り捨てたらいいから。
0165デフォルトの名無しさん
2008/09/19(金) 20:35:47理解させずとも「規約違反」で片付ければいいだろ。
ガチガチの規約ずくめのプロジェクトなら
そもそもPGが勝手にinterfaceを作ることすら「規約違反」だしな。
0166デフォルトの名無しさん
2008/09/19(金) 20:46:29レイヤ構成と機能毎の箱だけ用意しておいて、後はそこに
処理を書いてください、みたいな。
馬鹿にしているとも思うけど、悲しいかな、そうしないと
最低限の品質を保てないということもある。
0167デフォルトの名無しさん
2008/09/19(金) 23:10:35それやっちゃうと3000行のメソッドや10000行のクラスが湧いて出たりしない?
そうならないように適切に分割したクラスやインターフェース書いて渡すの?
でもそういうのが判断できるとこまで設計したら、
中身も自分で書いた方がはるかに少ない工数で作れるよね……。
0168デフォルトの名無しさん
2008/09/19(金) 23:48:26レイヤ、機能までをそれなりに分割したものを渡すけど、
それでなくても今時3000行のメソッドは無いだろう(ﾟдﾟ )？
むしろ気をつける必要があるのは、重複する処理が作られること。
これはチェックして交通整理する必要有り。
工数というか効率に関しては、少数精鋭の方が良いのは勿論だけど、
1人で単位時間当たり1の成果を出すのではなく、10人かき集めて
単位時間当たり2の成果(効率は1/5)を求められることもある(´・ω・`)
0169デフォルトの名無しさん
2008/09/20(土) 11:51:27実際生産性自体は大きなな差はないこともある。
特に業務処理みたいなのの実装では。
しかし品質や保守性にはかなり差が出る。
業務処理とかじゃなくてもっと基盤よりの実装だったりして難度が高い部分だと
生産性にも品質にも保守性にもそれを使う側への影響にも大きな差がでる。
そもそも優秀じゃないと出来ないものもある。
0170デフォルトの名無しさん
2008/09/20(土) 12:27:401メソッド3000行はさすがに見たことないけど。
1000行のメソッドAの一部処理を別の1000行のメソッドBにしてあり、
メソッドBの一部処理をまた別の1000行のメソッドCにしてある、とかなら普通に見る。
ちなみに10000行どころか70000行程度のクラスまでなら普通に見る。
VB.NETのForm継承クラスに業務処理まで突っ込んだやつ。
0171デフォルトの名無しさん
2008/09/20(土) 14:07:320172デフォルトの名無しさん
2008/09/20(土) 15:21:57DIの有用さが理解出来ない奴は、これまでテストをきちんとやって来なかった奴だな
0173デフォルトの名無しさん
2008/09/20(土) 18:30:260174デフォルトの名無しさん
2008/09/20(土) 22:18:010175デフォルトの名無しさん
2008/09/20(土) 23:12:38疎結合って何？食えるの？な人の振り分けに使える。
インターフェースと実装は分けるだろ、普通。な人と
実装継承最高!オブジェクト指向って継承しまくることだろ？な人の振り分けに使える。
ステートレスが基本だが場合によってはステートフルなロジックも必要か、な人と
メンバ変数ってクラス内グローバルで最強だよな。スレッドセーフ？わけわかんねえ横文字口走るなよ、な人の振り分けに使える。
100行超えるとキモいからクラスなりメソッドなりにして意味のある名前付けようぜ、な人と
3000行超えるメソッドや10000行超えるクラス作っても動けばそれでいいだろ、な人の振り分けに使える。
なんでコードをコピペすんだよ。3回同じこと書いたら首吊って死ね！な人と
コピペのどこが悪いんだよ、動けばそれでいいだろ、このタコが！な人の振り分けに使える。
なんでテストコード書かないの？馬鹿なの？な人と
テスト書く時間でコード書けばいいでしょ？早く帰りたいでしょ？な人の振り分けに使える。
用途はたくさんあるぞ。
0176デフォルトの名無しさん
2008/09/21(日) 09:43:260177デフォルトの名無しさん
2008/09/23(火) 01:45:47自分も、業務ロジッククラスであっても値としてのプロパティを持たす事は少ないんだけど
(基本的にインターフェースだけプロパティに持たす)
これって普通なの？
状態を持たないクラスばかりであまりオブジェクト指向っぽくないかなと思ってた
0178デフォルトの名無しさん
2008/09/23(火) 02:17:20Webアプリがそうなるのはオブジェクトライフサイクルの都合かな。
スケーラビリティの都合と言い換えてもいいと思う。
0179デフォルトの名無しさん
2008/09/23(火) 06:00:48DI の問題点というのはまさにそこで、
その振り分けを生き延びた精鋭にしか保守できないシステムを作りまくるわけですよね。
業務システムの開発という場面では、保守担当者を選ぶコードなど糞です。
0180デフォルトの名無しさん
2008/09/23(火) 12:02:46一般的に >>175の内容で振り落とされた奴のコードはメンテし難いと思うんだが…
それからステートレス，ステートフル云々はwebアプリ実装する上では必須の知識でしょう。
まあ、それ以外でも必要だと思うけど。
OOP勉強すりゃ、DIなんて難しいこと何も無いと思うけどね。
スレッドプログラミング初心者にマルチスレッドサーバのメンテをさせることで金貰おうとしてないか？OOPも同じことだと思うんだが。
それで苦労するんなら、金貰って勉強できる分有り難いと思え。
それで勉強しないのなら諦めて辞めろと言いたい。
0181デフォルトの名無しさん
2008/09/23(火) 12:17:25「業務システムに適用するスキルレベルを引き下げないと保守要員が確保しづらい」という話をしてるのに
なんで>>180では
「保守したきゃスキルあげてこい」って話になるのかな？なるのかな？
0182デフォルトの名無しさん
2008/09/23(火) 12:26:54業務による垂直方向の機能分割と、レイヤによる水辺方向の機能分割。
DIってのはそれを補助する仕組みにすぎないんだから。
あって困るものでないというものであって、精鋭でないと使えないなんていうのは
大きくな勘違いだと思うよ。
それが理解できないなら、煽りでなく、職業を変えた方が良いと思う。
0183デフォルトの名無しさん
2008/09/23(火) 12:43:56初期設計にまともなプログラマが居れば良いだけ。
0184デフォルトの名無しさん
2008/09/23(火) 12:55:21俺の言いたいこと全部言ってくれて助かったんだが、
＞それが理解できないなら、煽りでなく、職業を変えた方が良いと思う。
これ実践すると、日本のプログラマ人口は1/100以下になるよな。多分。
0185デフォルトの名無しさん
2008/09/23(火) 12:59:340186デフォルトの名無しさん
2008/09/23(火) 13:50:100187デフォルトの名無しさん
2008/09/23(火) 14:08:12いや、それはむしろそっちの方が正しいだろ。
一般的な業務アプリの世界では、99/100の作業者PGには
テクニカルな事よりも業務知識を覚えさせて。
アーキテクチャとかは1/100な人間が決めて、作業者PGは
その枠組みの中で制御構造だけ書いていた方が効率が良い
…っというか、現実的ではあるから。
テクニカルな仕事がしたいのであれば、インフラ系、
製品開発、Web系、組込み系へいくべきだろう。
0188デフォルトの名無しさん
2008/09/23(火) 15:39:34>これ実践すると、日本のプログラマ人口は1/100以下になるよな。多分。
でも残った人の仕事は逆に楽になっちゃう、みたいな。
0189デフォルトの名無しさん
2008/09/23(火) 15:45:400190デフォルトの名無しさん
2008/09/23(火) 16:01:27結果として出る成果に違いは無いとも思うし、
居ても居なくても同じどころか、
むしろ居ない方が良い人間が居るのにも
同意はするが。
でも、矢面に立って無駄死にしてくれる人間が居ないと、
こっちにまで変なおはちが回ってくるので、
まあ、居ても良いよというか、そんなかんじかな。
0191デフォルトの名無しさん
2008/09/23(火) 21:45:03業務知識も知らないよりは知っていた方がいいだろうけど、
それは最低限のエンジニアとしての力量があってから初めて役に立つのであって、
上（アーキテクトする人）の言う事も理解できんアフォが「業務知識」とか言うと胡散臭ぇ。
0192デフォルトの名無しさん
2008/09/23(火) 21:55:390193デフォルトの名無しさん
2008/09/23(火) 22:01:510194デフォルトの名無しさん
2008/09/23(火) 22:22:03そんなたいしたもんじゃないけどな。
誰でもしばらくやっていれば身につく程度の内容で。
本当に業務知識があると思うのなら、
PGなんかやめて、それ専門で飯を食ったほうが
良いと思うし。
35歳で定年になったり、PG→SE(笑)→無能なPMと
ジョブチェンジして、現場に迷惑をかけたい奴は
技術より業務知識でもなんでも良いと思うが。
よく、転職情報とかにも業務知識がある人間が
不足しているみたいな事が書いてあるけど、
俺の感覚としては、本当に足りてないのは、
技術的なバックボーンを持って、意志決定できる
人間だと思うがな。
0195デフォルトの名無しさん
2008/09/23(火) 22:33:43信用しない方がいい、ってのは共通認識みたいだな。
0196デフォルトの名無しさん
2008/09/24(水) 11:24:48修正してやる！
0197デフォルトの名無しさん
2008/09/24(水) 11:28:12時々いるよね、顧客との折衝がうまくてSE向きの人とか、
人間関係調整するのがうまくてPM向きの人とか。
例え人差し指だけでキーボードを打ってても
0198デフォルトの名無しさん
2008/09/24(水) 11:29:020199デフォルトの名無しさん
2008/09/24(水) 20:43:18顧客の言うことをオウム返しするだけの無意味な存在になったり、
技術的背景が無いせいでにアホな設計をして、無駄な工数をかけて
デスマを引き起こしたりと、ろくなもんじゅない。
顧客と技術がわかる人間が差し向かいでやったときの生産性の高さを
一度経験してしまうと、そういうのって本当に馬鹿らしくてやって
いられない。
さらにスレ違いすまそ。
0200デフォルトの名無しさん
2008/09/24(水) 22:05:12偉そうにスレ違いな会話を続けるくらいだったらDIをもっと広める方法でも語ってくれよ。
業務知識とか言い出すPG（よほど恨みでもあるのか？）の説得方法とかさ。
0201デフォルトの名無しさん
2008/09/24(水) 22:15:02コンテナ自体を布教したりDependency Injectionパターンを
どうこう語るよりも、DIを使ったプロダクトを盛り上げた方が
嬉しいんじゃないかな。
0202デフォルトの名無しさん
2008/09/25(木) 01:19:27いったんDIを無理矢理導入すれば、後は使い込むにつれ説明不要で依存し出す。
0203デフォルトの名無しさん
2008/09/25(木) 01:25:12情熱と時間がないと無理よね。俺には無理。
0204デフォルトの名無しさん
2008/09/25(木) 01:34:19無理。
オブジェクト指向言語使っても構造化以前の
スパゲティコード書くやついるでしょ。あれと同じ。
DI使ってるはずなのに、オブジェクトを名前で探し出してたり、
あるいはなんでもかんでも new してたりするから。
あなたが然るべき立場の人間で、現場でそれを強制するだけの発言力があれば話は別。
0205デフォルトの名無しさん
2008/09/25(木) 01:42:50という導入から入っても俺は迷うことなくDIまで辿り着いたなぁ。
保守思考が高いか否かで、個人差が出るのかなと思ってる。
0206デフォルトの名無しさん
2008/09/27(土) 01:32:33Springは「困ったら英語のドキュメントを読む人」でなければ使えない
Seasarは「困ったらソースコードを読む人」でなければ使えない
という印象。
少なくとも、チームリーダーがしっかりしてるレベルの部隊でないと
現状ではどちらも厳しいと思うのだが。
0207デフォルトの名無しさん
2008/09/27(土) 01:44:44記述量の削減が善という宗教
0208デフォルトの名無しさん
2008/09/27(土) 04:07:26それくらいできない奴は、いなくなった方が楽になる
0209デフォルトの名無しさん
2008/09/27(土) 07:26:39それは組織力のないチーム(=一匹狼の寄り合い所帯)の言い訳
0210デフォルトの名無しさん
2008/09/27(土) 08:15:02それですむ仕事をすればいいのに、なんで開発者になるんだろうか？
0211デフォルトの名無しさん
2008/09/27(土) 09:33:43だったりするんで、実は心の奥底から生産性なんか求めてなかったりする。
組織力ってのも Javaモンキー１００匹集められるか否か、ただそれだけだったりもする。
0212デフォルトの名無しさん
2008/09/27(土) 10:18:41>>209みたいなことを言うんだね
0213デフォルトの名無しさん
2008/09/27(土) 15:50:540214デフォルトの名無しさん
2008/09/27(土) 16:14:500215デフォルトの名無しさん
2008/09/27(土) 19:28:290216デフォルトの名無しさん
2008/09/27(土) 20:37:020217デフォルトの名無しさん
2008/09/27(土) 20:38:440218デフォルトの名無しさん
2008/09/27(土) 20:50:310219デフォルトの名無しさん
2008/09/27(土) 20:55:15s2はhackerのオモチャ
0220デフォルトの名無しさん
2008/09/27(土) 21:01:510221デフォルトの名無しさん
2008/09/27(土) 21:03:380222デフォルトの名無しさん
2008/09/28(日) 18:56:380223デフォルトの名無しさん
2008/09/28(日) 19:34:28問題なのは、真剣に学習コストをかけて展開するほど
今後長持ちするとは思われていないところじゃないかな
0224デフォルトの名無しさん
2008/09/28(日) 19:36:44人件費を裂くような馬鹿はいないだろ。
うちはWebBeansがJavaEEに載っかったら、
without EJBな連中とは決別する予定。
0225デフォルトの名無しさん
2008/09/28(日) 19:49:13仕事ではリスクが高くて採用できない
(請負で作っちゃって納品ﾊｲｻﾖﾅﾗなPJなら採用できるのはﾅｲｼｮ)
0226デフォルトの名無しさん
2008/09/28(日) 20:29:42COBOLなんか大昔の極一部の俺流フレームワークが神扱いされてるから･･･。
それに比べればSeasar系はまだマシだろう。
0227デフォルトの名無しさん
2008/09/28(日) 20:40:46キモ
0228デフォルトの名無しさん
2008/09/29(月) 02:30:39without EJBっていつの時代だよ
0229デフォルトの名無しさん
2008/09/29(月) 20:12:09自分より下を見てまだマシだ安心する訳ですね。
0230デフォルトの名無しさん
2008/09/29(月) 20:46:28ロッド・ジョンソンは今でもwithout EJBだよ
0231デフォルトの名無しさん
2008/09/30(火) 00:56:510232デフォルトの名無しさん
2008/09/30(火) 01:33:11もうロッドのいうことを無条件に賛同してるやつはいないだろ。
0233デフォルトの名無しさん
2008/09/30(火) 01:55:47少数派がいがみあってもしょうがない
0234デフォルトの名無しさん
2008/10/02(木) 07:33:34seasarも全然さくさくじゃねーしなｗ
0235デフォルトの名無しさん
2008/10/19(日) 21:03:330236名無し募集中。。。
2008/10/20(月) 01:28:40DIとは関係ない部分でだけど
0237デフォルトの名無しさん
2008/10/20(月) 03:18:260238名無し募集中。。。
2008/10/20(月) 03:30:530239デフォルトの名無しさん
2008/10/20(月) 06:56:59SAStrutsをパクってコンテナに依存しないStruts拡張を作るのが吉。
0240デフォルトの名無しさん
2008/10/20(月) 07:14:32Strutsに依存してることはOKなのか？
0241デフォルトの名無しさん
2008/10/20(月) 07:47:49ttp://d.hatena.ne.jp/higayasuo/20080613/1213326209
まあ、S2でいい人は別にSAStrutsで良いんじゃね。
0242デフォルトの名無しさん
2008/10/20(月) 07:53:13今はその時とは事情が全く違う
0243デフォルトの名無しさん
2008/10/20(月) 11:44:06あっさり変更したじゃないか。springはまだまだ死亡しないだろ。
0244デフォルトの名無しさん
2008/10/20(月) 13:24:25嬉しいことってあるの？
プロダクトを作る側ではなくて、使う側の話だけど。
非依存や切り替え可能にできるなら、その方が良くね？
特にSpringのゴタゴタとか見ていると。
T2はコンテナ非依存とか言ってるけどさ。よくわからんけど、プロダクトがコンテナに依存して
嬉しいことってあるの？
プロダクトを作る側ではなくて、使う側の話だけど。
非依存や切り替え可能にできるなら、その方が良くね？
特にSpringのゴタゴタとか見ていると。
T2はコンテナ非依存とか言ってるけどさ。
0245デフォルトの名無しさん
2008/10/20(月) 16:41:540246デフォルトの名無しさん
2008/10/20(月) 20:04:47メリットがあると言えなくもないが。
むしろ、作る側が非依存で切り替え可能だと、影響調査やバージョンの互換性
やらテスト項目がてんこ盛りで泣けてくるとだろうし。
0247デフォルトの名無しさん
2008/10/20(月) 20:59:50なんで2回繰り返してんだ？
依存するとコンテナの機能をフルに使える。
それで使う側に有益な機能が実現されればメリットになる。
DB依存のSQLも同じだろ。
0248デフォルトの名無しさん
2008/10/20(月) 21:13:31別にコンテナ固有の処理に依存する必要もないので、コンテナの部分を
抽象化して、切り替え可能にしたプロダクトを作っても良し。
コンテナに依存しているプロダクトを別のコンテナと使いたいので、
そのプロダクトのコピー版を作っても良し。
0249デフォルトの名無しさん
2008/11/01(土) 16:39:33dicon→javaのコード変換としてやってもらって、
後は普通にseasar2要らずでコンパイル→実行
みたいな枠組みは作れないのかなあ…
使う側としてはその方が嬉しいんだけどね。
プロダクトよりもseasar2の耐用年限を気にしないといけない今の状況だとチョット
0250デフォルトの名無しさん
2008/11/01(土) 17:19:130251デフォルトの名無しさん
2008/11/01(土) 18:02:030252デフォルトの名無しさん
2008/11/01(土) 19:25:380253デフォルトの名無しさん
2008/11/02(日) 16:04:21「なにがDIされるか」を知ってないと自分の書いたコードで
実行時になにが起こるかわかりにくいよねえ。継承ならまだ階層追えば
調べられるけど。
フレームワークのDIはほどほどにしてコード内で明示的に
委譲するようにしたい。でもspring利用しといて一部のクラスの生成だけ
サービス管理クラスを呼び出すのもわかりにくいし、難しいなあ
0254デフォルトの名無しさん
2008/11/03(月) 20:24:21ドメイン主体で継承とか。。
DIを良くわかってないようだな。
勉強し直してきた方がいいぞ
0255デフォルトの名無しさん
2008/11/03(月) 21:33:33君こそ勉強し直した方がいいぞ。DI以前にOOもな。
0256デフォルトの名無しさん
2008/11/03(月) 21:41:05Guiceみたいな形式が一番スマートだと思う。
0257デフォルトの名無しさん
2008/11/03(月) 21:52:570258デフォルトの名無しさん
2008/11/03(月) 23:07:13タイプセーフを壊す過度なDIってw
0259デフォルトの名無しさん
2008/11/04(火) 19:41:26注入する実装クラスが違ってたらコンテナが起動時に教えてくれるから
DIでタイプセーフ云々を問題視したことないんだが
0260デフォルトの名無しさん
2008/11/04(火) 23:30:27>タイプセーフを壊す過度なDIは不毛。
あんたはきっと実装に依存しすぎだと思う
0261デフォルトの名無しさん
2008/11/05(水) 00:01:170262デフォルトの名無しさん
2008/11/05(水) 00:52:35継承元のメソッドを呼び出してるかは継承関係追っかけるだけじゃ
わからないから、DIも継承も関係ないや、と思った。まる。
0263デフォルトの名無しさん
2008/11/05(水) 23:23:27そりゃあんましイミないけど
気持ちは分かる
0264デフォルトの名無しさん
2008/11/06(木) 02:10:35>実行時になにが起こるかわかりにくいよねえ。
そもそもDependency Injectionというのは
「分からないでもいい」という粗結合を実現するためのもの。
呼び出し側はインターフェースだけを知っていればよい。
理想論ではあるけれども。
おそらく実装に過度に依存したコードを書いているんだろうなと思う。
0265デフォルトの名無しさん
2008/11/06(木) 05:30:53フレームワークのドキュメント調べてる時間で自分で書いた方が
早かったじゃんって思ったり。フレームワークの全機能使う訳じゃ
ないからさ。
0266デフォルトの名無しさん
2008/11/07(金) 00:43:44DIコンテナに限らない話だな
0267デフォルトの名無しさん
2008/11/08(土) 16:22:02ただし、便利なら採用できるかといえば、それは次元の違う話
それだけ
0268デフォルトの名無しさん
2008/11/08(土) 18:56:25と思ったら1割くらいか…
0269デフォルトの名無しさん
2008/11/08(土) 19:07:59インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
そこでDI登場、と素っ飛ぶところ。
DIという考えが生まれるよりも遥か昔から、プログラマはインタフェースと実装を分離していたわけだが。
0270デフォルトの名無しさん
2008/11/08(土) 19:43:28だったら俺は昔からMVCに分けてたとかORマッピングやってたとかなっちゃうぜ
0271デフォルトの名無しさん
2008/11/08(土) 19:49:21自前のサービスロケータやDIコンテナモドキも作っているわけで。
だったら、そこでDI登場、と素っ飛んでしまっても何も
問題は無いと思う。
0272デフォルトの名無しさん
2008/11/08(土) 19:53:270273デフォルトの名無しさん
2008/11/08(土) 21:43:11>インタフェースと実装の分離という原則を説いて (それ自体は誰でも賛成する)
この｢インタフェースと実装の分離｣を聞きながら、
｢はあ？その理想論をどーやって現場で使えっつうんだよ！！｣
って思ってたところに
>そこでDI登場、と素っ飛ぶところ
DIが出てきて、
｢あーなるほどね、そーやるのね｣
って感じでナットクされたってこと。
インターフェイスとインプリメンテーション
みたいに
理論と実践をやってみせたのがDI。
0274デフォルトの名無しさん
2008/11/09(日) 06:08:42>この｢インタフェースと実装の分離｣を聞きながら、
>｢はあ？その理想論をどーやって現場で使えっつうんだよ！！｣
>って思ってたところに
そういう人のための道具ということでよろしいですか？
0275デフォルトの名無しさん
2008/11/09(日) 12:29:57それまではService Locatorをつかってた。
昔のEJBとかね。
だから、最初はDIじゃなくてInversion of Control（制御の反転）コンテナとか軽量コンテナとか呼ばれてたんだよ。
0276デフォルトの名無しさん
2008/11/09(日) 12:42:13むしろDIが無いと出来ないといってもいいな
0277デフォルトの名無しさん
2008/11/09(日) 15:36:38お前は独自フレームワーク(笑)でも作って一人で頑張って
0278269
2008/11/09(日) 20:25:58流石にファウラーの記事くらいは読んで言ってるよ。日本語訳もあるんだし
そもそもファウラー自身がメリットデメリットの話を書いているのに
素人が何の検討もなしに流行に乗っているだけという感じが。
巷が騒がしいから俺も遊んでみる→なんかコード書かなくて楽じゃね？→DIﾜｼｮｰｲ
という狂宴
0279デフォルトの名無しさん
2008/11/09(日) 21:11:19なんだ「自分は分かってる」君か。
臭いよ。
0280デフォルトの名無しさん
2008/11/10(月) 00:36:540281デフォルトの名無しさん
2008/11/10(月) 19:44:31AOPが簡単にできるだけで良いじゃねーか。
0282デフォルトの名無しさん
2008/11/11(火) 20:30:12あんたらばかぁ？
0283デフォルトの名無しさん
2008/11/11(火) 23:53:040284デフォルトの名無しさん
2008/11/11(火) 23:57:240285デフォルトの名無しさん
2008/11/12(水) 00:27:39ひがちゃんに聞いてみれば？
たぶん「ホットデプロイが！！！」しか言わないと思うが。
0286デフォルトの名無しさん
2008/11/12(水) 00:29:460287デフォルトの名無しさん
2008/11/12(水) 00:32:52javarebel
0288デフォルトの名無しさん
2008/11/13(木) 17:00:250289デフォルトの名無しさん
2008/11/22(土) 23:40:00GlassFishやJBossやら動いちゃくれても、現実問題耐えられんのよｗ画面真っ白けにしてお休みしちょうし。
かと言ってxmlヘルへの逆行もごめんだしで、もうS2アディクティブですよ。
0290デフォルトの名無しさん
2008/11/24(月) 22:44:02J2EEコンテナ(GlassFish , JBoss vs Tomcat , jetty) と
フレームワークの違いを混ぜてないか?
DI コンテナは、フレームワーク(ライブラリ)であって、J2EE コンテナではないだろう。
0291デフォルトの名無しさん
2008/11/24(月) 22:50:43http://www.infoq.com/jp/news/2007/12/does-di-pay-off
この記事でも、DIはテストする際の有利さ(便利さ)が語られている。
(逆に言えば、それしかない、という意見も紹介されている)
0292デフォルトの名無しさん
2008/11/25(火) 01:12:27この手のしょうもない議論がまだ繰り返されてるんだな。
OOPも初期は無駄な議論多かったよな。
今は自明だから議論が発生しないか、
あるいは分かってふりして黙ってるかの二択だが。
0293デフォルトの名無しさん
2008/11/27(木) 00:25:490294デフォルトの名無しさん
2008/11/27(木) 01:30:130295デフォルトの名無しさん
2008/11/27(木) 02:19:09XML書くことの何が面倒なのか理解不能。
0296デフォルトの名無しさん
2008/11/27(木) 02:30:090297デフォルトの名無しさん
2008/11/27(木) 08:42:29SAStrutsとか
0298デフォルトの名無しさん
2008/11/27(木) 21:00:580299デフォルトの名無しさん
2008/11/27(木) 21:18:39あいつらは設定ファイルやデータファイルの域を逸脱してる。
web.xmlとstruts-config or faces-configだけなら大して難しくない。
0300デフォルトの名無しさん
2008/11/27(木) 23:07:030301デフォルトの名無しさん
2008/11/28(金) 02:24:15つか、いまどきHibernateやらSpringやらもアノテーションだろ。
0302デフォルトの名無しさん
2008/11/28(金) 02:24:51antの、XMLで条件分岐や繰り返しや変数代入ってプログラム書かされるのはイヤになんない？
0303デフォルトの名無しさん
2008/11/28(金) 07:34:040304デフォルトの名無しさん
2008/11/29(土) 09:15:280305デフォルトの名無しさん
2008/11/29(土) 09:26:570306デフォルトの名無しさん
2008/11/29(土) 10:14:290307デフォルトの名無しさん
2008/11/29(土) 10:49:33XMLは違うファイルをいちいち開いてみなければならない
0308デフォルトの名無しさん
2008/11/29(土) 12:18:430309デフォルトの名無しさん
2008/11/29(土) 16:30:43俺は逆だと思う。
XML地獄は、設定をすべて一箇所にまとめておける。
アノテーションは、ソース開いてみないとわからない。
トランザクションなどの挙動を変えるときに、アノテーションはソースコードを編集しないといけないが、
XMLの場合は、設定ファイルをいじるだけ。
DIコンテナが登場した初期の思想、「設定をソースから追い出す」を、アノテーションは壊してしまっていると思う。
※アノテーションがすべて悪いといっているわけではない
0310デフォルトの名無しさん
2008/11/29(土) 21:06:32言いたい事を俺はどこまで理解できるか覚束ないレベルなんだが、
たとえばO/Rマッピングが一切のSQL文の排除を理想とするなら、SQL文定義ファイルは邪道になっちゃうよね。
設計思想に理想はあるべきでも、ほどよく妥協させてくれる仕組みがあるのが一番と思うんだが。
設定を一切合切ソースから追い出すのに、時間をかけすぎるくらいなら少しあってもいいんじゃ。コードの形式美を追求するためだけに書く人間が人生を浪費させられるんじゃねｗ
最後のひと言※があるからわかっちゃもらえると思う。俺はもうXMLオンリーの世界に帰りたくないｗ
なーんて。
0311デフォルトの名無しさん
2008/11/30(日) 05:31:11ソースいじったらコンパイルが必要とかはもうデメリットじゃないと思う。
ロジックの階層に応じてxmlなりアノテーションなりにまとめておければ
いいんじゃないの？設定ファイルにif文や変数いれたりアノテーションに
ビジネスロジック入れるようになるとやりすぎだと思う。
アノテーションでvalidateするのもvalidate処理が分散してちょっと嫌。
ORMはSQLを排除するんじゃなくて、速度を気にしないでいいところは
自動生成しちゃおうよって事だと思う。チューニングが必要なSQLだけ
外部ファイル書き出しでいいでしょ。つかみんなそうやってない？
0312デフォルトの名無しさん
2008/11/30(日) 13:46:22トランザクションの挙動みたいにアプリケーション横断なものは、それはそれでまとめておけばいいだろ。
0313デフォルトの名無しさん
2008/11/30(日) 15:05:23Seamみたいにカスタムアノテーションで共通設定をまとめれれば、設定を一箇所にまとめておける。
>>309 はアノテーションの使い方や、設定とアプリケーション構成記述の違いをわかってないだけではないか？
0314デフォルトの名無しさん
2008/11/30(日) 23:34:11アノテーションが散らばったソースコードを元にライブラリマイグレーションする事を考えると鬱になる。
5年前に良いと言われていたものを今見てみるとひどいだろ？ 5年後はどう？って感じるのも事実。
0315デフォルトの名無しさん
2008/12/01(月) 01:15:160316デフォルトの名無しさん
2008/12/01(月) 07:21:260317デフォルトの名無しさん
2008/12/04(木) 14:45:42>これは実際Strategyパターンなのです。 依存性注入は（私の見るところ）基本的にひとまとめに使われるStrategyパターンです。
同意。
0318デフォルトの名無しさん
2008/12/07(日) 17:52:43DI使ってる意味が無いという事が分からない低能が多くて困る
流行ってるらしいからとかって理由だけでDI導入すんな！
0319デフォルトの名無しさん
2008/12/07(日) 18:25:470320デフォルトの名無しさん
2008/12/07(日) 19:21:05一般のプログラマの能力なんて。
0321デフォルトの名無しさん
2008/12/07(日) 21:38:300322デフォルトの名無しさん
2008/12/07(日) 23:24:370323デフォルトの名無しさん
2008/12/07(日) 23:36:21それは、AOPの機能じゃん。
まぁ、AOPのためにDIがあるといってもいいのかもしれないけど。
0324デフォルトの名無しさん
2008/12/07(日) 23:47:49SeasaもSpringも
EJBは知らんけど
0325デフォルトの名無しさん
2008/12/08(月) 00:41:32サービスクラスだけじゃなくて？
0326デフォルトの名無しさん
2008/12/08(月) 01:51:40俺は書かんけど。
0327デフォルトの名無しさん
2008/12/10(水) 12:40:10めんどい。
0328デフォルトの名無しさん
2008/12/10(水) 15:43:35filter挟んだりベースクラスでやるよね。
全部のクラスにコピペする人なんてさすがに見たこと無い
0329デフォルトの名無しさん
2008/12/10(水) 17:26:320330デフォルトの名無しさん
2008/12/10(水) 17:29:43filter は HttpServlet に依存するが、
DI にすることで、HttpServlet に依存しない環境でもログインチェックをすることができる。
たとえば、業務機能は、web 画面でもバッチでも Service クラス の execute() を実装する、
みたいな方針になっているとき。
バッチにも実行ユーザという概念があったときは、filter にせず DI でのやり方にすることで、
web画面でもバッチでも処理方式を統一することができる。
こうしておくと、web 画面の Service クラスのテストを、
Servlet コンテナを立ち上げずに JUnit 等から単体駆動することもできる。
0331デフォルトの名無しさん
2008/12/10(水) 18:18:38DI以前だってベースクラスの一カ所に実装しておくから、
全クラスにコピペするような馬鹿は見たこと無いんだけど、
という事が言いたいんだけど理解してくり
0332デフォルトの名無しさん
2008/12/11(木) 01:58:01AOPでできるとか言うが、AOPの実現手段としてDIがいいってことじゃねぇの？
0333デフォルトの名無しさん
2008/12/11(木) 02:02:12EJB3.0はバランスがよくて好感が持てる。
DAOパターン信者の俺にJPAは少しきついが。
0334デフォルトの名無しさん
2008/12/11(木) 13:08:10処理対象クラスを柔軟に変えたり、
複数の横断的処理をそれぞれ別の対象クラス群に対して実装したいとき
多重継承が出来ないJavaでは限界がある
それを一気に解決出来るのがAOP
AOPがある今では、ベースクラスでそういう処理を実装するのはメンテナンス性が激しく下がるので
なるべく避けるようにしている
0335デフォルトの名無しさん
2008/12/11(木) 14:53:32AOP/DI以前でも>>322が言うように
>全部のクラスに頑張ってログ出力書いたりログインチェック書いたり
するやつがいたのか？って聞いてるんだけど
まあログ出力はステップ実行の無い昔は全部書いたけどさ
0336デフォルトの名無しさん
2008/12/11(木) 15:45:46ログインチェックしないのか？
サーブレットフィルタはAOPじゃないという話か？
運用のためのログ出力は不要か
0337デフォルトの名無しさん
2008/12/11(木) 17:34:540338デフォルトの名無しさん
2008/12/11(木) 17:37:25だからAOPが無い時代にベースクラスでそれをやろうとして
StrutsのActionクラスの継承づくしみたいなボロボロな形になったんだよw
それを今でも続けたいのならずっとそうしてれば？
一緒に仕事をする人は迷惑なだけだろうけど
0339デフォルトの名無しさん
2008/12/11(木) 17:51:31ベースのexecute()でチェックしてからdoExecute()するだけだから
「Actionクラスの継承づくし」みたいなことにはならなかったし
（なったとしても別の問題だし）、Struts/2以降ならfilter/interceptorだし。
それをやらないなんて一度も言ってないだろ。
AOP/DI以前には全クラスにコピペなんてしてたのか？そんなやついないだろって
言ってるだけじゃないか。ま、どうでもいい話題だしどうでもよかとにあん
0340デフォルトの名無しさん
2008/12/11(木) 18:04:48visitor系Actionがあるから
interceptorはAction毎にどれを使用するか指定できるけど
0341デフォルトの名無しさん
2008/12/11(木) 22:50:410342デフォルトの名無しさん
2008/12/12(金) 00:40:430343デフォルトの名無しさん
2008/12/12(金) 00:44:080344デフォルトの名無しさん
2008/12/17(水) 22:43:49AOPを喧伝する人を見かけたら、マトモなOO設計出来ない人なんじゃないかと警戒する。
0345デフォルトの名無しさん
2008/12/18(木) 02:00:120346デフォルトの名無しさん
2008/12/18(木) 08:24:220347デフォルトの名無しさん
2008/12/18(木) 08:35:56>>344は自分しか理解できない仕組みしか作れなかったと言ってるようなもんじゃん
0348デフォルトの名無しさん
2008/12/18(木) 08:51:04「盛んに言いふらすこと。世間でやかましく言いたてること。」
酔った勢いとはいえ、申し訳ない。では！
0349デフォルトの名無しさん
2008/12/18(木) 10:22:59そういうオレオレシステムをフレームワークとして汎用的に提供したと思えばいいんじゃないか？
それすらも嫌なのなら、ご自慢のシステムwもフレームワーク化して世に出してみれば？
0351デフォルトの名無しさん
2008/12/19(金) 00:10:37以前から分散アプリサーバ系の構築をやってきた者からすると、
DIではじめて何かできるようになったというより、以前からできてたことを、
コンテナなしでテストできるようになって便利になったという感想になるのだと思う。
0352デフォルトの名無しさん
2009/03/10(火) 08:40:15(´･ω･｀)ｼｮﾎﾞｰﾝ
http://imepita.jp/20090124/089930
0353デフォルトの名無しさん
2009/04/19(日) 18:20:240354デフォルトの名無しさん
2009/05/17(日) 14:07:47ｵﾔｽﾐ…
＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣
0355デフォルトの名無しさん
2009/05/17(日) 20:35:36ものすごい過疎っぷりだな
0356デフォルトの名無しさん
2009/05/19(火) 18:08:08Z
z
z
＜⌒／ヽ-､_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣
0357デフォルトの名無しさん
2009/06/10(水) 18:10:00やっぱり製品作ってなんぼだな
0358デフォルトの名無しさん
2009/06/11(木) 08:51:300359デフォルトの名無しさん
2009/06/13(土) 04:22:18本番DBとズレが生じて、仕方なく設定ファイルで読み込むクラスが変わるような
仕組みを作ったけど、常に必要ってわけじゃないな。
DIコンテナが喜ばれてるのはDI以外の部分だよね？
インスタンス管理とかトランザクション管理とか。
0360デフォルトの名無しさん
2009/06/13(土) 04:26:540361デフォルトの名無しさん
2009/06/15(月) 02:15:290362デフォルトの名無しさん
2009/07/17(金) 02:07:27使わない方がいいんですか？
そこんとこ教えて下さい。
0363デフォルトの名無しさん
2009/07/17(金) 02:17:180364デフォルトの名無しさん
2009/07/17(金) 02:23:18流行ってるのはなんとなく分かるんですが、色んなサイト見ても何が
いいんだかさっぱり分からないんですよ。
フレームワークを使う事が目的になってる気がしてなりません。
それ以上の価値は、一体どこにあるんでしょう？？
0365デフォルトの名無しさん
2009/07/17(金) 02:28:09お前みたいな屑を兵隊として使えるようになると分かる
0366デフォルトの名無しさん
2009/07/17(金) 03:55:48まあそれは俺を使ってみてから言ってください(笑)
で、何がよくなるんですか？
0367デフォルトの名無しさん
2009/07/17(金) 04:38:35使えるかどうか判断してやるからスペック晒してみろ
0368デフォルトの名無しさん
2009/07/17(金) 05:52:5124歳 ♀
165センチ
45キロ
胸はC
顔は うちの総務の高山さんの若い頃に似てるそうです。
つかえますか？
0369デフォルトの名無しさん
2009/07/17(金) 06:28:270370デフォルトの名無しさん
2009/07/17(金) 12:18:410371デフォルトの名無しさん
2009/07/17(金) 12:42:09まぁスペックなんて晒しても無駄ですよ。
そんなもん所詮こけ脅しにしかならないし。
実力とか応用力とか本当に使えるかどうかなんて実際に
仕事やらしてみるしかないんすよ。
人事なんてそんなもんだと思ってます。
0372デフォルトの名無しさん
2009/07/17(金) 12:48:58何するもん? 使う必要あんの? フレームワークを使うことが
目的になってない? とか訳分からんチラ裏ばっか書くから
google先生がゴミばっか拾って汚染されていく。
0373デフォルトの名無しさん
2009/07/17(金) 13:05:42必要ないなら使わないのは当然ですが、必要性をお教え頂きたいのです。
依存性の注入とか言いますが、結局は設定ファイルを簡単に読み込む
ためのものなんですか？
それを単純に文字列の値からオブジェクトにまでしたもの？？
0374デフォルトの名無しさん
2009/07/17(金) 14:07:17> 実力とか応用力とか本当に使えるかどうかなんて実際に
> 仕事やらしてみるしかないんすよ。
もう十分わかったよ。お前は使えないから消えろ。
0375デフォルトの名無しさん
2009/07/17(金) 14:21:13DI にこだわる意味を教えてもらうまではいるぴょーん
0376デフォルトの名無しさん
2009/07/17(金) 14:23:29ヌルーの季節ですな
0377デフォルトの名無しさん
2009/07/17(金) 14:27:05何が便利かは人によって違う。
スパコンの計算能力が不要な人にスパコンの価値は理解できない。
DIも同じ。HelloWorldしか作ってないやつにDIの価値は理解できない。
0378デフォルトの名無しさん
2009/07/17(金) 14:45:19いや…なんて言うんですかね、つまり、特定の状況では DI コンテナ
なしで開発するよりも DI コンテナありで開発した方が効率がいいと
皆さん考えている訳ですよね？
その状況を知りたいのです。
どういう時ですか？？ もうプロジェクト全部？文句なしで？
だったら、次のプロジェクトで試しに使ってみようと思ってます。
0379デフォルトの名無しさん
2009/07/17(金) 15:03:10クラス入れ替えが便利になる程度。真正面からDIを勉強するとそういう説明ばっかで
あまりメリットが見えてこない。
みんなが便利に使ってるのはDIコンテナが持ってる機能で、例えばオブジェクトを
インジェクトするときにちょこっと書き換えてAOPでトランザクション管理やらせたり、
インスタンスの生成管理をコンテナにさせてソースの記述量が減ったり、そういうこと。
0380デフォルトの名無しさん
2009/07/17(金) 20:58:42マネジメントできずに下手なPGになんでもインジェクションされて終わり
0381デフォルトの名無しさん
2009/07/17(金) 22:12:140382デフォルトの名無しさん
2009/07/17(金) 22:50:45guiceくらいが一番バランスいいかもしれんが。
0383デフォルトの名無しさん
2009/07/18(土) 00:01:22ふむふむ…。
なんだか複雑な事情ですね。
まぁ一回使ってみりゃ分かるんですかねぇ。
でも納期が８月末のプロジェクトなんで、ちょっと冒険する気に
ならないな…………。
0384デフォルトの名無しさん
2009/07/18(土) 00:35:27だから、使わないほうがいいと思うよ。
0385デフォルトの名無しさん
2009/07/18(土) 00:56:15でもそれって「フレームワーク」の思想に反するんじゃないんですかね？
フレームワークの上に乗っかって作業してりゃあバカでも恩恵に与れる
のがフレームワークってもんなのでは？？
0386デフォルトの名無しさん
2009/07/18(土) 01:22:320387デフォルトの名無しさん
2009/07/18(土) 01:41:450388デフォルトの名無しさん
2009/07/18(土) 02:38:430389デフォルトの名無しさん
2009/07/18(土) 04:04:54しようと思っています。
この場合、DIするためにActionクラスにインスタンス変数を
持たなければならないのですが、この変数はスレッドセーフで
動作するのでしょうか？
しないならば、どのような解決策が考えられるでしょうか？
どなたかお知恵のある方、ご解答よろしくお願いします。
0390デフォルトの名無しさん
2009/07/18(土) 13:50:17Actionにステートフルなコンポーネントをインジェクトしたいと言うこと？
それは設計としてまずいような気がするが。
0391390
2009/07/18(土) 13:52:440392389
2009/07/19(日) 00:30:18期日が迫っている作業なのであせっていました。
どうやら変数のスコープをプロトタイプにしたところ
hashCodeが異なる値で取得出来たので問題なさそうです。
ありがとうございました。
名言集 その２
『お前が規制系キャップ取れるか審査してやるよ』
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/
にて自動焼人 ★までご連絡ください
0394デフォルトの名無しさん
2009/11/29(日) 18:23:570395デフォルトの名無しさん
2010/01/03(日) 13:48:33おそらく、2010年も過疎進行でいくと思う。
0396デフォルトの名無しさん
2010/01/06(水) 04:21:390397デフォルトの名無しさん
2010/01/06(水) 21:20:180398デフォルトの名無しさん
2010/01/07(木) 10:17:340399デフォルトの名無しさん
2010/01/07(木) 22:44:22WebBeansの頃から空気だろ
0400デフォルトの名無しさん
2010/01/09(土) 05:03:49CDIのせいで一番最初に滅びるのはEJBだが。
0401デフォルトの名無しさん
2010/01/09(土) 08:54:160402デフォルトの名無しさん
2010/01/09(土) 13:53:11CDIはTomcat6で今でも動いてるよ
JavaSEでも動いてSwingのコンポーネントに使えるサンプル付属してるくらい
0403デフォルトの名無しさん
2010/01/09(土) 14:42:50Tomcatが「標準装備」するようになったら、だろ
自分でライブラリ突っ込めば動くってんじゃ誰も使わんよ
俺はTomcatが標準装備してもCDIが流行るとは思わんけどな
0404デフォルトの名無しさん
2010/01/09(土) 15:33:460405デフォルトの名無しさん
2010/01/09(土) 15:47:34EJB3だって流行ってないだろ？3.1だって流行らないよ
理由なきJavaEEアレルギーはまだまだ根強い
0406デフォルトの名無しさん
2010/01/09(土) 16:01:540407デフォルトの名無しさん
2010/01/09(土) 16:11:060408デフォルトの名無しさん
2010/01/17(日) 11:42:250409デフォルトの名無しさん
2010/01/18(月) 06:45:590410デフォルトの名無しさん
2010/01/19(火) 17:07:410411デフォルトの名無しさん
2010/10/04(月) 04:35:34気に入らない人はまだまだ居そうだけど。
0412ななし。
2011/07/27(水) 19:32:41.180413デフォルトの名無しさん
2011/10/26(水) 20:17:30.57■ このスレッドは過去ログ倉庫に格納されています