【最速】google guice DI Framework【シンプル】

【最速】google guice DI Framework【シンプル】 at TECH

1:デフォルトの名無しさん
07/03/24 09:34:46
無かったので立ててみた。
URLﾘﾝｸ(code.google.com)

2:デフォルトの名無しさん
07/03/24 09:45:50
鼬害

3:デフォルトの名無しさん
07/03/24 09:46:13
これなんて読むんだ？
juice→ジュースだから
グース？

4:デフォルトの名無しさん
07/03/24 10:11:04
pronounced　'juice'
って書いてあるじゃん。

ってかまたDIか。本気でDIいけてると思ってる奴どんだけ
いんのよ？流行で触ってみた、使ってみたじゃなくてさ。

心底、これはスゲーって思ってる奴いる？

5:デフォルトの名無しさん
07/03/24 10:24:14
DIなんてJavaが駄目言語であるがゆえに存在するものだからなあ

6:デフォルトの名無しさん
07/03/24 10:34:07
ＤＩいけてないって思うヤツに
プログラムを書かせてはいけない

7:デフォルトの名無しさん
07/03/24 11:11:11
>>4
普通に１００人規模の開発で使ってるんだが。。

8:デフォルトの名無しさん
07/03/24 11:12:37
>>4
DI無しでの単体テストなんてもう考えられないな。
DIは単体テストの為にあるって言ってもいいかも。

9:デフォルトの名無しさん
07/03/24 11:15:59
>>6
書き方が悪かったな。
ＤＩいけてると判断して使ってる奴がどれだけいますかー？
ＤＩいけてないと判断して使ってない奴がどれだけいますかー？

って事だけ。流行に躍らされてないで、DI理解して
DIDIって言ってる奴が何割いるのかと。

10:デフォルトの名無しさん
07/03/24 11:17:51
>>9
DIはいけてるが既存のフレームワークは最悪。
guiceはちょっとましになったかなという程度か。

11:デフォルトの名無しさん
07/03/24 11:31:10
DIなんて聞いたこともないわけだが。
まったく次から次へと焼き畑農業のようにゴミライブラリ撒き散らして悦に入っている
Java厨は本当に度し難いな。

12:デフォルトの名無しさん
07/03/24 11:46:14
まぁＣ/Ｃ＋＋何ぞでは、ＦＷ作る意味すらないからな

13:デフォルトの名無しさん
07/03/24 13:57:12
リフレクションが使いにくい言語にはDI適用は困難
ダックタイピングが有る言語にはDIは不要

14:デフォルトの名無しさん
07/03/24 14:58:31
DIってDLLみたいなもんだろ。
デバッグ情報含んだDLLをデバッガで動き見て
リリースモードのDLLにして納品みたいな。

15:デフォルトの名無しさん
07/03/24 16:37:09
>>14
違う予感

え、そうなの？
不安になってきた。

16:デフォルトの名無しさん
07/03/24 16:39:55
うさんくせぇ～～～～～
Java開発を変える最新の設計思想「Dependency Injection（DI）」とは
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

17:デフォルトの名無しさん
07/03/24 16:51:38
国際化対応もDLLにリソースぶち込んで、ロケール見て切り替えってのもそう？

18:デフォルトの名無しさん
07/03/24 16:53:56
なんだよＤＬＬって
Windows厨はでてけよ

19:デフォルトの名無しさん
07/03/24 17:04:47
soもDLLっていうが

20:デフォルトの名無しさん
07/03/24 17:07:40
EJBが糞過ぎてそれをどうにか他環境並みの疎結合に引き上げてくれる夢の新技術がDIってことか

21:デフォルトの名無しさん
07/03/24 17:24:01
ﾅﾆこのスレ
ＤＩわからん香具師は出てけ

22:デフォルトの名無しさん
07/03/24 18:06:20
>>14
DLLて。。
勘違いにも程があるな。少なくともぐぐってから書き込め

23:デフォルトの名無しさん
07/03/24 18:07:48
大して違わないことに気づいても無い奴よりマシだと思う

24:デフォルトの名無しさん
07/03/24 18:17:54
しかし徹頭徹尾無内容なスレだな。

25:デフォルトの名無しさん
07/03/24 18:42:19
DIなんぞやから語る事自体は悪い流れではなかろう
問題はこの煽り合いの流れが意地の張り合いで終わるのかどうか

26:デフォルトの名無しさん
07/03/24 18:42:47
スレタイにDIなんて入れるから中途半端なのが入ってくるんだ。

27:1
07/03/24 18:48:31
>>24
そうならないように、スピード比較結果を貼ってみる
１回目
Spring: 1,734 creations/s
Guice: 35,161 creations/s
S2: 18,395 creations/s
２回目
Spring: 1,776 creations/s
Guice: 37,202 creations/s
S2: 19,394 creations/s
３回目
Spring: 1,783 creations/s
Guice: 36,764 creations/s
S2: 19,164 creations/s

数字大きい方が速いって事で。

URLﾘﾝｸ(d.hatena.ne.jp)

スレの内容見るとこのネタじゃ盛り上がらなさそうだけど(´・ω・｀)

28:デフォルトの名無しさん
07/03/24 19:18:07
軽量で高速なDIコンテナは需要あるんじゃない？
うちじゃSpring使ってるけど、サーバ起動時の待ち時間は異常

29:デフォルトの名無しさん
07/03/24 19:23:29
つーかＤＬＬとＤＩを同じ基準で比較するバカどもウゼー

30:デフォルトの名無しさん
07/03/24 19:27:46
バインディングをコード書いてやらなあかんのがなー
Springで定義したのをGuiceで運用するってのがいいのかなーｗ

31:1
07/03/24 19:28:30
>>28
個人的には、DI定義XMLが無い所がかなり気に入ってる。
リファクタリング手軽に出来るしね。

32:デフォルトの名無しさん
07/03/24 19:32:43
>>31
へー。実例とかあったら見てみたい。

33:デフォルトの名無しさん
07/03/24 19:41:48
悪りい、ここにドキュメントあったわ
URLﾘﾝｸ(code.google.com)

34:デフォルトの名無しさん
07/03/24 19:41:59
jarを(dll)をどうロードするかでしかないんだから
こんなものありがたがってる奴らはドカタだわな

35:デフォルトの名無しさん
07/03/24 19:46:04
>>34
いいからコボラーは引っ込んでろ

36:デフォルトの名無しさん
07/03/24 19:48:03
>>34
むかしはファクトリのコードを手で書いてたんだから、かかなくて良くなりゃ
それに越したことはないと思うんだけど。

37:デフォルトの名無しさん
07/03/24 19:51:45
だが、バインディングコードを書く時点で「コードを書く」こと自体は従来と同じ（戦略はともかく）
アノテーションのみだったらまだ違うけど

38:デフォルトの名無しさん
07/03/24 19:56:19
春休み明けに立てればよかったのに

39:デフォルトの名無しさん
07/03/24 19:57:08
ユーザガイドざーっと読んでみた。とりたてて目新しいことは無いな。

>>37
コードでもバインディングできますよ、ってだけで基本アノテーションのみ
じゃないの？

40:デフォルトの名無しさん
07/03/24 19:57:36
まったくだな、>>38みたいな盲目な人間が消えてくれる

41:デフォルトの名無しさん
07/03/24 20:04:48
ソースをざーっと読んでみた。とりたてて目新しいことは無いな。。

googleは何でこれ作ろうと思ったんだ？？

42:デフォルトの名無しさん
07/03/24 20:06:00
作ったアプリの中からスピンオフしただけだろ
企業発のコードなんざ大抵そうだ

43:デフォルトの名無しさん
07/03/24 20:11:28
へー、そういうものなのね。

44:1
07/03/24 20:23:16
>>39
いや。バインディングのコードは必ず必要。

45:デフォルトの名無しさん
07/03/24 20:32:28
簡単なDIだけでいいなら不要だけど
多分それじゃもの足りんよねー

46:デフォルトの名無しさん
07/03/24 20:40:02
>>41
思うに、実行速度を早くしたかったのかと・・・・
Springの定義から作ったものをGuiceに上で高速に
動かしたいんじゃないの？

47:1
07/03/24 20:45:04
>>41
バインディングがコードで書けると
jUnitで単体テストが書けてとても嬉しいよ。
XMLの場合、結合しないとテスト出来なかったから。

48:デフォルトの名無しさん
07/03/24 20:51:04
オリは逆にDJUnitでコードバインディングみたいにコーディングしてダミーのクラスとか入れ込んでたけど
XMLで定義できたらなぁとか思ってたｗ

49:デフォルトの名無しさん
07/03/24 21:10:16
>>47
ん？手でmockをセットすればテストできるけど、そういう話じゃないよね？

50:デフォルトの名無しさん
07/03/24 21:14:17
ちら裏スマン
4月から超ファイヤープロジェクトに放り込まれそうだ。
ってか、燃えカスしか無いかも。。。

漏れは製造系の会社のIT分門で、9ヶ月前ぐらいにIT系の会社から
社内SEとして転職。で、問題のプロジェクトは工場で使う生産系の
システムを外部に請負で発注。テストもてきとうで、少し前から触るとなんか出る
って感じでやばいのがどかどか出てきた（ってか根幹の仕組み自体が破綻してるみたい）。
検収上げなきゃ良いじゃんって思ったけど、こっちの期末処理の関係で
3末で検収ださなあかんのだとｗｗｗ
保守契約は無し。構築中にスキトラ受けて自分らでやる予定だったみたい。

で、どうするかなーと思い、BLだけ切り出してきてDIでくっ付けなおそうかと。
BLの部分はJavaの基礎と最低限のライブラリの知識で作れるようにして
業務を知ってる社内のエセSEをちょっと鍛えて作ってもらうと。
数億の仕組みだから1人じゃどうにもならんので、人海戦術使うならこんな感じかなと。

立て直るかはプロジェクトの進め方で7割は決まると思っていて
やり方は色々あると思う。ただ、バグを1つ1つ潰してたら、きりが無い
という噂が流れてきてるから、上記みたいな事を考えてる。
まだ自分で蓋を開けてないから変わるかもしれないけどね。

51:デフォルトの名無しさん
07/03/24 21:41:49
フルスクラッチするなら幾らでもやりようがあるがノー
結局そうした方がいい場合が多いんだけどねー
目先の予算やら何やらでお茶を濁すと結局は本質的な問題が
解決されずにグダグダするだけだったりして・・・

52:50
07/03/24 22:25:49
>目先の予算やら何やらでお茶を濁すと結局は本質的な問題が　
>解決されずにグダグダするだけだったりして・・・　
まったくです。でも4月からの予算枠も当然取ってないですとｗｗｗｗ
って事で、社内要員でなんとかするしかなさそ。
1年以上やってるプロジェクトだから、なんとか活かせる部分は
活かして短期決戦に持っていきたい。

53:デフォルトの名無しさん
07/03/24 22:59:58
∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵。∴∵
∴∵∴∵:。∴∵∴∵∴: --─-　∴∵∴∵∴∵∴∵
∴∵゜∴∵∴∵∴∵　（___ ）（___ ）　>>50∵∴∵　゜
∴∵∴∵∴:∵∴∵_　i/ ＝　＝ヽi　∴∵∴∵。∴∵∴
∴∵☆彡∴∵∵ ／/[||　　」　　||]　∴:∵∴∵∴∵:∴∵
∴∵∴∵∴∵　/　ﾍ　| |　 ____,ヽ | |　∴:∵∴∵∴∵:∴∵
∴ﾟ∴∵∴∵ ／ヽﾉ　　ヽ＿＿./　　∴∵∴∵:∴∵∴∵
∴∵∴∵　く　 /　　　　三三三∠⌒＞　∴:∵∴∵:∴∵
∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∵∴∵∴∵
　　 ∧∧　　∧∧　　∧∧　　∧∧
　　（　　）ゝ（　　）ゝ（　　）ゝ（　　）ゝ　ムチャしやがって・・・
　　 i⌒　/ 　 i⌒　/ 　i⌒　/ 　 i⌒　/
　　三　 |　　三　 |　　三　 |　　三　|
　　 ∪ ∪　　∪ ∪　　∪ ∪　　∪ ∪
　　三三　　　三三　　三三　　三三

54:>>46
07/03/25 01:53:21
全然チゴタ

55:デフォルトの名無しさん
07/03/25 02:57:20
コレクションへのDIとかってGuiceではどうすんかしら？
そこは直接書かないとアカンみたいな希ガス

■　Spring
　<bean id="test1" class="test.Test1" singleton="true"/>
　<bean id="test2" class="test.Test2" singleton="true"/>
　<bean id="test3" class="test.Test3" singleton="true"/>
　<bean id="testFactory" class="test.TestFactory" singleton="true">
　　<constructor-arg>
　　　<map>
　　　　<entry key="test1" value-ref="test1"/>
　　　　<entry key="test2" value-ref="test2"/>
　　　　<entry key="test3" value-ref="test3"/>
　　　</map>
　　</constructor-arg>
　</bean>

　TestFactory testTactory = (TestFactory)beanFactory.getBean("beanFactory");
　Test test = testTactory.getTest(key);
　test.process();

　　

56:デフォルトの名無しさん
07/03/25 02:58:08
■　Guice
　@Singleton
　public class TestFactory{

　　Map<String,Test> map;

　　static{
　　　Injector injector = Guice.createInjector();
　　　map = new HashMap<String,Test>();
　　　map.put("test1",injector.getInstance(Test1.class);
　　　map.put("test2",injector.getInstance(Test2.class);
　　　map.put("test3",injector.getInstance(Test3.class);
　　}

　　public TestFactory(){}

　　・・・
　}

　TestFactory testTactory = injector.getInstance(TestFactory .class);
　Test test = testTactory.getTest(key);
　test.process();

57:デフォルトの名無しさん
07/03/25 02:59:38
>>56は間違ってるけど適当に脳内補完してくださいｗ

58:1
07/03/25 17:24:04
>>56
こんな感じになる希ガス

　public interface IfItems {
　　Map getItems();
　}
　public class ItemsMock implements IfItems{
　　public Map getItems(){
　　　マップ作る処理
　　}
　}
　public class MyModuleMock implements Module {
　　public void configure(Binder binder){
　　　binder.bind(IfItems.class).to(ItemsMock.class)
　　　　　　.in(Scopes.SINGLETON);
　　}
　}
　public class ItemProcessorImpl impletemts IfItemProcessor {
　　private IfItems mItems;
　　public void process(){
　　　mItemsを使った処理
　　}
　　@Inject
　　void injectItems(IfItems inItems){
　　　mItems = inItems;
　　}
　}
　
　Injector inj = Guice.createInjector(MyModuleMock.class);
　IfItemProcessor ip= inj.getInstance(ItemProcessorImpl.class);
　ip.process();

59:1
07/03/25 17:38:09
間違ってた
Injector inj = Guice.createInjector(MyModuleMock.class);
　　↓
Injector inj = Guice.createInjector(new MyModuleMock());

60:55-57
07/03/25 18:37:21
むむむ・・・・
ちなみにやりたいことは、

　switch(key){
　case 1:
　　　// １の時の処理
　case 2:
　　　// 2の時の処理
　case 3:
　　　// 3の時の処理
　}

のような、ある条件に応じて処理が分かれるロジックを
コマンドパターンで解決しようとしているところで、
条件と処理の関連付けをDIで解決しようとする場合に
どうすりゃいいのかのー？ってことなんだなこれが
Springなら<map>でそれができるんだけど、同じことをやろうと
すると>>56のようにマッピングは自力で書かんとイカンだろなー
っというところだがどうなんだろう？
Mapを使わなくても条件と処理の関連付けがコーディング
しなくても出来ればいいなと

で、>>58だと、条件と処理のｾｯﾄ（＝ItemsMock）と、
条件に応じた処理を実行するコンテキスト（＝ItemProcessorImpl）の
依存関係がDIで解決されているように思うのだが、だとすると
そこは悩ましいところではないんです
違ってたらすみません。

61:1
07/03/25 21:58:52
>>60
なるほど。それならこれでいけるかな。
ただ、その処理やるならkeyとクラス名を紐付けといてリフレクションで呼んだ方が楽かと。。
　public interface IfCommand {
　　public void exec();
　}
　public OneTimeExecCommand implements IfCommand{
　　public void exec(){何かの処理}
　}
　public TwoTimeExecCommand implements IfCommand{
　　public void exec(){何かの処理}
　}
　public class MyModule implements Module {
　　public void configure(Binder binder){
　　　binder.bind(IfCommand.class).to(OneTimeExecCommand.class)
　　　　.annotatedWith(OneTimeExec.class).in(Scopes.SINGLETON)
　　　binder.bind(IfCommand.class).to(TwoTimeExecCommand.class)
　　　　.annotatedWith(TwoTimeExec.class).in(Scopes.SINGLETON)
　　}
　}
　pulic class CommandProcessor {
　　private @Inject @OneTimeExec IfCommand oneTimeExec;
　　private @Inject @TwoTimeExec IfCommand twoTimeExec;
　　public process(){
　　　switch(key){
　　　case 1:
　　　　oneTimeExec.exec();
　　　case 2:
　　　　tweTimeExec.exec();
　　　}
　}

62:55-57
07/03/25 22:09:18
むむむむむむ・・・・・

っていうか、switch文で解決しようとすると、条件が増減したりすると
ソコのコードを書き換えなきゃでしょ？
switch文を書かないようにすることが主目的なんだけどなー

条件と処理のマッピングが設定で出来れば条件の追加はコーディング不要になるでしょ
少なくともMapなどのコレクションでの解決は、コレクション要素の追加だけで
修正が出来るからいい解決方法かな？と思ってるんだけどね

Springの場合は<map>に<entry>を追加するだけでいいんだけど
Guiceは要素を追加するコードは書かなきゃならんようだなー

63:55-57
07/03/25 23:22:43
あと>>60はこうでした
　switch(key){
　case 1:
　　　// １の時の処理
　　　break;
　case 2:
　　　// 2の時の処理
　　　break;
　case 3:
　　　// 3の時の処理
　　　break;
　}

64:1
07/03/26 21:27:58
>>62
あ～ようはCommandインスタンスのMapをインジェクションしたいと。
それならProviderでラッピングしてやれば出来るけど
Springより面倒だね(´・ω・`)

65:デフォルトの名無しさん
07/03/26 22:06:15
>>1
ｲﾀｲｿﾞ

66:デフォルトの名無しさん
07/03/29 16:09:29
とりあえず日本語の情報源っぽいもの

Users Guide翻訳
URLﾘﾝｸ(d.hatena.ne.jp)

なんか色々試してるブログ（のリンク）
URLﾘﾝｸ(www.wikihouse.com)

67:デフォルトの名無しさん
07/03/31 09:49:33
よし
XML定義ファイルからModuleを自動生成して登録する拡張を作るぞ

68:デフォルトの名無しさん
07/03/31 11:23:56
>>67
わかった
ならおれはOGNL実装する

69:デフォルトの名無しさん
07/03/31 12:15:35
SpringのXMLファイルをそのまま使ったらまずいかしら？

70:デフォルトの名無しさん
07/03/31 14:08:45
>>69
お！それいいね！

71:デフォルトの名無しさん
07/03/31 14:15:32
>>50
javaのお仕事ってこういうのが多いのかね？

72:デフォルトの名無しさん
07/04/01 01:54:39
XMLでbindの定義したのを読み込んで、Module内でバインディングしようとしたら
bindする型をはっきりさせないと遺憾からXML定義による自動バインディングは
できんかった・・・
バイトコードいじれば出来るのかしら？
しかしそれはメンドイ
やはりXMLからModeuleクラスを作るようにしよか・・・

73:デフォルトの名無しさん
07/04/01 10:07:58
>>72
おまいは本気でxmlで定義しようとしてるのか！？
あぁ。。４月１日か。。

74:デフォルトの名無しさん
07/04/01 10:32:36
バインド定義をコーディングするのはオレてきにメンドイ

75:デフォルトの名無しさん
07/04/01 11:08:29
続きはWebで・・・・
URLﾘﾝｸ(d.hatena.ne.jp)
（ここもWebだが）

76:デフォルトの名無しさん
07/04/01 11:29:47
>>74
なら、SpringかSeasar使えと。。
Guiceの利点はxmlを使わない所にある。

77:デフォルトの名無しさん
07/04/01 11:43:18
コードでバインディングめんどいかー？エディタで補完効いて快適じゃん。

78:デフォルトの名無しさん
07/04/01 11:48:03
コードをゴリゴリかくのメンドイし、どうバインディングされてるかわかりにくいのが良くないと思う
最終的にはExcelで定義したバインディング仕様からModuleクラスが作れればいいかなと・・・・
まぁ挫折してもエイプリルフールってことでｗ

79:デフォルトの名無しさん
07/04/01 12:02:20
>>78
１０年程PGや設計やってきて出した俺的結論としては
PGのコード記述するのに、外部ファイルや自動生成系は使うなだな。
自動生成やるにしても、最初の１回だけで後は使わない。

理由は単体テストがやりにくい・リファクタリングが自動で出来ないのと、
管理がめんどいから。
自動生成で作成したJavaソースはいじらないってルール作っても、
従わないヴァカがいっぱいいるんだよ世の中。

78はまだ若そうだが、いずれ分かるようになるさ。

80:デフォルトの名無しさん
07/04/01 12:11:55
マダマダ若いなｗ
１５年この業界にいてフレームワークを作り続けてきた俺の結論は
ドキュメント＝実行モジュールになるのがもっとも生産性が高いってこと
幾らプログラム作ってもドキュメント化されないと保守できない
システムのメンテナンスは同じ人間がやれるわけでもないし、
新しい人間がスグに使えるようになる必要もあるのだよ

プログラマからすれば自分の作業が問題なければそれでいいカモしれんが
それじゃいかん

81:デフォルトの名無しさん
07/04/01 12:34:02
>>80
ま～理想で言えばそうだが、現実は違うわなw

ドキュメント書くだけでJavaソース作ってくれる
某G○nってツール使った事あるんだが、パフォーマンス糞だったぞ？
いくら生産性高くて(特殊なツールで生産性高いとは言えなかったが。。)
シス方と開発がウハウハでもユーザー不在なのはどうかと。

ドキュメント書くのはSEの仕事だから、
PGはJavaDocさえきっちり書いとけばいいんじゃね？

82:デフォルトの名無しさん
07/04/01 12:48:14
ドキュメント＝実行モジュールと考えるからよくない。
実行モジュール＝ドキュメントと考えればいいんだ。
つまり、ソースがそのままドキュメントになる。

guiceは、メソッドがinとかtoとかになってるんだが、
英語が母国語な人にとっては、
このソースはドキュメントっぽく読めるんじゃないだろうか。

83:デフォルトの名無しさん
07/04/01 12:57:43
>>81
1から10までってのは難しいと思うけど、インターフェイスの部分て言うのは
わかりにくいからドキュメント化したいし、バグの温床でもあるからねぇ。

例えばエンティティクラスやStrutsのActionFormのようなデータインターフェイス
は自動生成して、データの転送はリフレクションを使ったプロパティコピー
ユーティリティのようなもの（commons-beanとか）でコードを極力書かない
ようにしたほうがバグも少ないし生産性も高い。

Guiceの場合はGuiceとアプリケーションのインターフェイスであるModule
を自動で作ったりバインドしたりする方がそのインターフェイス間での問題が
少なくなるし、どんなバインディングしてるのかが第3者にもわかりやすくなる。

>>82
Hibernateもそうだけど、

　hoge.createSQLQuery(...).
　　　　.addEntity(.....)
　　　　.setString(....)
　　　　.list()

見たいな続けて書くのがはやってるね。
こういうプログラムを書のは面白いと思うけどｗ

84:デフォルトの名無しさん
07/04/01 13:23:12
>>82
ドキュメント＝実行モジュールも
実行モジュール＝ドキュメントも同じ意味なんぢゃ。。

ソースがそのままドキュメントになるのは同意。
ただ、実装のソースじゃなくてTDDなjUnitテストケースのソース(javaDoc付き)だが。

ちなみに、
>英語が母国語な人にとっては、
>このソースはドキュメントっぽく読めるんじゃないだろうか。
この考え方はCOBOLやSQLに取り入れられてる。

85:デフォルトの名無しさん
07/04/01 22:41:55
よかったらおためしくだされｗ
URLﾘﾝｸ(d.hatena.ne.jp)

86:デフォルトの名無しさん
07/04/03 02:07:39
guice使えるよguice

87:デフォルトの名無しさん
07/04/03 12:06:39
Springは使うインターフェースがドキュメントにかかれてないとわからないけど
Guiceはモジュールを見るだけだから一目瞭然でわかりやすいな

ドキュメントが常に最新のコードをあらわしているわけではないという法則があるから
これはうれしい

88:デフォルトの名無しさん
07/04/03 22:58:17
ふうん

89:デフォルトの名無しさん
07/04/04 00:09:33
結局、俺はリファクタリングが利くのが一番いけてるところだと思うな。
XMLの書き間違い、規約の間違いみたいなものは、ビルド時に発見されるので
単純だけど問題解決に時間がかかってしまうケアレスミスみたいなのが減る。

これはプログラマの精神安定的な観点からも非常にいいことだと思う。

もっとも、リファクタリング(の自動化サポート)の価値については
Javaを使ってるさらにIDE族(多分Eclipseが最大勢力)だけしか、
価値が分かってない気がするので一般のプログラマーには
あんまりありがたみが分からないだろうなーってのも事実。

90:デフォルトの名無しさん
07/04/04 00:20:51
>>89 参考になる。
メモメモφ。

91:デフォルトの名無しさん
07/04/04 00:35:23
Springだとどのインターフェースでアクセスすればいいのかがわからないために
仕様書眺めて使うようなタイプになっちまう

>>89
タイプセーフってのは大きいよ
コンパイルが通るだけでもモジュール定義とか失敗してないのがわかるわけで
IDEのサポートがないならなおさら重要

あと実装ベースでDIする場合モジュール定義がいらないので手軽な疎結合にも十分な価値がある
おもにJavaSE側でGUIクライアント側で使う場合や小規模実装にすばらしく重要

92:デフォルトの名無しさん
07/04/04 02:02:47
>>89
だな。コンパイラがチェックしてくれるのはかなり大きい。
IDEが使える環境ならxmlもチェックしてくれるが、
使えない環境では実行時にしか分からないのが痛い。

IDE使っててもリファクタリング何それ？な奴が殆どだけどな

93:デフォルトの名無しさん
07/04/06 00:44:49
いいよGuice

94:デフォルトの名無しさん
07/04/06 22:42:09
>>92
一番はありえないだろjava使ってたらさ…とまじれす

95:デフォルトの名無しさん
07/04/06 22:43:10
×一番はありえないだろjava使ってたらさ…とまじれす
○一番下はありえないだろIDEでjava使ってるならさ…とマジレス

96:デフォルトの名無しさん
07/04/07 09:06:57
>>95
いや、ありえる。
リファクタリングとユニットテストの関係を分かってない奴だと、１度動いたソースを修正することに抵抗が在る奴らが多い。

97:デフォルトの名無しさん
07/04/07 09:40:44
リファクタリングって別にIDEでの一部の機能だけをさすわけじゃないから
動いてるソースをいじるのは誰だって抵抗はあるだろ

98:デフォルトの名無しさん
07/04/07 09:52:09
つーか
Guiceがリファクタリングにコレまで以上に貢献しているってわけでもないような・・・・

99:デフォルトの名無しさん
07/04/07 15:02:07
>>97
jUnitできちっとテストコード書いてる
テストファースト信者なおれは抵抗ないがな

100:デフォルトの名無しさん
07/04/07 16:17:24
>>99
単体テストが通るのは当たり前
それ以外の抜けが問題になる場合もあるわけで

101:デフォルトの名無しさん
07/04/07 16:24:59
>>100
それは仕様漏れでリファクタリングには関係ないだろ

102:デフォルトの名無しさん
07/04/07 21:33:51
>>99
多分これから貢献する。
Javaだけで完結すると言う事は開発現場に時々居る
プロジェクトで決められたプラグインを入れない馬鹿でも
ビルドエラーに気付けると言うことだからな。

>>100
シナリオベースの単体テストが書けてないお前が馬鹿なだけ。

まぁ、DI使おうが何使おうがとにかく一番恐ろしいのはＵＩ層にロジックを書いてしまう事だな。
SwingでもStrutsでもUIに近いところは自動化できない(難しい)領域っていうのは紛れの無い事実。
リファクタリングも実装の置き換えも、自動テスト無しでは
どうしてやっても自信を持って変更後のソースの正当性を保障する事が難しくなる。

103:デフォルトの名無しさん
07/04/07 21:57:30
>>102
シナリオベースとかそういう話以前の問題
単体テストやコードがみんなまともにできていれば苦労はせんよ
わざとバグ出してくださいっていうところも多いしな
100行に3つくらいバグがナイトテストが不十分とか言う富士通系で多いアレとか

104:デフォルトの名無しさん
07/04/08 02:48:56
パーペキなコードを書いてやったら、
テストでバグが出なくて品質に問題「あり」にされてしまった俺を助けて。

105:デフォルトの名無しさん
07/04/08 03:46:54
>>104
それはテストケース(チーム)が悪いって事にしとけ

106:デフォルトの名無しさん
07/04/11 01:07:17
2.0待ち？

107:デフォルトの名無しさん
07/04/11 01:52:22
普通に安定して動いてるよ

108:デフォルトの名無しさん
07/04/11 16:01:23
WebアプリならViewとDAOは何組み合わせるとｳﾏｰな感じ？
無難にStrutsとハイバネあたり？

109:デフォルトの名無しさん
07/04/11 16:53:34
GuiceはStruts2サポートされてるよ
DAOは何使ってもいいけどJPA使うだろうからTopLinkのほうがおそらく便利

110:デフォルトの名無しさん
07/04/13 00:57:50
実際裸のDIコンテナなんだよなー

111:デフォルトの名無しさん
07/04/13 02:11:05
>>110
その方がシンプルでいい訳だが

112:デフォルトの名無しさん
07/04/13 10:33:17
ﾄﾝｸｽ
そうだよね
シンプルたから何使っても良いのが萌え(*´Д｀)
とりあえすStruts使うとして
DAOはS2DAOとか組み合わせてみようかな…とか妄想中

113:デフォルトの名無しさん
07/04/13 11:47:37
何それ？

114:デフォルトの名無しさん
07/04/13 23:06:05
まぁ遊びならなんだっていいんじゃね

115:デフォルトの名無しさん
07/04/14 00:10:07
>>112
S2系は業務で使うのは止めといた方がいいぞ

116:デフォルトの名無しさん
07/04/15 13:04:37
グーグルジュースか。ストローがほしいなｗ

117:デフォルトの名無しさん
07/04/15 13:18:17
Guiceはぐいすと読んでしまう

しかし、依存ライブラリがないってのはいいね

118:デフォルトの名無しさん
07/04/16 01:26:44
だが結局はおざなりのライブラリの組み合わせになってしまう事実ｗ

119:デフォルトの名無しさん
07/04/16 01:53:10
>>118
元々勝手に好きなの使えってスタンスなんじゃね？

120:デフォルトの名無しさん
07/04/16 02:06:12
好きな組み合わせがGuice＋Struts＋Hibernateって
個性を主張してもやってることは皆同じｗ
しかもそれらのプロバイダーは自分で書かなきゃならんしｗ

121:デフォルトの名無しさん
07/04/16 02:10:34
逆に自作DIフレームワーク作るベースとしてはおもろいかもね

122:デフォルトの名無しさん
07/04/16 02:16:34
そうか！これからgoogle版ORマッパーを出す伏線なんだな
むしろリレーショナルDBに変わる物出してくれって気もするが

123:デフォルトの名無しさん
07/04/17 23:51:09
で
実務でつこてんの？

124:デフォルトの名無しさん
07/04/18 00:21:29
googleがつかってるな

125:デフォルトの名無しさん
07/04/18 00:22:25
あほか

126:デフォルトの名無しさん
07/04/18 00:35:58
つかってるよ

127:デフォルトの名無しさん
07/04/18 00:38:25
うそつけ

128:デフォルトの名無しさん
07/04/18 01:33:36
使いたいが、サーバーがjava5対応して無いから使えね～～～～～
これからGuiceくるぞ。
SpringとSeasarを使い込んだおれが言うんだから間違いない。

129:デフォルトの名無しさん
07/04/18 01:52:10
>>127
うそじゃないよ

130:デフォルトの名無しさん
07/04/18 02:02:48
つこてんの？

131:デフォルトの名無しさん
07/04/18 02:19:04
つこてるよ

132:デフォルトの名無しさん
07/04/18 02:22:56
ふーん。どこで？

133:デフォルトの名無しさん
07/04/18 11:32:51
業務で

134:デフォルトの名無しさん
07/04/18 11:47:55
うそつけ

135:デフォルトの名無しさん
07/04/18 11:48:42
うそじゃないよ

136:デフォルトの名無しさん
07/04/18 11:49:40
これからGuiceくるぞ。

137:デフォルトの名無しさん
07/04/18 11:50:19
>>136
どこへ？

138:デフォルトの名無しさん
07/04/18 11:52:12
googleへ。

139:デフォルトの名無しさん
07/04/18 12:02:28
あほか。

雑談はーーーーーーーー終了ーーーーーーーーー

140:デフォルトの名無しさん
07/04/18 14:53:19
I USE IT.

141:デフォルトの名無しさん
07/04/18 15:22:55
新規のプロジェクトはGuiceしか考えられないね

142:デフォルトの名無しさん
07/04/18 18:35:25
で
実務でつこてんの？

143:デフォルトの名無しさん
07/04/18 18:59:44
つこてる

144:デフォルトの名無しさん
07/04/18 19:07:37
しかしDIコンテナの数が増えるのはいただけない。
そろそろ学習コストこそがJavaの最大のボトルネックだと気づいて欲しい。
JDBC4.0がDAOの主流になることを祈るばかり。

145:デフォルトの名無しさん
07/04/18 19:10:49
JDBC4は静的なSQLしかつかえんのがな
INはコレクションわたせるようにならんかな

あとJDBC4はいまだ未完成では？

JPAともかぶりやすいのが癌

146:デフォルトの名無しさん
07/04/18 19:55:28
>>144
こんなもん１０分で覚えられるやろ

147:デフォルトの名無しさん
07/04/18 20:24:54
うそつけ

148:デフォルトの名無しさん
07/04/19 00:00:36
実は学習しないヤツがこの業界全てのボトルネックだという事実

149:デフォルトの名無しさん
07/04/19 00:03:11
全然事実じゃねーよ、混沌としすぎてRubyが持てはやされてるくらいだ

150:デフォルトの名無しさん
07/04/19 00:05:38
あほか

151:デフォルトの名無しさん
07/04/19 00:29:25
うそじゃないのに

152:デフォルトの名無しさん
07/04/19 00:32:27
オナニー言語ってことだろ
Javaは

153:デフォルトの名無しさん
07/04/19 00:42:26
Springを大体知ってりゃguiceの学習時間は10分で済むって

154:デフォルトの名無しさん
07/04/19 00:56:25
つか覚えるとこねーじゃん
なんにもないんだから

155:デフォルトの名無しさん
07/04/19 01:55:57
で
実務でつこてんの？

156:デフォルトの名無しさん
07/04/19 11:50:48
つこてるよ

157:デフォルトの名無しさん
07/04/19 21:27:23
AdWordsがGuiceつこてるらしいし、自信作らしいってことは確か。

158:デフォルトの名無しさん
07/04/19 21:49:21
あほか

159:デフォルトの名無しさん
07/04/19 21:59:43
何か湧いてるな

160:デフォルトの名無しさん
07/04/19 22:00:34
Guiceがシェアとると困る人はというと・・・

161:デフォルトの名無しさん
07/04/19 23:18:45
その内Guice用のなんたらがわんさか出てくるんかのー？

162:デフォルトの名無しさん
07/04/19 23:38:48
Struts2とかはGuiceが一番現実的だな

あとサーバーサイドではSpringなど比較的なんでもいいけど
クライアントサイドだとGuiceが一択かと

163:デフォルトの名無しさん
07/04/20 22:08:40
>>162
は？

164:デフォルトの名無しさん
07/04/20 22:15:55
>>163
使ってないやつはこなくていいよ

165:デフォルトの名無しさん
07/04/20 22:30:19
>162 名前: デフォルトの名無しさん Mail: sage 投稿日: 2007/04/19(木) 23:38:48
>Struts2とかはGuiceが一番現実的だな
>
>あとサーバーサイドではSpringなど比較的なんでもいいけど
>クライアントサイドだとGuiceが一択かと

クライアントサイド( ﾟДﾟ)

166:デフォルトの名無しさん
07/04/20 22:43:34
クライアントサイドのコードもかけないド素人かよ

167:デフォルトの名無しさん
07/04/20 22:47:48
162の人気に嫉妬

168:デフォルトの名無しさん
07/04/20 22:56:20
Guiceのことで語ることはないのがなー

169:デフォルトの名無しさん
07/04/20 23:17:00
現実のシステムで、DB回りとかのUnitTest以外で役に立つ場面てあるの？
机上の空論じゃなくて、現実のシステムで、な。

170:デフォルトの名無しさん
07/04/20 23:21:49
>DB回りとかのUnitTest以外
ソコが限定される理由もわからんがｗ

171:デフォルトの名無しさん
07/04/20 23:29:05
こいつ670KBって、クライアントじゃ起動時間が惜しくて使えないな
Class#forNameとMap<String, Deque>あたりの即席DI&プールで十分かと

172:デフォルトの名無しさん
07/04/20 23:46:56
>>171
670KBってどこのサイズ？

173:デフォルトの名無しさん
07/04/20 23:52:28
zipのサイズを言うのはおかしいな。とはいってもjarも544KBあるが。

174:デフォルトの名無しさん
07/04/21 00:05:51
というかサイズと起動時間がどう関係あるの？

175:デフォルトの名無しさん
07/04/21 00:29:42
クラスの依存関係が深ければ取り出しに時間が掛かるでしょ

176:デフォルトの名無しさん
07/04/21 00:38:24
巨大なjarがアプリケーションの起動にかける負荷を知らない奴はクソ。

「サーバーサイドなら、一度起動したら普通落とさないから」

とか知った風な事を言う奴も同様にクソ。

177:デフォルトの名無しさん
07/04/21 00:49:57
キチガイの罵詈雑言でスレが滅茶苦茶になるパターン飽きた

178:デフォルトの名無しさん
07/04/21 01:03:44
DI関係でひとつのスレッドにすりゃよかったんだ

179:デフォルトの名無しさん
07/04/21 01:05:26
世界はお前の都合に合わせて回っているわけではない。

180:デフォルトの名無しさん
07/04/21 01:07:55
ならぐだぐだでも文句は言えんな

181:デフォルトの名無しさん
07/04/21 01:14:25
死ねキチガイ

182:デフォルトの名無しさん
07/04/21 01:19:14
世界はお前の都合に合わせて回っているわけではない。

183:デフォルトの名無しさん
07/04/21 01:28:06
>>182
キチガイ>>180の相手はお前に任せたｗ
朝まで相手してやれ。

184:デフォルトの名無しさん
07/04/21 01:32:31
言ってる本人が一番基地ってるってとこが哀れだな

185:デフォルトの名無しさん
07/04/21 01:32:55
なんでここ荒れてんの

186:デフォルトの名無しさん
07/04/21 01:35:12
キチガイが出没したから

187:デフォルトの名無しさん
07/04/21 01:37:38
自己紹介乙って言われるだけだっていい加減気づけよ
ただ騒ぎ立てたいだけなんだろうが

188:デフォルトの名無しさん
07/04/21 01:38:41
荒らすなよ。よそ行ってやれ。

189:デフォルトの名無しさん
07/04/21 01:40:23
うっ、もれそう。ちょっとトイレを貸してくれないか。

190:デフォルトの名無しさん
07/04/21 01:41:14
何これ？
また異常者が自作自演してるのか？

191:デフォルトの名無しさん
07/04/21 01:42:39
キチガイほどキチガイって言葉を使いたがる良いサンプルスレになったな

192:デフォルトの名無しさん
07/04/21 01:43:13
ここでやる意味がわからん
荒らしのセンスすらゼロだな

193:デフォルトの名無しさん
07/04/21 01:44:56
でも普通に安定して動いてるよ

194:デフォルトの名無しさん
07/04/21 01:45:27
自作自演乙

溜まってるのは判ったから
とにかく荒らすな

195:デフォルトの名無しさん
07/04/21 01:46:26
>>194
荒らしは無視が一番。かまわないほうがいいよ。

196:デフォルトの名無しさん
07/04/21 01:46:32
>>194
おまえが消えろよ、学習能力ない奴だな・・・

197:デフォルトの名無しさん
07/04/21 01:47:15
>>194-197 自演乙!!!!!

198:デフォルトの名無しさん
07/04/21 01:50:30
　　　| ＼
　　　|Д｀)　ﾀﾞﾚﾓｲﾅｲ･･ｵﾄﾞﾙﾅﾗｲﾏﾉｳﾁ
　　　|⊂
　　　|

　　　　　♪　　Å
　　　♪　　　／＼　　　ﾗﾝﾀﾀﾝ
　　　　　　ヽ(´Д｀;)ﾉ　　ﾗﾝﾀﾀﾝ
　　　　　　 (　へ) 　　　ﾗﾝﾀﾗﾝﾀ
　　　　　　く　　　　　　ﾀﾝ

　　　♪　　　　Å
　　　　　♪　／＼　　　ﾗﾝﾀﾗﾝﾀ
　　　　　　ヽ（;´Д｀）ﾉ　　ﾗﾝﾀﾀﾝ
　　　　　　 (へ　 ) 　　　ﾗﾝﾀﾀﾝﾀ
　　　　　　　　 >　　　　ﾀﾝ

199:デフォルトの名無しさん
07/04/21 01:54:20
異常なまでの過剰反応っぷりに
病的なものを感じた。

200:デフォルトの名無しさん
07/04/21 01:55:37
荒らし以前に、つまらなすぎてイラっとくるわ
キティなのは知ってたけど、バカになっちゃったの？

201:デフォルトの名無しさん
07/04/21 01:56:44
544KB程度で巨大なの？
そんなに負荷かかるもんなの？
いや知らないから聞いてるんだけどね。

202:デフォルトの名無しさん
07/04/21 01:58:01
>>201
おれは十分軽いと思うんだけどね。
使ったこともないやつがふかしてるだけかと。

203:デフォルトの名無しさん
07/04/21 01:58:54
話題のつまらなさにイラッとくるわ
バカでキティなのは知ってたけど、
最近ますます心にゆとりがなくなってるな

204:デフォルトの名無しさん
07/04/21 01:59:35
>>202
そんな感じ

205:デフォルトの名無しさん
07/04/21 02:03:31
>>203
来んなよｗ
おめえが荒らすから人が少ねんだよｗ

206:デフォルトの名無しさん
07/04/21 02:04:32
ハッタリをからかうと面白いな。
ちょっとつついただけで、すぐに10も20もレスを返してくる。
もし心にゆとりがあったら軽くスルーできる程度の話。

207:デフォルトの名無しさん
07/04/21 02:05:58
ゆとりの無い奴らしかいないスレだな・・・

208:デフォルトの名無しさん
07/04/21 02:06:46
おい、ハッタリ
いい加減にしろ

209:デフォルトの名無しさん
07/04/21 02:10:01
悪いことは言わない、病院へ行け。

210:デフォルトの名無しさん
07/04/21 02:11:54
ハッタリ、もう荒すのはよせ
お前のハッタリはスレ汚しだ
さっさと首吊れ

211:デフォルトの名無しさん
07/04/21 02:14:22
なにがよせだよ
いい加減にして、豆腐スレ帰っぞ

212:デフォルトの名無しさん
07/04/21 02:18:28
>>206
いつも切迫してるから、ちょっとした事でキレまくるのな

213:デフォルトの名無しさん
07/04/21 02:20:08
それがハッタリくんの人生

214:デフォルトの名無しさん
07/04/21 08:22:44
この記事のコードだけでも俺の環境だと実行に314msだな
URLﾘﾝｸ(journal.mycom.co.jp)

Eclipse級のほかの重さでごまかせるレベルのアプリならともかく
小物アプリにたかがDIを実装するためにこの起動コストは無駄。

215:デフォルトの名無しさん
07/04/21 08:43:39
なんで小物と決め付けるの?

216:デフォルトの名無しさん
07/04/21 09:07:38
まあだいたい実務で使ってるっていってるヤツも
ゴミのような小さい規模のアプリ（っていうかアプレット？）
しか作ってないんだと思うけどね

217:デフォルトの名無しさん
07/04/21 09:28:30
大きいのにつこてるよ

218:デフォルトの名無しさん
07/04/21 09:29:03
うそつけ

219:デフォルトの名無しさん
07/04/21 09:40:31
うそじゃないよ

220:デフォルトの名無しさん
07/04/21 09:47:14
DIなしなら何msなの？

221:デフォルトの名無しさん
07/04/21 10:54:26
>>214
Springだと一分かかるぞ

222:デフォルトの名無しさん
07/04/21 10:57:25
いやいやいやいや

ほんまに…？
いや、冗談だよね？

223:デフォルトの名無しさん
07/04/21 10:59:37
マシンスペックにもよるだろう

224:デフォルトの名無しさん
07/04/21 11:15:50
ハッタリの自作自演は無駄口が多いから
延々と話題が上滑りして本質的な議論は何も行われないのが特徴

225:デフォルトの名無しさん
07/04/21 11:20:35
>>224
本質的な議論はじめていいぞ。はやくしろ。

226:デフォルトの名無しさん
07/04/21 11:22:03
ハッタリにタダで情報提供する筋合いはない。
独りでオナってろ

227:デフォルトの名無しさん
07/04/21 11:24:57
>>226
あれ？お前の嫌いなたかひろとおんなしこといってらｗ
あーあ。

228:デフォルトの名無しさん
07/04/21 11:30:10
またお前の脳内友達の話か。

229:デフォルトの名無しさん
07/04/21 11:34:28
>>226
おまえにはがっかりだよｗ
死ね

230:デフォルトの名無しさん
07/04/21 11:38:36
お先にどうぞ。

結局お前の一番ダメな所は
ハッタリこいて延々話を空回りさせて
スレに誰も寄り付かないような状況にすることだ。
パーサスレのデタラメさ加減、どーしよーもねぇだろ。
まず基礎知識をちゃんと付けろ。

あと、くだらねぇ自作自演やってる暇があったら
自分で勉強して自分で成果出して、
成果だけ発表しろ。

231:デフォルトの名無しさん
07/04/21 11:39:50
ハッタリちゃんはスルー力が足りない。
きっと、スルーしたらハッタリを認めた事になるから
スルーできないのだろう。

232:デフォルトの名無しさん
07/04/21 11:56:30
>>230
外でないから話題の少ないことｗ

233:デフォルトの名無しさん
07/04/21 11:59:55
なんだ自己分析できてるのか

234:デフォルトの名無しさん
07/04/21 12:08:17
へたっぴｗ

235:デフォルトの名無しさん
07/04/21 12:09:18
ハッタリをちょっと突付いたら一昼夜キチガイ騒ぎか
だらしねぇ

236:デフォルトの名無しさん
07/04/21 12:12:09
俺のレスみて勉強しろ。へたっぴ荒らしｗ

237:デフォルトの名無しさん
07/04/21 12:13:34
まだイジメられたいのかｗマゾかお前は

238:デフォルトの名無しさん
07/04/21 12:31:17
・基本的にスルー力が足りないのだと思う。
・「荒しに反応するのも荒し」という経験則が、
　荒し検出に非常に有効である事を再確認できた。
・同様に「キ○○○という単語に過剰反応を示す奴は、
　たいてい本人がキ○○○」という経験則が得られた。

239:デフォルトの名無しさん
07/04/21 13:17:44
DI frameworkの中じゃ一番速い訳だが

>27 名前: 1 Mail: sage 投稿日: 2007/03/24(土) 18:48:31
>>>24
>そうならないように、スピード比較結果を貼ってみる
>１回目
>Spring: 1,734 creations/s
>Guice: 35,161 creations/s
>S2: 18,395 creations/s
>２回目
>Spring: 1,776 creations/s
>Guice: 37,202 creations/s
>S2: 19,394 creations/s
>３回目
>Spring: 1,783 creations/s
>Guice: 36,764 creations/s
>S2: 19,164 creations/s
>
>数字大きい方が速いって事で。
>
>URLﾘﾝｸ(d.hatena.ne.jp)

240:デフォルトの名無しさん
07/04/21 14:26:30
それはDIコンテナの初期化そのものじゃないから計測対象が違う。
サーバ用途としては今後筆頭のDIコンテナになるだろうことは確か。
Springからしても競合相手じゃなくて補完してくれるサービスプロバイダってだけ。

241:デフォルトの名無しさん
07/04/21 16:51:38
サーバープログラムで起動時間が多少かかったとしても問題あるとは思わんがな

>>240
補完？あきらかにベースを置き換える物なんだが
Guice理解してるか？

242:デフォルトの名無しさん
07/04/21 16:53:04
クライアントで0.1秒起動が遅れても問題があるとはおもえないけどな

243:デフォルトの名無しさん
07/04/21 16:55:21
GWTの例もあるし、単にGoogleってだけで広まるとは思えない
革命的に既存のDIコンテナとは違う！という機能を提供してるわけでもないしな

244:デフォルトの名無しさん
07/04/21 16:59:54
・軽量であること
・タイプセーフであること
・従来のコードでもすぐに実装可能なこと
・上記によって拡張がしやすいこと

245:デフォルトの名無しさん
07/04/21 17:04:05
>>241がSpringを理解してないだけ。

246:デフォルトの名無しさん
07/04/21 17:20:35
>>241
Springの一部を肩代わり出来るモジュールだな。
まぁ、DI部分だからベースと言えん事もないが

247:デフォルトの名無しさん
07/04/21 19:02:11
こいつの発言がいつも挙動ってるのはデフォ？

248:デフォルトの名無しさん
07/04/21 19:13:18
>>247
アペオスは飛ばないし、Googleは挙動らないだろう？

249:デフォルトの名無しさん
07/04/21 19:18:54
>>247
自作自演の人だから。
時々ツッコミが入ると挙動る。

250:デフォルトの名無しさん
07/04/21 23:29:49
で？

251:デフォルトの名無しさん
07/04/21 23:49:11
つこてるよ

252:デフォルトの名無しさん
07/04/22 00:10:48
大きいのにもつこてるか？

253:デフォルトの名無しさん
07/04/22 00:38:16
つこてるよ

254:デフォルトの名無しさん
07/04/22 00:38:55
サンクス！

次ページ