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

**デフォルトの名無しさん** · 2008/08/20(水) 23:23:26

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

**デフォルトの名無しさん** · 2008/08/20(水) 23:42:55

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

**デフォルトの名無しさん** · 2008/08/22(金) 00:40:41

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

**デフォルトの名無しさん** · 2008/08/22(金) 01:57:47

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

**デフォルトの名無しさん** · 2008/08/22(金) 05:09:45

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

**デフォルトの名無しさん** · 2008/08/22(金) 10:44:21

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

**デフォルトの名無しさん** · 2008/08/23(土) 15:43:06

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

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

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

**デフォルトの名無しさん** · 2008/08/23(土) 23:57:34

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

**デフォルトの名無しさん** · 2008/08/24(日) 02:25:07

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

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

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

**デフォルトの名無しさん** · 2008/08/24(日) 10:39:57

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

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

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

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

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

**デフォルトの名無しさん** · 2008/08/24(日) 12:58:04

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

**デフォルトの名無しさん** · 2008/08/24(日) 13:05:54

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

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

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

**デフォルトの名無しさん** · 2008/08/24(日) 13:18:46

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

**デフォルトの名無しさん** · 2008/08/24(日) 13:36:21

>>15
確かに

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

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

**デフォルトの名無しさん** · 2008/08/24(日) 13:48:19

>>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メソッドを持っていれば何でもいい)
となるので、リスナーみたいなインターフェースはまとめて削減できそう。

16 · 2008/08/24(日) 13:49:56

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

**デフォルトの名無しさん** · 2008/08/24(日) 15:00:05

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

**デフォルトの名無しさん** · 2008/08/24(日) 16:40:09

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

**デフォルトの名無しさん** · 2008/08/24(日) 18:38:55

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

**デフォルトの名無しさん** · 2008/08/24(日) 19:30:53

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

**デフォルトの名無しさん** · 2008/08/24(日) 19:42:31

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2008/08/24(日) 21:17:10

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

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

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

**デフォルトの名無しさん** · 2008/08/25(月) 01:06:47

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

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

**デフォルトの名無しさん** · 2008/08/25(月) 08:03:17

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

**デフォルトの名無しさん** · 2008/08/25(月) 21:35:10

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

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

**デフォルトの名無しさん** · 2008/08/25(月) 22:17:32

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

**デフォルトの名無しさん** · 2008/08/25(月) 22:59:07

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

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

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

**デフォルトの名無しさん** · 2008/08/26(火) 03:55:28

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

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

**デフォルトの名無しさん** · 2008/08/26(火) 21:52:13

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

**デフォルトの名無しさん** · 2008/08/26(火) 22:29:25

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

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

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

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

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

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

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

（ﾏな内容でｽﾏｿ）

34 · 2008/08/26(火) 22:38:15

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

**デフォルトの名無しさん** · 2008/08/26(火) 23:19:54

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

**デフォルトの名無しさん** · 2008/08/26(火) 23:59:18

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

**デフォルトの名無しさん** · 2008/08/27(水) 00:18:53

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

**デフォルトの名無しさん** · 2008/08/27(水) 00:24:48

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

**デフォルトの名無しさん** · 2008/08/27(水) 00:28:08

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

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

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

**デフォルトの名無しさん** · 2008/08/27(水) 00:36:09

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

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

**デフォルトの名無しさん** · 2008/08/27(水) 01:11:47

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

34 · 2008/08/27(水) 02:04:26

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

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

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

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

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

**デフォルトの名無しさん** · 2008/08/27(水) 02:27:13

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

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

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

**デフォルトの名無しさん** · 2008/08/27(水) 21:26:50

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

**デフォルトの名無しさん** · 2008/08/27(水) 22:58:15

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

**デフォルトの名無しさん** · 2008/08/28(木) 00:32:17

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

**デフォルトの名無しさん** · 2008/08/28(木) 01:32:59

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

**デフォルトの名無しさん** · 2008/08/28(木) 06:20:19

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

**デフォルトの名無しさん** · 2008/08/28(木) 06:42:56

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

**デフォルトの名無しさん** · 2008/08/28(木) 08:15:02

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

**デフォルトの名無しさん** · 2008/08/28(木) 19:54:11

人は流れに乗ればいい

**デフォルトの名無しさん** · 2008/08/28(木) 22:50:00

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

**デフォルトの名無しさん** · 2008/08/29(金) 01:48:31

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

**デフォルトの名無しさん** · 2008/08/30(土) 01:50:09

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

**デフォルトの名無しさん** · 2008/08/30(土) 19:32:22

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

**デフォルトの名無しさん** · 2008/08/31(日) 14:28:16

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

**デフォルトの名無しさん** · 2008/08/31(日) 16:20:22

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

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

**デフォルトの名無しさん** · 2008/08/31(日) 16:37:08

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

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

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

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

**デフォルトの名無しさん** · 2008/08/31(日) 17:09:36

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

**デフォルトの名無しさん** · 2008/08/31(日) 20:56:39

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

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

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

**デフォルトの名無しさん** · 2008/08/31(日) 21:09:44

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

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

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

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

**デフォルトの名無しさん** · 2008/08/31(日) 23:50:23

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

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

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

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

**デフォルトの名無しさん** · 2008/08/31(日) 23:57:13

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

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

**デフォルトの名無しさん** · 2008/09/01(月) 00:04:32

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

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

**デフォルトの名無しさん** · 2008/09/01(月) 00:29:30

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

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

**デフォルトの名無しさん** · 2008/09/01(月) 00:40:51

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

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

**デフォルトの名無しさん** · 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でトランザクション管理しない
っていうのが徹底されてるのが効いてるのかな。

**デフォルトの名無しさん** · 2008/09/01(月) 09:45:29

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

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

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

69 · 2008/09/01(月) 09:47:40

続き。

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

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

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

**デフォルトの名無しさん** · 2008/09/01(月) 10:06:33

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

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

**デフォルトの名無しさん** · 2008/09/02(火) 00:22:13

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

**デフォルトの名無しさん** · 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

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

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

**デフォルトの名無しさん** · 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が有効か。

69 · 2008/09/02(火) 09:21:14

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

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

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

**デフォルトの名無しさん** · 2008/09/02(火) 09:30:42

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

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

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

**デフォルトの名無しさん** · 2008/09/02(火) 12:15:15

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

**デフォルトの名無しさん** · 2008/09/02(火) 16:36:26

なんですとぉ！？

**デフォルトの名無しさん** · 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 を書こう。
今大人気だから覚えといて損はないよ

**デフォルトの名無しさん** · 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っぽいコード
ああ、見てるとイラッと来る
自分も一度は通った道ではあるものの

**デフォルトの名無しさん** · 2008/09/07(日) 00:55:05

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

**デフォルトの名無しさん** · 2008/09/07(日) 02:25:30

激しくスレ違い

**デフォルトの名無しさん** · 2008/09/07(日) 11:46:30

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

**デフォルトの名無しさん** · 2008/09/07(日) 21:13:24

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

**デフォルトの名無しさん** · 2008/09/14(日) 21:08:26

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

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

**デフォルトの名無しさん** · 2008/09/14(日) 21:11:59

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

**デフォルトの名無しさん** · 2008/09/14(日) 21:15:24

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

**デフォルトの名無しさん** · 2008/09/14(日) 21:22:13

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

**デフォルトの名無しさん** · 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なんて実行時に今までやっていたことを設計時に限定する代わりに
設定ファイルで簡単に記述できるようにしただけだよね。
言語使用でサポートするとしたらどうなるのかな。

**デフォルトの名無しさん** · 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

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

**デフォルトの名無しさん** · 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

楽くね？
くねくね？

**デフォルトの名無しさん** · 2008/09/17(水) 05:05:33

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

**デフォルトの名無しさん** · 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

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

**デフォルトの名無しさん** · 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の有用さが理解出来ない奴は、これまでテストをきちんとやって来なかった奴だな

**デフォルトの名無しさん** · 2008/09/20(土) 18:30:26

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

**デフォルトの名無しさん** · 2008/09/20(土) 22:18:01

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

**デフォルトの名無しさん** · 2008/09/20(土) 23:12:38

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

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

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

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

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

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

用途はたくさんあるぞ。

**デフォルトの名無しさん** · 2008/09/21(日) 09:43:26

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

**デフォルトの名無しさん** · 2008/09/23(火) 01:45:47

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

**デフォルトの名無しさん** · 2008/09/23(火) 02:17:20

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

**デフォルトの名無しさん** · 2008/09/23(火) 06:00:48

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

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

**デフォルトの名無しさん** · 2008/09/23(火) 12:02:46

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

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

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

**デフォルトの名無しさん** · 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（よほど恨みでもあるのか？）の説得方法とかさ。