Dependncy Injectionを語るスレ

Dependncy Injectionを語るスレ at TECH

1:デフォルトの名無しさん
04/11/07 20:32:05
依存性注入ということらしい。IoCともいわれる。
最近注目を集めているがその是非を論じてみよう。

参考
URLﾘﾝｸ(cvs.picocontainer.codehaus.org)
URLﾘﾝｸ(www.kakutani.com)

2:デフォルトの名無しさん
04/11/07 20:40:01
Java製DIコンテナ

Spring Framework
URLﾘﾝｸ(www.springframework.org)

PicoContainer
URLﾘﾝｸ(www.picocontainer.org)

HiveMind
URLﾘﾝｸ(jakarta.apache.org)

Seasar2
URLﾘﾝｸ(www.seasar.org)

3:デフォルトの名無しさん
04/11/07 20:46:16
RubyでDIという記事
URLﾘﾝｸ(jp.rubyist.net)

上記の記事に出てないRuby製DIコンテナ
URLﾘﾝｸ(homepage1.nifty.com)

4:デフォルトの名無しさん
04/11/07 20:48:53
関連ありそうなスレ

Java Spring Frameworkを語るスレ
ｽﾚﾘﾝｸ(tech板)

国産DIコンテナSeaserとくーすその2
ｽﾚﾘﾝｸ(tech板)

5:デフォルトの名無しさん
04/11/07 21:03:45
.NET版DIコンテナ

Spring.NET
URLﾘﾝｸ(www.springframework.net)

Dosanko
URLﾘﾝｸ(cvs.sourceforge.jp)

Kodama
URLﾘﾝｸ(sourceforge.jp)

6:デフォルトの名無しさん
04/11/07 21:18:33
補足

PicoContainerにはRuby版と.NET版もあり。
PHP版のDIコンテナを作るというのもどこかで見かけた。

7:デフォルトの名無しさん
04/11/07 22:15:50
結論
　EJB3.0で決まり

8:デフォルトの名無しさん
04/11/07 22:51:16
EJB3.0ってDIコンテナになるの？

9:デフォルトの名無しさん
04/11/08 00:24:44
>>3
Needle つかったことないけど。
URLﾘﾝｸ(rubyforge.org)

10:デフォルトの名無しさん
04/11/08 16:59:38
Pythonのものはないかと探して見つけたもの

PyContainer
URLﾘﾝｸ(www.pycontainer.glt.pl)

11:デフォルトの名無しさん
04/11/08 17:15:14
Dependency Injection in Ruby
URLﾘﾝｸ(onestepback.org)

12:デフォルトの名無しさん
04/11/08 17:16:07
色々とあるもんだなー。
Perlはないのかな？

13:デフォルトの名無しさん
04/11/08 18:51:20
IOC - A lightweight IOC (Inversion of Control) framework
URLﾘﾝｸ(search.cpan.org)

14:デフォルトの名無しさん
04/11/08 19:03:11
おーPerlだ。㌧ｸｽ
スクリプト系でもDIって流行ってきてるんだね。
Javaだけってわけじゃないんだ。

15:デフォルトの名無しさん
04/11/09 05:58:21
で、DIって具体的にどういう的に便利なの？
・小規模...わざわざxmlに定義するよりPOJOでやった方が簡単
・大規模...インスタンスの生成管理したいので大部分では使わない
　→ソース追いづらくなるしDI使わないに統一した方がいい
・中規模...ウォーターフォールでインターフェースを決め打ちできる
　＆インスタンスが始めから無駄に一個ずつ生成されていてもどうでもいい
　程度の規模ならメリットあり

って感じ？あ、こういうのもあるね。
・中規模...設計がわかった気になった厨くんの自己満足に最適
現場の人間のモチベーションは大事だからね

16:デフォルトの名無しさん
04/11/09 06:05:50
規模にかかわらず、OOPの真のメリットが理解出来ない人達(残念ながら結構いるよね)を
束ねて開発する際に、始めに指針をきちんと提示してあげればソースの綺麗さを
ある一定の水準に保てることかな。

ちゃんとしたOOPとOOPモドキが混じったソースは汚いことこの上ないからね。
全部構造化設計で共通処理をちゃんとサブルーチン化して、あとは
システムが処理する順番通りに記述していった方がはるかにマシ。
前時代的だけど。

17:デフォルトの名無しさん
04/11/09 10:05:18
>>15
>大規模...インスタンスの生成管理したいので

これが大変だからDIコンテナ使うんじゃ？
インターフェースによる設計が強制されるし。

18:太田＠会社
04/11/09 11:01:45
15さん>
どんな規模でもユニットテストを厳密にしようと思ったら有効化と。
単体テストの網羅率が低いプログラムを4年もメンテしたら考えが変わりますよ。

19:デフォルトの名無しさん
04/11/09 11:41:20
>>15
> わざわざxmlに定義するよりPOJOでやった方が簡単

DIで使うのはPOJOなんだけど。
あと、わかんないなら、StrutsとHibernate使うときになんか便利とか、その程度で最初はいいと思う。
基本的にはある種のパラダイムシフトだから、やってみないことにはメリットは実感できないよ。
やらないうちは、ファクトリ書くのとどう違うの？って感じだけど。

「DIってどういうときに便利なの？」っていうのは「オブジェクト指向ってどういうときに便利なの？」という問いがばかげてるのと似てる。

20:デフォルトの名無しさん
04/11/09 11:46:36
>>18
DI使わないで書いてますので間違ってる所はバンバン指摘してくださいね。

DI使うと単体検査の網羅率が変わるんですか？
どの項目になにを入力したらエラーになる、というのは
結局人が書かないといけないと思うのですが。

太田さんが言われてるのは趣味の延長でやっているような
検査仕様書といえば正常系の画面遷移くらいしか記述しないような
人たちのことを言っていますか？

あえていえば、xmlファイルでクラス名やメソッド名を書き間違えると
実行時クラスキャストエラーになってプログラムが停止してしまうので
最低限一通り正常処理は通しておかないと目も当てられない、
というのはあるかと思いますが、ってこれは極端か。

21:デフォルトの名無しさん
04/11/09 11:58:02
> DI使うと単体検査の網羅率が変わるんですか？
> どの項目になにを入力したらエラーになる、というのは
> 結局人が書かないといけないと思うのですが

単体検査をやりやすくなるので、網羅率が間接的に変わるかも。
オブジェクトとオブジェクトを結びつけるためだけのコードも減るので、やっぱり網羅率はあがるかも。
ただし、Javaコードの網羅率があがっても、DI定義の網羅率は低いことが多いので、トータルでは変わってないかも。
DI定義のテストをどう考えるか、というのは問題のひとつだと思う。

> xmlファイルでクラス名やメソッド名を書き間違えると
> 実行時クラスキャストエラーになってプログラムが停止してしまうので

該当クラスがないときは、DI定義の読み込み時でエラーになるコンテナが多いので、クラス名の間違いに関してはあまり問題なさそう。
あと、現実問題として、最初のひとつのオブジェクトを読み込むとあとは芋づる式にインジェクションされたオブジェクトを取得するので、クラスのキャストエラーというのも実は心配するほどもない。
Container.getInstance("name")みたいなことをすることは結構少ない。
ということで、やっぱ極端かと。
テストしろよ、という話でもあるし。

22:デフォルトの名無しさん
04/11/09 11:59:53
>>19

なるほど、言われてみれば確かにポインタを初めて勉強したときも、
ポインタのポインタや関数ポインタの話を聞いたときも、実際に
やってみるまで「なんのためにそんなことをするのか」わからなかった。
TemplateMethodパターンもAbstractProductはともかく、AbstractFactoryクラスまで
抽象化する意味が始めはよくわからなかった。

やってみろというのはその通りだ。でもメリットもわからないうちから
業務には適用できないし(してるアホもいるけどね)、なんか作ると便利なモノないかな。

どうせ時間かけるなら、その時間をOOのスキルアップに使った方が
いいような気がしてDIの勉強に本腰が入らないんだよね。

23:デフォルトの名無しさん
04/11/09 12:35:48
>>22
「OOのスキルアップ」が足りてないなら、そっちやったほうがいいのかもしれないけど、DIの勉強って、はっきりいってすることないから、ちょっと試しに何か使ってみればいい。
勉強っていっても、ほんとDIってsetXxxメソッド用意して<property name="xxx"><value>aaa</value></property>書くだけで、その文法とコンテナの準備が違うだけだし。
で、これ見ても「だから何？」なんだけど、やってみるとその「だから何？」のためにコードをたくさん書かされていたことに気づく。

24:デフォルトの名無しさん
04/11/09 12:38:54
コンポーネントの再利用って、DI使わないときには、OOの技術やらデザインパターンの知識と有効活用が必要で、ちょっとキバらないといけないと思うんだけど、DI使うと、システムの一部分がなぜかどこでも使えるようになってたりするから不思議。

25:22だけど
04/11/09 13:00:00
スキルアップが足りてると思ったら技術者として終わりだよね・・

26:デフォルトの名無しさん
04/11/09 13:14:47
誰も>>1の綴り間違いに気づかない

27:デフォルトの名無しさん
04/11/09 13:14:57
技術的な面での知識をつける事は勿論スキルアップだけど
マネジメントの視点から開発効率を考えて
より合理的な方法を探るのも立派な「スキルアップ」だと思うよ。

と自分にも言い聞かせてますけど。
>15の「設計がわかった気になった厨くんの自己満足に最適」
ってのは、ちょっと耳が痛いですなー。

28:デフォルトの名無しさん
04/11/09 13:58:53
>22自己レス
TemplateMethodじゃなくてFactoryMethodだね

29:１
04/11/09 14:30:33
>>26
>>1の母です。この度は…

スマソ言われるまで気付かなかった。
回線切って首吊って逝ってくる。

30:太田＠会社
04/11/09 14:47:54
えーとすでに21さんが書かれていますが，
DIによって，依存性を分離すると，
より小さな要素のレベル(サブシステム→クラスの集合→クラス→メソッド)で，
高い網羅率を可能にすることができるということです。

FactoryとかSingletonとかFacadeとかを使いこなしても，
やはりクラスの依存関係が密になってしまって(色々回避するためのパターンはありますが)，

結果的に結合テストでえいやっってことになってしまっているのを
自分が関わった仕事を含めたびたび見てきたということです。

31:デフォルトの名無しさん
04/11/09 14:51:49
なんかどんどん色々なものが生まれてくるね。ついてゆけないや。

32:デフォルトの名無しさん
04/11/09 14:52:28
順調に伸びてまつね、このスレ。

33:デフォルトの名無しさん
04/11/09 15:03:20
>>22
DIってOOのパターンのひとつっぽい感じだと思う。
別に仕事でどうこうとか難しいことを考えなくても
簡単なサンプルをいくつか作るだけでも随分と印象が
変わる。

実は漏れもそうで最初またウザイフレームワークかと
思ったんだけど、結構目からウロコというか新鮮だった。
もちろん別の手間が増えるというのはあるんだけどね。
interfaceをしっかりと考えるとかさ。

ちょっと新しいOOのトレンドとして捉えて触ってみても
損は無いと思うよ。

34:デフォルトの名無しさん
04/11/09 15:40:29
DIって何なの？
DIなんて聞いた事も分からない漏れにも分かるように説明キボンヌ

35:デフォルトの名無しさん
04/11/09 15:40:53
Do It

36:デフォルトの名無しさん
04/11/09 15:42:37
スレタイと違うじゃんよ

37:デフォルトの名無しさん
04/11/09 16:12:24
Direct Injection

38:デフォルトの名無しさん
04/11/09 16:15:15
スレタイと違うじゃんよ

39:デフォルトの名無しさん
04/11/09 16:18:35
ていうか>>1のリンク先は読んだ？

40:デフォルトの名無しさん
04/11/09 16:57:17
実際にはDIはAOPと一緒に使って新しいパラダイムという感じになるし、実際DIだけだと単に便利なだけなので、スレタイにAOPを含めなかった1を少し恨む。

41:デフォルトの名無しさん
04/11/09 18:11:45
AOPは
ｽﾚﾘﾝｸ(tech板)
で語ることになってるのかと。

>15
ユニットの抽象化、ブラックボックス化が進むのが利点かと。
大規模開発する時、ここの作業領域が明確になって
分業が進むのが素敵チックに思います。
XMLで必死に定義書きまくるのはどうなんだといわれりゃその通りですが
結合を疎に持ってく方向自体は間違ってないかと。

42:デフォルトの名無しさん
04/11/09 18:30:01
AOPはAOPだけではどうしようもないし、DI+AOPではじめて両者の本当のメリットが得られると思うんだよね。

43:デフォルトの名無しさん
04/11/09 18:39:26
ほならスレタイなぞ気にせず語ってしまえばよいですよ。

44:デフォルトの名無しさん
04/11/09 18:55:11
語りにくいけど、そうする。
やっぱり、2chってスレタイと1の文は大事なんだよね。

AOPはDIあってこそだし、DIはAOPのためにあると思う。
AOPとして語られる横断的な関心事って、処理のことがとりあげられるけど、さまざまなオブジェクトで必要になるオブジェクトを横断的な関心事と考えると、DIはそれを織り込む仕組みになる。

45:デフォルトの名無しさん
04/11/09 21:12:15
ＰＯＪＯって何だ？
ただの普通のクラスと何が違うんだ？

46:デフォルトの名無しさん
04/11/09 21:39:02
むしろ、普通のクラス。
なにか特定のインターフェイスの実装やらクラスの継承を義務づけられてないということ。
だから、RMIのリモートオブジェクトとか、EJBとか、StrutsのActionとかActionFormはPOJOじゃない。

47:デフォルトの名無しさん
04/11/09 22:47:33
>>30
するってえと太田さんところでは単体検査とは本当にユニット単位で
検査すること(JUnitで出来るようなこと)であって、機能毎にプログラムの
分岐を現実的な範囲内で網羅するような試験ではないって事ですかね。
だとすると私とは前提が違うのでかみ合わないわけですね。

まあもともとDIに興味を持ったからこそいろいろ聞いているわけだけど、
調べていくうちに「なんかなー、いまいち手間に比べてメリットが薄い気がするなー」
というのが正直なところなわけですよ。メリットがあるのはわかるんだけど。
で、みんなにメリットを語ってもらおうと思って質問するんだけど、まだピンと来ない。

EclipseにSpringプラグインをいれたらxmlの定義を書いてるときもコード補完で
型検索とかできるの？

48:デフォルトの名無しさん
04/11/09 22:49:10
(Springのスレ違から誘導されてきました)

PicoConatiner 1.1出ました。
URLﾘﾝｸ(www.picocontainer.org)

49:デフォルトの名無しさん
04/11/09 23:05:27
>>47
> 本当にユニット単位で検査すること(JUnitで出来るようなこと)

と

> 機能毎にプログラムの分岐を現実的な範囲内で網羅するような試験

って具体的にどう違うの？
後者はJUnitでは出来ないことなんだよね？

50:49
04/11/09 23:06:18
>>47
DIだけ見てて、AOPを見てないとか？

51:デフォルトの名無しさん
04/11/10 00:10:47
スレタイが「Dependency Injectionコンテナを語るスレ」だったら
AOPの話題もスレ違いにならなかった罠。

52:デフォルトの名無しさん
04/11/10 00:17:47
>>47は以下のような依存関係を持つコンポーネントの単体テストを
どうやって実行してるんだろうか。

プレゼンテーション層のコントローラ
↓
ドメイン層のサービス
↓
データソース層のDAO

そもそも「そんな層分割は知らん」とか「一気通貫目視に決まってんだろ」とか
言うんだったら勉強して出直して来い。

「Mockで依存関係を切ってカバレッジ確保してます」ということならまずそこが
DIコンテナの出番。

53:かくたに
04/11/10 00:21:17
>>51
AOPはスレ違いじゃないと思います。
URLﾘﾝｸ(www.kakutani.com)
>今のところ、本記事ではアスペクト指向については考慮していないが、今後追加するなり、
>他の記事を書くなりして、是非とも取り組んでみたいと思っている。

54:デフォルトの名無しさん
04/11/10 00:33:54
どーでもいいが、太田君もかくたに君(お子さん誕生おめでとう)も
トリップつけなさい。

URLﾘﾝｸ(info.2ch.net)

55:デフォルトの名無しさん
04/11/10 00:59:42
>>49
うちの単体は機能単位でできることは出来るだけ網羅したい感じ。
画面遷移して前画面のパラメータも引きずってくるし、桁あふれを
狙うような無茶をするのも単体。テストデータはあまり厳密じゃない。
外部モジュールとは結合しないので代わりにエミュレーターを立てたりする。
JUnitでも頑張ってシナリオ持たせればできそうだけど、そうすると
今度はTestクラスの設計から始めないと、って感じじゃない？

結合検査は外部とも実際に繋ぐし、ログインからはじめて実際にあり得そうな
画面遷移のシナリオをいくつも用意してテスト。

ちっちゃい会社だから品質検査会社にテスト外注するわけでもないし、
この後はもうユーザーテストだけ。ユーザーテストでバグ出したくないから、
それぞれの重みはこうなっちゃうよ。場合によっちゃ客前で結合を
もう一回やるだけの事もあるし。
一般的なシステム会社から見たら単体の比重が大きいのかな？
ユーザーの前で単体テスト並のバグだしをする小さな会社も見てきたけど。

AOPのメリットはDIコンテナいれなくても享受できるでしょ。
AOPはDIとは別に見てる。AspectJとかちょこっといじってたし。
EclipseでTomcatプロジェクトと共用できなくて業務では使ってない。
AJDT入れると他のプラグインが挙動不審になったりしたし。

とまあこうしてスレの主題から脱線していくわけだが

56:デフォルトの名無しさん
04/11/10 01:14:33
>>52
このスレで続けていいのかな？ちょっと気がひけるけど。
うちはそもそもJUnitをまだ開発プロセスとして取り込んでない。
テスト項目漏れをチェックする基準がよーわからんから。
何回か導入すればノウハウも出てきてそれなりのクオリティで
検査できるようになるとは思うけど、お金もらって実験するほど
仕事なめてないから。胸張って導入できるほどの調査時間がとれない。
ただ、導入したいとは常々思ってる。

「それは一気通貫目視だからとっとと出直してこい」というなら
是非とも勉強したいので参考URLおせーて。その層は知ってるよ。
知ってるっていうよりjspでMVCモデル2とか言う言葉が出てくる前に
PACとかn層と実案件の関係を考えていて、n層の中でMVCでいうところの
Modelが機能(今でいうサービス？)、ユーティリティ、ドメインオブジェクト、dao
にわけたらキレイになるかなーとかやっていたので、その層はすんなり入ってきていた。
「Mockでカバレッジ」っていうのはわからん。

57:デフォルトの名無しさん
04/11/10 01:19:46
>>52
ちなみにURLおせーて、っていうのは依存関係を持つコンポーネントの単体テストを
JUnitでわかりやすく実施するサンプルとかのことね。
でもコントローラーからdaoまでだったら、たとえばWebアプリなら普通に
URLのGETパラメータに情報載せてセッション帰ってきたらDBにアクセスして
値確認すればいいだけのような気がするけど、違うの？

58:１
04/11/10 01:23:12
すみませんすみません。DI+AOPもアリといういうことでお願いします。

AOP単独だとAspectJみたいな話になるし、そうすると別スレのほうが
いいのかなとか思ったりしますが、皆さんのご判断にお任せします。

初めてスレ立てしたので、気が回りませんでした。
回線吊って首切って逝ってきます。

>>48
ｵﾒ!

59:デフォルトの名無しさん
04/11/10 01:26:35
>>55
> AspectJとかちょこっといじってたし。
> EclipseでTomcatプロジェクトと共用できなくて業務では使ってない。
> AJDT入れると他のプラグインが挙動不審になったりしたし。

> AOPのメリットはDIコンテナいれなくても享受できるでしょ。

享受できてないじゃんｗ

60:デフォルトの名無しさん
04/11/10 01:30:29
連書きスマン
>依存関係を持つコンポーネントの単体テストをJUnitで

逆か。依存関係を切ったままJUnitでテストしろって話ね。
まあコントローラーでエラーになることは無いから(なったらテストクラスの
パラメータが足りないって事だから)Modelの段階でのエラーと
daoの段階でのエラーを分けて管理しろという事ですか。うーん、やっぱり
出直して勉強してきた方がいいみたいだけど、どのサイトorどの本を読めばそのメリットがわかる？

61:デフォルトの名無しさん
04/11/10 01:33:36
>>59
えーっと、俺が享受してたかどうかじゃなくて、DIに時間を割くべきかどうかの判断に
AOPは含まないよ、DI無しでAOPだけ導入することもできるから、って言いたかったんだけど
っていうか細かいツッコミにいちいち反応するなよ＜俺って感じ？

#これだけ書く時間があったらDIのサンプルぐらい動かせそうだな・・

62:デフォルトの名無しさん
04/11/10 01:35:33
>>56
JUnitをいままでのテストを置き換えるものとしてとらえなくてもいいんじゃない？
むしろ、プログラマがプログラムが動いて自分の作業が完了したというためのものという感覚で。
いままでなら「コンパイルが通っただけでできたっていうなバカ、動作テストしたのか？」っていうところを、「ユニットテスト作ったのか？」っていう感じで。

63:デフォルトの名無しさん
04/11/10 01:42:18
>>61
いや、>>55の書いていたような理由から、だれも実業務でAspectJなんか使えないし、つまりAOP使えてなかったんでしょ。
ほんとにAspectJでAOPだけ導入ができると思う？
で、DIコンテナですよ、と。
結局DIコンテナを評価するべきで、SpringとかSeasarとかはデータベース抽象化機能を提供してて宣言的トランザクションが使えて、と。
実際問題、DIコンテナは、宣言的トランザクションが気軽に使える仕組みだと最初はとらえていいんじゃないかと思ったりする。

64:63
04/11/10 01:48:00
と勢いだけで書いてみたけど、AspectJで実際にシステム組んでるところってあるのかな？
パイロットプロジェクトという意味合いではなく。

65:かくたに ◆572YBhdE/s
04/11/10 01:53:05
>>54 ありがとうございます。コテハンといっても基本ヲチなので捨てハンみたいなもんだからトリップ無用かな、と。
# とりあえずつけてみるテスト

AOP単体での導入はまんどくさいし、ニュータイプならぬPOJD(Plain Old Java Developer)には
見通し的に辛い。S2の文脈(というか他はまともには知らない)でのAOP適用は、
AOP的には邪道かもしれないけれど、DIと抱き合わせでついてくるし、コンポーネントに適用する、という
POJDに優しい枠組はうれしい。以上まとめると、63に禿同。

66:デフォルトの名無しさん
04/11/10 01:58:35
>>62
まーねー、それもそうなんだけど。折を見てみんなでやってみますわ。
でも新技術に積極的な人いないから、結局俺が使い方ちゃんと教えられるほど
になるまでノビノビ～というパターンだな。

>>63
AspectJが駄目だからDIコンテナをAOP込みで評価しろってことね。それもそだね。
そこで教えて欲しいんだけど、メソッドのin/outでトレースログを吐く以外に
どんなメリットがあるの？よくトランザクション管理が楽なんて見かけるんだけど、
マルチスレッドの時どうやって自分のトランザクションを取得するの？
今までのjdbcなら
Connection con = pool.getConnection();
con.setAutoCommit(false);
DaoTable1 dao1 = new DaoTable1(con);
dao1.update();
DaoTable2 dao2 = new DaoTable2(con);
dao2.update();　...(1)
con.commit();

なんていう風にやっていて、AOPだとconを持ち回らなくていいなんていうけど、
(1)の時に別スレッドからこのトランザクションが開始されたとき、
conを持ち回らないでどうやって別々のトランザクションとして実行するのか
疑問だったんだけど。

67:デフォルトの名無しさん
04/11/10 02:06:46
>>66
ThreadLocal

68:デフォルトの名無しさん
04/11/10 02:08:01
>>67
もしくはJTA

69:63 =67
04/11/10 02:13:09
>>66
> AspectJが駄目だからDIコンテナをAOP込みで評価しろってことね。
そう。
つまり言語拡張の仕組みは受け入れにくいから、現実的にAOPのためにはDIが最適解かと。
それと、上の方に書いたけど、さまざまなオブジェクトから参照されるオブジェクトを横断的関心事として考えると、DIで横断的にインジェクションということも考えられる。

ThreadLocalは、サーブレットでのリクエストごとの情報を渡すのにとっても役に立って素敵。

70:デフォルトの名無しさん
04/11/10 02:14:58
POJO
ぽじょ

POJD
ぽじゅどぅ

後者を発音すると一瞬自分がフィリップ・トゥルシエになった気分が味わえます(ウソ)。

71:デフォルトの名無しさん
04/11/10 02:18:23
>>69
> ThreadLocalは、サーブレットでのリクエストごとの情報を渡すのにとっても役に立って素敵。

ThreadLocalは諸刃の剣だそうだ
URLﾘﾝｸ(d.hatena.ne.jp)

72:デフォルトの名無しさん
04/11/10 02:21:16
テストがしにくいってことね。なるほど。

73:デフォルトの名無しさん
04/11/10 02:22:17
POJDってなに？

74:デフォルトの名無しさん
04/11/10 02:27:45
>>73
URLﾘﾝｸ(forum.javaeye.com)
を読め。

じゃなくて>>65を読め。

75:デフォルトの名無しさん
04/11/10 02:30:05
結論：良さの判らない頭の悪い香具師は無理して使わなくて結構。

76:デフォルトの名無しさん
04/11/10 02:34:12
ageてまでいうことかと

77:デフォルトの名無しさん
04/11/10 02:35:41
かくたにさんとか太田さんとか良く名乗りを上げられるなと感心する。
本人かどうか疑えばきりが無いけどきっと本人でしょ？すごいな。

78:73
04/11/10 02:46:59
>>74
つまりPOJDっていうのは、Javaの基本文法とJ2SEのライブラリは知ってるけど、他のライブラリとかフレームワークは知ったこっちゃない開発者ってことですね？

79:73
04/11/10 02:52:48
中国語サイトのは、アノテーションのない普通の宣言ってことか。
みんなみんな、プレインオールドっていいたいだけ違うんかと。
そんなにプレインオールド好きなら、頭髪までプレインオールドになってしまえｗ

80:デフォルトの名無しさん
04/11/10 02:54:56
>>78
Rod Johnsonにその文面英語に訳してメール送ってみろ。

つーかおそろしく下手な煽りだな。

81:80
04/11/10 02:56:14
訂正。

>>79は煽りとして合格。

82:デフォルトの名無しさん
04/11/10 02:59:40
見事な釣り師だということだな。
素直に釣られたことを認めた>>80も天晴だ。
今日も快晴だな。

83:デフォルトの名無しさん
04/11/10 03:01:03
>>82
おっすオラ>>80
おめえけっこういいやつだな。

84:デフォルトの名無しさん
04/11/10 03:04:18
Plain Old = 平凡な
PORH = 平凡なRod Hair

…普通じゃん。PORH!!　ぽー！　ぽー！！

85:73
04/11/10 03:05:53
ｼｮﾎﾞｰﾝ(´・ω・｀) (　´・ω) (　　´・) (　　　) (・´　　) (ω・´　) (｀・ω・´)ｼｬｷｰﾝ

86:デフォルトの名無しさん
04/11/10 03:19:45
MOJOなんてのもあるぞ。

URLﾘﾝｸ(blog.goo.ne.jp)
> "Mojo"の最初の"o"はどっから湧いて出たんだ!と突っ込みたくなりますが

禿同。

87:デフォルトの名無しさん
04/11/10 09:52:20
早速話がそれてきてるわけですが。

とりあえず何を語ればいいのかがよく分からない。

88: ◆TDNdW1Xcyo
04/11/10 10:33:40
54さん>トリップつけました。失礼しました。

別にはずかしことを書いているわけじゃないので，
あえて匿名にする必要はないかなと思っています。
むしろ皆さん非常にすぐれた開発者の方だと思いますので，
リアルでお会いして話を聞きたいぐらいです。

ちょっとテストの話から離れてしまいましたが，
僕の本業はテストなのでその筋から単体テストが
容易になるDIに興味を持ちました。

#AOPはビジネスロジックの開発者が自分で実装しようとすると逆にテストがし
#にくくなるので，本当に必要な場合のみアーキテクチャチームが実装し，
#ビジネスロジックの開発者が利用するというのが現実的かと。

で，一応会社には単体テストの基準として，メソッドレベルで分岐網羅とか
あるわけですが，依存関係の強い設計をするとこれが有名無実化されてしま
って，本来適切に分離できていれば，単体(かつ自動テスト対象)で検出でき
たバグが結合テスト，システムテスト以降に持ち越されて発見，テスターも
開発者も疲労困憊という悪夢になります。これじゃあ，全然OOのメリットを
生かせてないじゃん，でもなんか解決策はあるはず，で出会ったのがDIとい
うわけです。

89:太田＠会社 ◆TDNdW1Xcyo
04/11/10 10:35:47
失礼しました。つけ方間違えました。

90:デフォルトの名無しさん
04/11/10 12:40:38
まだDIもJUnitも使ってないのでアレですが、
単体で網羅されてないことと設計段階の依存性がそれほど
関係あるとは思えないです。たしかにsetXXみたいなメソッドは
DIのobjectが読み込めた時点で正常動作しているので
JUnitでの項目は減らせるのかもしれませんが。

単体試験の項目はちゃんとレビューされてますか？項目漏れは
レビューアーの責任ですよね。って釈迦に説法かな。
自動テスト対象の項目はどうやってレビューされているか、
今後の導入の参考までに伺いたいです。

91:デフォルトの名無しさん
04/11/10 13:31:09
>>90
少し話がずれてると思う。
A->B->Cという依存関係のあるクラスが3つあるとする。
もし依存関係が強いとCの単体テストはできるが
BとCは単体では動かすこともできない
よって単体テストで網羅できるのはクラス数で数えると
わずか1/3にしかならない。
90はCができてからBを、BができてからAをテストするのかも
しれないが、それは単体テストではなく結合テストだし、
A・B・Cの担当者が違う場合にだれが責任持ってテストするのか？
DIで依存性を排除できればそれぞれ担当者が単体テストを
実施できて網羅率を上げることができる。

92:デフォルトの名無しさん
04/11/10 14:05:22
単体テスト・結合テストの粒度が違う人たちが議論してるように見えるのは俺だけ？

93:太田＠会社 ◆TDNdW1Xcyo
04/11/10 15:10:08
DIによる依存性の分離と単体テストとの関係は90さんが既におっしゃって
いますが，私が直面したのは息の長い製品で欠陥が発生したときの原因追求
に必要な時間です。依存関係が高い場合のボトムアップのテストだと，切り
分けが非常に難しいのです。テストの分離による保守性の高さという観点も
有効かなと。

あと，私がいる会社は非常にレビューを重視(インスペクション専門の組織が
あり過度といってよい)する組織ですが，逆にそれがあだとなって，ツールを
使ったり，自動化したり，テスト容易性を高めたりということが遅れています。
レビューって結局実際に動作させているわけではないので，僕はあまりレビュー
を重視するのは考えものかなと思います。

94:デフォルトの名無しさん
04/11/10 18:52:41
>依存性の分離と単体テストとの関係は90さんが
91だよね。なるほど、言いたいことはよくわかりました。でも単体で網羅すべき
基準がやっぱり違うようですね。

>息の長い製品で欠陥が発生したときの原因追求に必要な時間
太田さんはRUP推進派とのことでしたよね？なら理想はちゃんとOOして
クラスの責任分担が明確になっていれば、それが一番工数の削減に
繋がるけど、実際は現場の人間のスキルによってそうもいかんから
DIはいいんじゃないかってことですかね。

ちゃんとOOすることとDIを使うことを別の次元とは思ってないですよ。念のため。
ちゃんとOOした中でもDIという手法があると捉えています。

レビューしないでスキルの低い技術者が作ったものがそのまま放置されるのは
いただけないですよね。レビューアがスキルの高い人のやり方をスキルの低い人に
伝えていくことができればいいんですけどねえ。レビューによって詳細な進捗もわかるし。

専門の組織があるのは微妙ですね。レビューはプロジェクトリーダーがやって、
リーダーは自分の範囲内の仕様は把握していて、突発的な欠員がでても
代わりの人にちゃんと引き継げるくらいの近さがいいと思ってます。
太田さんとこは大きな会社っぽいので組織変更は難しいでしょうけど。

95:デフォルトの名無しさん
04/11/10 19:18:17
いい年こいて、昼間っから会社で2chかよ…

……窓際？

96:デフォルトの名無しさん
04/11/10 19:28:49
>>95
仕事の出来ない同僚？(ﾜﾗ

97:デフォルトの名無しさん
04/11/10 20:56:18
>>95
なんか嫌なことでもあったのか？

98:デフォルトの名無しさん
04/11/10 21:03:21
PHPのDIコンテナってありますか？

99:デフォルトの名無しさん
04/11/10 21:12:59
IT戦略部に通報しますた。

100:デフォルトの名無しさん
04/11/10 23:31:16
DIやろうとするとやたらとinterfaceが多くなってしまうような気がするんですが
そんなことない？

コンテナに管理任せるクラスって何を基準に決めるの？

101:デフォルトの名無しさん
04/11/11 00:19:17
>>100
DIやろうとしなくてもやたらとinterfaceが多くなるよ。

102:デフォルトの名無しさん
04/11/11 00:52:04
91の主張はマクロな視点だとその通りなんだけど、
実際クラス間に依存があるテストを行う場合、どちらかのテストを先にするしかなくなるんだよね。
すべてのクラスにDI適用させるのは無駄だし

103:デフォルトの名無しさん
04/11/11 01:00:52
俺はOOすることとDIすることは全く別次元
(相補的ではあるが依存でも排他でもない)
だと思うんだが、認識間違ってるのかな？

>100
interface は別に増えてもかまわないのでは。
増えることでどんなメリットとデメリットが出るかが重要なのであって。

>102
91氏は依存性がある場合はA→B→Cの順にやる、
って明言してると思いますが。

なんか1氏の思惑通りにはスレが進んでない気がするよ。

104:デフォルトの名無しさん
04/11/11 01:04:36
DBのWebフロントエンドだと、結果的にすべてのクラスにDI適用させることになったりして。
で、そういうアプリケーションだと、せいぜい継承くらい知っておけば、OOの知識というのもほとんど必要なかったり。
細切れの独立したクラスをDIで結びつけるわけで。

105:デフォルトの名無しさん
04/11/11 01:09:14
>>103
> 俺はOOすることとDIすることは全く別次元
> (相補的ではあるが依存でも排他でもない)
> だと思うんだが、認識間違ってるのかな？

DIはOOの上に成り立ってると思うが。
OOする、っていうのがなんのことなのかよくわからんけど。

> なんか1氏の思惑通りにはスレが進んでない気がするよ。

荒れてないし、いいんでないの？

106:デフォルトの名無しさん
04/11/11 01:25:39
>>103
91はそれぞれ独立してテストするって言ってるでしょ。
あともしテストするなら順番逆になるよ

107:デフォルトの名無しさん
04/11/11 01:27:32
結局DIも適用させる範囲絞らないと効率悪くなるから
トレードオフなんだよね

108:デフォルトの名無しさん
04/11/11 01:51:55
>106
＞順番逆になる
そうですね。うっかりしてました。

＞独立してテストするって言ってる
？　DIで依存性を排除できれば、では？

ところでDIって一言でいった場合、どういう意味なんでしょうか。
相関するモジュール群の結合を疎にし、コードベースではなく
コンフィグレーション(XMLファイルがありがち)によって結び付ける、
程度の意味だと思ってたんでOOの上とは違うよな、と思ってしまうんですが。

109:デフォルトの名無しさん
04/11/11 01:54:30
クラスとクラスの関連が強いんであっても、そのクラスを取り替えることがなかったり、オブジェクトを一つずつしか生成しないんだったら、あまりDIの意味はないね。
業務アプリみたいに、似たようなクラスと別の似たようなクラスをいろいろな組み合わせで関連させるものだとDIのやりがいがあると思う。

110:デフォルトの名無しさん
04/11/11 01:57:30
>>108
オブジェクトとオブジェクトを結びつけるものだと思うので、OOありきかと。
OOじゃない技術の上でDIするためには、結局OOじゃない技術の上でOOみたいなことをしてないとDIできないんじゃないかと。

111:デフォルトの名無しさん
04/11/11 02:46:44
>>108
コードベースじゃないとは限らないよ。Picoの例があるし

112:太田＠会社 ◆TDNdW1Xcyo
04/11/11 11:26:10
うん，窓際かも・・・

113:デフォルトの名無しさん
04/11/11 13:20:59
>>109
そうなんだよ。
だから、eclipseを見習おうといいたい。
extension point をアプリ側で定義する。
変更箇所が多そうなところを見つけてうまく定義すると素晴らしいアプリケーションになる。
ポリモーフィズムがここで大いに生きる。
DIで凡庸的にオブジェクトの定義の仕方云々っていっても、そんなのたいした意味ないわけ。
それならorg.eclipse.core.runtimeやosgiフレームワークのほうが偉いと思うよ。

114:デフォルトの名無しさん
04/11/11 13:27:01
>>113
>だから、eclipseを見習おうといいたい。
>extension point をアプリ側で定義する。
>変更箇所が多そうなところを見つけてうまく定義すると素晴らしいアプリケーションになる。

具体例を提示されたことで、なんか目の前が開けてきました。

115:デフォルトの名無しさん
04/11/11 13:28:21
まあ、extension pointっていっても、そんなもん無くたってプラグイン機構は作れるんだが
ここで人間の感性が反映されるわけ。コードの表現力が。
DIが悲しいのは、苦労して導入したところで、手間の割に表現力に乏しいところだと思うんだよ。
それと、DIを導入することで、初心者にも仕事をまかせられるとかいう意見あるけど、
これはどうも、いまいち。あやしい。
そんなことやる暇あれば仲良くなるためにどうすればいいか、考えたほうがいいなと。

116:デフォルトの名無しさん
04/11/11 13:33:50
eclipseの設計思想は、googleで
"the eclipse house rules"

を検索されたい。
なぜこんな素晴らしい設計指針がマッチする文章がPDF一枚なのかは謎だが、
結局地道にこれを実践することがいいアプリを作る唯一の方法なのだと漏れは結論する

117:デフォルトの名無しさん
04/11/11 15:48:40
DIだけだとそうかもしれんが、DI+AOPだと業務アプリには欠かせない。
デスクトップツールやライブラリ自体にはDIは不要だと思われる。つまりeclipse。
springやseasarにしても、その周辺ライブラリはDI使ってないものが多いし。

118:デフォルトの名無しさん
04/11/11 15:49:28
△周辺ライブラリ
○周辺ライブラリ自体

119:デフォルトの名無しさん
04/11/11 15:50:46
いや、適応範囲の問題ではなく、設計のコンセプトの問題でしょう。

120:デフォルトの名無しさん
04/11/11 16:11:41
>>119
そうとは言い難い。
DIはどちらかというと、多層化のアプローチで複数機能があるとき、升目状の設計になるわけだけど、それぞれの升ごとの独立性を高めるのにDIが有効になる。
それぞれの升目の中ではあまりDIは有効じゃなくて通常のOOアプローチになるんだけど、あまりクラスの関連が複雑になることもない。

逆に、デスクトップツールの場合は、それぞれのオブジェクトの依存性がもともと大きいので、DIで依存性の注入どころじゃない。
例えば、MapとEntryとIteratorをDIつかって独立性を高くってできないような感じ。

121:デフォルトの名無しさん
04/11/11 17:48:29
>>115
>DIが悲しいのは、苦労して導入したところで、手間の割に表現力に乏しいところだと思うんだよ。
DIの導入に苦労？どんな？
表現力ほどの手間もかからないと思うが？
Eclipseのプラグインは見事だと思うけど業務アプリには
それこそ手間の割にメリットがないと思う。

>extension point をアプリ側で定義する。
それがうまくいくくらい業務要件の未来が予測できる？
ツールのように使い手により様々にカスタマイズするのとは
コンテキストが違いすぎて正直参考にならんと思う。

122:デフォルトの名無しさん
04/11/11 17:52:58
というか、DIがめんどくさいとか言ってる人は、DI使ったことないだけじゃないかと。

123:デフォルトの名無しさん
04/11/11 17:58:43
俺は使った事ないんですど、確かに雑誌の記事など読むと
設定ファイルとかめんどうくさそうに思えます。

124:デフォルトの名無しさん
04/11/11 18:17:13
「BOYがGIRLに・・・」だけの場合だと、確かにめんどくさい。
でもある程度実用的な業務アプリだと、簡単にそのコストは回収できる。
ただ、現実的には、DIコンテナの価値は、その周辺ライブラリにあると思う。
Webでデータベース使うなら、しのごの言わずにSpringかSeasar使うべき。
また、そういった周辺ライブラリが作りやすいのもDIコンテナの特徴。
だから今後も周辺ライブラリは増えていくと思われ。
それと、業務で作った機能がなぜかライブラリとして独立した形になっているのもDIコンテナ使った場合の特徴。

125:124
04/11/11 18:34:29
SpringとSeasarでは、今のところSpringの方が導入が楽。
Seasarは、現時点では周辺ライブラリの充実度やドキュメントの整備など今一歩のところがある。
ただ、のびしろとしてはSeasarの方があるので、S2JSFとSeasar自体のブラッシュアップ、ドキュメントの整備、英語圏へのプロモーションが進めば大ブレイクするかもね。
今は中の人が盛り上がってるだけだけど、このままのモチベーションで開発が続けば１年半後くらいがみものかも。

126:124
04/11/11 18:41:35
そういう意味では、情報集約サイトとして機能してないホームページをどうにかして欲しいんだけど、S2JSFとセミナー準備で手一杯のようだ。
年があけたころから機能していくんじゃないかと、外野から見て思う。

127:デフォルトの名無しさん
04/11/11 18:49:04
>>123
テキストエディタで設定ファイルを書くのは確かに面倒。特にSpring。
そこでEclipseプラグインの出番。SpringやS2にはすでにある。
S2のKijimunaというEclipseプラグインは設定ファイルのエディタを提供してくれる。
XMLの要素や属性の補完だけではなく、クラス名やプロパティ名も補完してくれるから
面倒さはほとんど感じない。

128:124
04/11/11 18:54:43
SpringはAOPの定義がクソめんどいね。
技術的にはSeasarの方がかなりいいと思う。
ただ、現状スウィートスポットがSpringより狭い印象がある。けど、時間の問題。

129:デフォルトの名無しさん
04/11/11 19:00:22
>>125
Seasarに足りない周辺ライブラリって？
Springの方が充実してるのは確かだと思うけど，
差があるのはJDOとかiBATISとかVelocityとかSpring MVCとか、
なくても困らないようなマイナーなものばっかりじゃない？
そのためにSpringとは思わないけど。

130:デフォルトの名無しさん
04/11/11 19:16:33
>>129
そりゃ、iBatis使ってない人にはなくて困らないだろうけど。

131:デフォルトの名無しさん
04/11/11 19:23:13
iBatis使ってない人には、iBatis+SpringよりもS2Daoでいいだろうけどね。

132:デフォルトの名無しさん
04/11/11 19:26:20
そんなにiBATISユーザって多いのか。そっちのほうがビックリする。

133:デフォルトの名無しさん
04/11/11 19:28:35
>>130
スマソ
意図としては、すでにiBATISなどを使っているところに
DIコンテナを導入するという状況ではなくて、これから新たに
開発する際にDIコンテナとしてSpringかS2のどちらにするかの
判断材料となるほど影響力のあるプロダクトのサポートに違いが
あるのか聞きたいということなので許してほしい。

134:124
04/11/11 20:07:20
>>132
たぶん、多くはないんだろうけど、それなりに開発をやってると、なにか一つマイナーなライブラリを使ってたりして、Springだと検索するとみつかる感じ。
その代表がiBATISってことで。

>>133
しがらみなく新たに開発だと、そこまで影響力のあるライブラリの違いは確かにないと思う。
Hibernate2対応とかそれぞれのライブラリをみると、むしろSeasarの方に軍配があがるとも思うし。
S2DaoがiBATIS自体を補完すると思うので、新たにiBATIS対応する必要もない気もする。
だから、若干スウィートスポットが狭いと感じるのも時間の問題だと。

135:デフォルトの名無しさん
04/11/11 20:11:48
>>124

>それと、業務で作った機能がなぜかライブラリとして独立した形になっている

もう、そんな幻想だれが信じるんだよ。
ひとつでいいから実例見せてくれ。

> ただ、現実的には、DIコンテナの価値は、その周辺ライブラリ
ツールに頼る必要のないところでなんでそんなにツールマンセーになれるのか不思議だよ。
そんなにツールのこと学ばなくても、シンプルに設計することを知らなきゃ意味ないし、
シンプルに設計することはツールは必要ない。

136:124
04/11/11 20:29:30
>>135
実例としては、DIコンテナの周辺ライブラリ。
DIコンテナって、周辺ライブラリがたくさんあるけど、それは、簡単にライブラリ化できるから。
公式じゃなくてもSpringXXXとかS2Xxxとかいっぱいある。

DIコンテナは周辺ライブラリあってナンボだと思ってて、DIのみ語ってめんどくさそうとか言ってもしかたないと思ってるから。
で、周辺ライブラリがそろってるDIコンテナはSpringとSeasarになるかと。
もちろん、DIはDIでとても有意義なものだと思うけど。
比較的あたらしいスレでこんなこというのもなんだけど、現実的には「DIってどうよ？」という段階はすでに過ぎてると思う。

> ツールに頼る必要のないところで

だって、便利だし。
あと、SpringとかSeasarって、使っててもそんなに依存するものじゃないから、Spring+Hibernate+StrutsでやってるものをSpringからSeasarに乗り換えるのも、そこまで苦ではない。

> シンプルに設計することはツールは必要ない。

知識も必要だし、ツールも必要だと思う。
もちろん、デザインパターンってなに？という人だけが集まってDIを活かせるとは思わない。
DIでのシンプルな設計を学ぶには、DIコンテナ使う必要はあると思う。

137:124
04/11/11 20:32:12
誤解のないように補足しておくと、Springでやってるプロジェクトを途中からSeasarに切り替えるのはもちろん作業時間てきに無駄。
ではなくて、前のプロジェクトをSpringでやってて、次のプロジェクトはSeasarでっていうときに、前のプロジェクトの成果物の再利用に苦労はそれほどないってこと。

138:124
04/11/11 20:42:37
ぶっちゃけ言えば、Web+DBの業務アプリで、プログラム自体の設計に頭を使ってもしかたないと思う今日この頃。

139:デフォルトの名無しさん
04/11/11 20:55:48
>>134
> たぶん、多くはないんだろうけど、それなりに開発をやってると、なにか一つマイナーなライブラリを使ってたりして、Springだと検索するとみつかる感じ。
> その代表がiBATISってことで。

ああ、なるほどね。納得した。

140:デフォルトの名無しさん
04/11/11 21:00:58
>>135

> もう、そんな幻想だれが信じるんだよ。

信じなくてもいいよ。出てきたばかりのものに実績とか言われてもな。
オブジェクト指向だって何10年かかってようやく今の認知度だ。

> そんなにツールのこと学ばなくても、シンプルに設計することを知らなきゃ意味ないし、
> シンプルに設計することはツールは必要ない。

考え方とツールが別というのはわかるけど、ツールがないのに考え方ばかり
論じてたって形あるものにはならんと思うよ。

141:デフォルトの名無しさん
04/11/11 21:01:30
>>138
俺も同意する。

142:デフォルトの名無しさん
04/11/11 21:11:40
なあ>>135よ、オマエさんはきっと出来る奴なんだろうな。
ところでな、オマエさんのその考えとかを同僚とかはすぐに理解してくれるかい？
もしそうなら恵まれた職場にいるし、だったらDIなんてものはオマエさんには不要だ。
こんなところでつまらない連中を相手にしてるのは勿体無いと思う。

しかしな、オマエさんが周囲の奴を見て使えねえ連中ばっかりだと思うなら
DIはひょっとするとオマエさんを楽にさせてくれるかも知れないよ。

なあ>>135よ、オマエさんのはオマエさん並みに出来る奴ばっかりか？

143:デフォルトの名無しさん
04/11/11 21:12:49
>>142

× なあ>>135よ、オマエさんのはオマエさん並みに出来る奴ばっかりか？
○ なあ>>135よ、オマエさんの周りはオマエさん並みに出来る奴ばっかりか？

144:デフォルトの名無しさん
04/11/11 21:20:41
DBを使用しないWEBアプリでDIコンテナを使うメリットってありますか？
自宅PCにWEBブラウザでアクセスして、２ちゃんブラウザのログを更新したり
閲覧したりしたいだけなんだけど・・・・・・・

こういう用途でも使えるものなんでしょうか？＞DIコンテナ

145:デフォルトの名無しさん
04/11/11 21:43:45
単機能のアプリケーションだとあまりメリット感じれないかもね。
自分なら、とりあえずDIコンテナ使うけど。すでにある程度慣れてるから。

146:デフォルトの名無しさん
04/11/11 22:08:44
自分なら、とりあえずEJB使うけど。すでにある程度慣れてるから。

147:デフォルトの名無しさん
04/11/11 22:11:58
>>144
その程度だたらperlとかrubyとかの出番じゃない？

148:デフォルトの名無しさん
04/11/11 22:17:12
>>144
そのアプリってログはどうするのかな。自分で保持しつづけるの？
もしそうなら、仮にDBを使わなくてもストレージ管理が必要になるよね。
テキストファイルなんかでもさ。それがちょうどORMツールみたいな
位置付けになるから、DIは有効だよ。
テキストファイル管理コンポーネントを自作するとしてもPOJOで済むしね。
でももしログを持ちつづけるならDBを使ったほうが楽だと思うよ。
インストールが面倒ならPure JavaのDBでもいいんじゃないかな。

もし単なる串を作りたいならどうだろうね。漏れならDI使うと思うけど
もっと別の方法でもいいかも知れないね。串を作ったことがないから
よくわからない。ごめん。

>>146はすごいね。尊敬するよ。

次ページ