- 1 名前：デフォルトの名無しさん [2007/03/24(土) 09:34:46 ]
- 無かったので立ててみた。
code.google.com/p/google-guice/
- 2 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 09:45:50 ]
- 鼬害
- 3 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 09:46:13 ]
- これなんて読むんだ？
juice→ジュースだから
グース？
- 4 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 10:11:04 ]
- pronounced 'juice'
って書いてあるじゃん。
ってかまたDIか。本気でDIいけてると思ってる奴どんだけ
いんのよ？流行で触ってみた、使ってみたじゃなくてさ。
心底、これはスゲーって思ってる奴いる？
- 5 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 10:24:14 ]
- DIなんてJavaが駄目言語であるがゆえに存在するものだからなあ
- 6 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 10:34:07 ]
- ＤＩいけてないって思うヤツに
プログラムを書かせてはいけない
- 7 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 11:11:11 ]
- >>4
普通に１００人規模の開発で使ってるんだが。。
- 8 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 11:12:37 ]
- >>4
DI無しでの単体テストなんてもう考えられないな。
DIは単体テストの為にあるって言ってもいいかも。
- 9 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 11:15:59 ]
- >>6
書き方が悪かったな。
ＤＩいけてると判断して使ってる奴がどれだけいますかー？
ＤＩいけてないと判断して使ってない奴がどれだけいますかー？
って事だけ。流行に躍らされてないで、DI理解して
DIDIって言ってる奴が何割いるのかと。
- 10 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 11:17:51 ]
- >>9
DIはいけてるが既存のフレームワークは最悪。
guiceはちょっとましになったかなという程度か。
- 11 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 11:31:10 ]
- DIなんて聞いたこともないわけだが。
まったく次から次へと焼き畑農業のようにゴミライブラリ撒き散らして悦に入っている
Java厨は本当に度し難いな。
- 12 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 11:46:14 ]
- まぁＣ/Ｃ＋＋何ぞでは、ＦＷ作る意味すらないからな
- 13 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 13:57:12 ]
- リフレクションが使いにくい言語にはDI適用は困難
ダックタイピングが有る言語にはDIは不要
- 14 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 14:58:31 ]
- DIってDLLみたいなもんだろ。
デバッグ情報含んだDLLをデバッガで動き見て
リリースモードのDLLにして納品みたいな。
- 15 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 16:37:09 ]
- >>14
違う予感
え、そうなの？
不安になってきた。
- 16 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 16:39:55 ]
- うさんくせぇ〜〜〜〜〜
Java開発を変える最新の設計思想「Dependency Injection（DI）」とは
itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050216/156274/?ST=develop&P=2
- 17 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 16:51:38 ]
- 国際化対応もDLLにリソースぶち込んで、ロケール見て切り替えってのもそう？
- 18 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 16:53:56 ]
- なんだよＤＬＬって
Windows厨はでてけよ
- 19 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 17:04:47 ]
- soもDLLっていうが
- 20 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 17:07:40 ]
- EJBが糞過ぎてそれをどうにか他環境並みの疎結合に引き上げてくれる夢の新技術がDIってことか
- 21 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 17:24:01 ]
- ﾅﾆこのスレ
ＤＩわからん香具師は出てけ
- 22 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 18:06:20 ]
- >>14
DLLて。。
勘違いにも程があるな。少なくともぐぐってから書き込め
- 23 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 18:07:48 ]
- 大して違わないことに気づいても無い奴よりマシだと思う
- 24 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 18:17:54 ]
- しかし徹頭徹尾無内容なスレだな。
- 25 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 18:42:19 ]
- DIなんぞやから語る事自体は悪い流れではなかろう
問題はこの煽り合いの流れが意地の張り合いで終わるのかどうか
- 26 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 18:42:47 ]
- スレタイにDIなんて入れるから中途半端なのが入ってくるんだ。
- 27 名前：1 mailto: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
数字大きい方が速いって事で。
d.hatena.ne.jp/arumani/20070315/p2
スレの内容見るとこのネタじゃ盛り上がらなさそうだけど(´・ω・｀)
- 28 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:18:07 ]
- 軽量で高速なDIコンテナは需要あるんじゃない？
うちじゃSpring使ってるけど、サーバ起動時の待ち時間は異常
- 29 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:23:29 ]
- つーかＤＬＬとＤＩを同じ基準で比較するバカどもウゼー
- 30 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:27:46 ]
- バインディングをコード書いてやらなあかんのがなー
Springで定義したのをGuiceで運用するってのがいいのかなーｗ
- 31 名前：1 mailto:sage [2007/03/24(土) 19:28:30 ]
- >>28
個人的には、DI定義XMLが無い所がかなり気に入ってる。
リファクタリング手軽に出来るしね。
- 32 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:32:43 ]
- >>31
へー。実例とかあったら見てみたい。
- 33 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:41:48 ]
- 悪りい、ここにドキュメントあったわ
code.google.com/p/google-guice/w/list
- 34 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:41:59 ]
- jarを(dll)をどうロードするかでしかないんだから
こんなものありがたがってる奴らはドカタだわな
- 35 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:46:04 ]
- >>34
いいからコボラーは引っ込んでろ
- 36 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:48:03 ]
- >>34
むかしはファクトリのコードを手で書いてたんだから、かかなくて良くなりゃ
それに越したことはないと思うんだけど。
- 37 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:51:45 ]
- だが、バインディングコードを書く時点で「コードを書く」こと自体は従来と同じ（戦略はともかく）
アノテーションのみだったらまだ違うけど
- 38 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:56:19 ]
- 春休み明けに立てればよかったのに
- 39 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:57:08 ]
- ユーザガイドざーっと読んでみた。とりたてて目新しいことは無いな。
>>37
コードでもバインディングできますよ、ってだけで基本アノテーションのみ
じゃないの？
- 40 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:57:36 ]
- まったくだな、>>38みたいな盲目な人間が消えてくれる
- 41 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 20:04:48 ]
- ソースをざーっと読んでみた。とりたてて目新しいことは無いな。。
googleは何でこれ作ろうと思ったんだ？？
- 42 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 20:06:00 ]
- 作ったアプリの中からスピンオフしただけだろ
企業発のコードなんざ大抵そうだ
- 43 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 20:11:28 ]
- へー、そういうものなのね。
- 44 名前：1 mailto:sage [2007/03/24(土) 20:23:16 ]
- >>39
いや。バインディングのコードは必ず必要。
- 45 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 20:32:28 ]
- 簡単なDIだけでいいなら不要だけど
多分それじゃもの足りんよねー
- 46 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 20:40:02 ]
- >>41
思うに、実行速度を早くしたかったのかと・・・・
Springの定義から作ったものをGuiceに上で高速に
動かしたいんじゃないの？
- 47 名前：1 mailto:sage [2007/03/24(土) 20:45:04 ]
- >>41
バインディングがコードで書けると
jUnitで単体テストが書けてとても嬉しいよ。
XMLの場合、結合しないとテスト出来なかったから。
- 48 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 20:51:04 ]
- オリは逆にDJUnitでコードバインディングみたいにコーディングしてダミーのクラスとか入れ込んでたけど
XMLで定義できたらなぁとか思ってたｗ
- 49 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 21:10:16 ]
- >>47
ん？手でmockをセットすればテストできるけど、そういう話じゃないよね？
- 50 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 21:14:17 ]
- ちら裏スマン
4月から超ファイヤープロジェクトに放り込まれそうだ。
ってか、燃えカスしか無いかも。。。
漏れは製造系の会社のIT分門で、9ヶ月前ぐらいにIT系の会社から
社内SEとして転職。で、問題のプロジェクトは工場で使う生産系の
システムを外部に請負で発注。テストもてきとうで、少し前から触るとなんか出る
って感じでやばいのがどかどか出てきた（ってか根幹の仕組み自体が破綻してるみたい）。
検収上げなきゃ良いじゃんって思ったけど、こっちの期末処理の関係で
3末で検収ださなあかんのだとｗｗｗ
保守契約は無し。構築中にスキトラ受けて自分らでやる予定だったみたい。
で、どうするかなーと思い、BLだけ切り出してきてDIでくっ付けなおそうかと。
BLの部分はJavaの基礎と最低限のライブラリの知識で作れるようにして
業務を知ってる社内のエセSEをちょっと鍛えて作ってもらうと。
数億の仕組みだから1人じゃどうにもならんので、人海戦術使うならこんな感じかなと。
立て直るかはプロジェクトの進め方で7割は決まると思っていて
やり方は色々あると思う。ただ、バグを1つ1つ潰してたら、きりが無い
という噂が流れてきてるから、上記みたいな事を考えてる。
まだ自分で蓋を開けてないから変わるかもしれないけどね。
- 51 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 21:41:49 ]
- フルスクラッチするなら幾らでもやりようがあるがノー
結局そうした方がいい場合が多いんだけどねー
目先の予算やら何やらでお茶を濁すと結局は本質的な問題が
解決されずにグダグダするだけだったりして・・・
- 52 名前：50 mailto:sage [2007/03/24(土) 22:25:49 ]
- >目先の予算やら何やらでお茶を濁すと結局は本質的な問題が
>解決されずにグダグダするだけだったりして・・・
まったくです。でも4月からの予算枠も当然取ってないですとｗｗｗｗ
って事で、社内要員でなんとかするしかなさそ。
1年以上やってるプロジェクトだから、なんとか活かせる部分は
活かして短期決戦に持っていきたい。
- 53 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 22:59:58 ]
- ∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵。∴∵
∴∵∴∵:。∴∵∴∵∴: --─- ∴∵∴∵∴∵∴∵
∴∵゜∴∵∴∵∴∵ （___ ）（___ ） >>50∵∴∵ ゜
∴∵∴∵∴:∵∴∵_ i/ ＝ ＝ヽi ∴∵∴∵。∴∵∴
∴∵☆彡∴∵∵ ／/[|| 」 ||] ∴:∵∴∵∴∵:∴∵
∴∵∴∵∴∵ / ﾍ | | ____,ヽ | | ∴:∵∴∵∴∵:∴∵
∴ﾟ∴∵∴∵ ／ヽ ﾉ ヽ＿＿./ ∴∵∴∵:∴∵∴∵
∴∵∴∵ く / 三三三∠⌒＞ ∴:∵∴∵:∴∵
∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∵∴∵∴∵
∧∧ ∧∧ ∧∧ ∧∧
（ ）ゝ （ ）ゝ（ ）ゝ（ ）ゝ ムチャしやがって・・・
i⌒ / i⌒ / i⌒ / i⌒ /
三 | 三 | 三 | 三 |
∪ ∪ ∪ ∪ ∪ ∪ ∪ ∪
三三 三三 三三 三三
- 54 名前：>>46 mailto:sage [2007/03/25(日) 01:53:21 ]
- 全然チゴタ
- 55 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 02:59:38 ]
- >>56は間違ってるけど適当に脳内補完してくださいｗ
- 58 名前：1 mailto:sage [2007/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 mailto:sage [2007/03/25(日) 17:38:09 ]
- 間違ってた
Injector inj = Guice.createInjector(MyModuleMock.class);
↓
Injector inj = Guice.createInjector(new MyModuleMock());
- 60 名前：55-57 mailto:sage [2007/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 mailto:sage [2007/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 mailto:sage [2007/03/25(日) 22:09:18 ]
- むむむむむむ・・・・・
っていうか、switch文で解決しようとすると、条件が増減したりすると
ソコのコードを書き換えなきゃでしょ？
switch文を書かないようにすることが主目的なんだけどなー
条件と処理のマッピングが設定で出来れば条件の追加はコーディング不要になるでしょ
少なくともMapなどのコレクションでの解決は、コレクション要素の追加だけで
修正が出来るからいい解決方法かな？と思ってるんだけどね
Springの場合は<map>に<entry>を追加するだけでいいんだけど
Guiceは要素を追加するコードは書かなきゃならんようだなー
- 63 名前：55-57 mailto:sage [2007/03/25(日) 23:22:43 ]
- あと>>60はこうでした
switch(key){
case 1:
// １の時の処理
break;
case 2:
// 2の時の処理
break;
case 3:
// 3の時の処理
break;
}
- 64 名前：1 mailto:sage [2007/03/26(月) 21:27:58 ]
- >>62
あ〜ようはCommandインスタンスのMapをインジェクションしたいと。
それならProviderでラッピングしてやれば出来るけど
Springより面倒だね(´・ω・`)
- 65 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 22:06:15 ]
- >>1
ｲﾀｲｿﾞ
- 66 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 16:09:29 ]
- とりあえず日本語の情報源っぽいもの
Users Guide翻訳
d.hatena.ne.jp/shot6/20070320#1174359874
なんか色々試してるブログ（のリンク）
www.wikihouse.com/arumani/
- 67 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 09:49:33 ]
- よし
XML定義ファイルからModuleを自動生成して登録する拡張を作るぞ
- 68 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 11:23:56 ]
- >>67
わかった
ならおれはOGNL実装する
- 69 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 12:15:35 ]
- SpringのXMLファイルをそのまま使ったらまずいかしら？
- 70 名前：デフォルトの名無しさん [2007/03/31(土) 14:08:45 ]
- >>69
お！それいいね！
- 71 名前：デフォルトの名無しさん [2007/03/31(土) 14:15:32 ]
- >>50
javaのお仕事ってこういうのが多いのかね？
- 72 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 01:54:39 ]
- XMLでbindの定義したのを読み込んで、Module内でバインディングしようとしたら
bindする型をはっきりさせないと遺憾からXML定義による自動バインディングは
できんかった・・・
バイトコードいじれば出来るのかしら？
しかしそれはメンドイ
やはりXMLからModeuleクラスを作るようにしよか・・・
- 73 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 10:07:58 ]
- >>72
おまいは本気でxmlで定義しようとしてるのか！？
あぁ。。４月１日か。。
- 74 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 10:32:36 ]
- バインド定義をコーディングするのはオレてきにメンドイ
- 75 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 11:08:29 ]
- 続きはWebで・・・・
d.hatena.ne.jp/guiceex/
（ここもWebだが）
- 76 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 11:29:47 ]
- >>74
なら、SpringかSeasar使えと。。
Guiceの利点はxmlを使わない所にある。
- 77 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 11:43:18 ]
- コードでバインディングめんどいかー？エディタで補完効いて快適じゃん。
- 78 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 11:48:03 ]
- コードをゴリゴリかくのメンドイし、どうバインディングされてるかわかりにくいのが良くないと思う
最終的にはExcelで定義したバインディング仕様からModuleクラスが作れればいいかなと・・・・
まぁ挫折してもエイプリルフールってことでｗ
- 79 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 12:02:20 ]
- >>78
１０年程PGや設計やってきて出した俺的結論としては
PGのコード記述するのに、外部ファイルや自動生成系は使うなだな。
自動生成やるにしても、最初の１回だけで後は使わない。
理由は単体テストがやりにくい・リファクタリングが自動で出来ないのと、
管理がめんどいから。
自動生成で作成したJavaソースはいじらないってルール作っても、
従わないヴァカがいっぱいいるんだよ世の中。
78はまだ若そうだが、いずれ分かるようになるさ。
- 80 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 12:11:55 ]
- マダマダ若いなｗ
１５年この業界にいてフレームワークを作り続けてきた俺の結論は
ドキュメント＝実行モジュールになるのがもっとも生産性が高いってこと
幾らプログラム作ってもドキュメント化されないと保守できない
システムのメンテナンスは同じ人間がやれるわけでもないし、
新しい人間がスグに使えるようになる必要もあるのだよ
プログラマからすれば自分の作業が問題なければそれでいいカモしれんが
それじゃいかん
- 81 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 12:34:02 ]
- >>80
ま〜理想で言えばそうだが、現実は違うわなw
ドキュメント書くだけでJavaソース作ってくれる
某G○nってツール使った事あるんだが、パフォーマンス糞だったぞ？
いくら生産性高くて(特殊なツールで生産性高いとは言えなかったが。。)
シス方と開発がウハウハでもユーザー不在なのはどうかと。
ドキュメント書くのはSEの仕事だから、
PGはJavaDocさえきっちり書いとけばいいんじゃね？
- 82 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 12:48:14 ]
- ドキュメント＝実行モジュールと考えるからよくない。
実行モジュール＝ドキュメントと考えればいいんだ。
つまり、ソースがそのままドキュメントになる。
guiceは、メソッドがinとかtoとかになってるんだが、
英語が母国語な人にとっては、
このソースはドキュメントっぽく読めるんじゃないだろうか。
- 83 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 12:57:43 ]
- >>81
1から10までってのは難しいと思うけど、インターフェイスの部分て言うのは
わかりにくいからドキュメント化したいし、バグの温床でもあるからねぇ。
例えばエンティティクラスやStrutsのActionFormのようなデータインターフェイス
は自動生成して、データの転送はリフレクションを使ったプロパティコピー
ユーティリティのようなもの（commons-beanとか）でコードを極力書かない
ようにしたほうがバグも少ないし生産性も高い。
Guiceの場合はGuiceとアプリケーションのインターフェイスであるModule
を自動で作ったりバインドしたりする方がそのインターフェイス間での問題が
少なくなるし、どんなバインディングしてるのかが第3者にもわかりやすくなる。
>>82
Hibernateもそうだけど、
hoge.createSQLQuery(...).
.addEntity(.....)
.setString(....)
.list()
見たいな続けて書くのがはやってるね。
こういうプログラムを書のは面白いと思うけどｗ
- 84 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 13:23:12 ]
- >>82
ドキュメント＝実行モジュールも
実行モジュール＝ドキュメントも同じ意味なんぢゃ。。
ソースがそのままドキュメントになるのは同意。
ただ、実装のソースじゃなくてTDDなjUnitテストケースのソース(javaDoc付き)だが。
ちなみに、
>英語が母国語な人にとっては、
>このソースはドキュメントっぽく読めるんじゃないだろうか。
この考え方はCOBOLやSQLに取り入れられてる。
- 85 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:41:55 ]
- よかったらおためしくだされｗ
d.hatena.ne.jp/guiceex/20070401
- 86 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 02:07:39 ]
- guice使えるよguice
- 87 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 12:06:39 ]
- Springは使うインターフェースがドキュメントにかかれてないとわからないけど
Guiceはモジュールを見るだけだから一目瞭然でわかりやすいな
ドキュメントが常に最新のコードをあらわしているわけではないという法則があるから
これはうれしい
- 88 名前：デフォルトの名無しさん [2007/04/03(火) 22:58:17 ]
- ふうん
- 89 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:09:33 ]
- 結局、俺はリファクタリングが利くのが一番いけてるところだと思うな。
XMLの書き間違い、規約の間違いみたいなものは、ビルド時に発見されるので
単純だけど問題解決に時間がかかってしまうケアレスミスみたいなのが減る。
これはプログラマの精神安定的な観点からも非常にいいことだと思う。
もっとも、リファクタリング(の自動化サポート)の価値については
Javaを使ってるさらにIDE族(多分Eclipseが最大勢力)だけしか、
価値が分かってない気がするので一般のプログラマーには
あんまりありがたみが分からないだろうなーってのも事実。
- 90 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:20:51 ]
- >>89 参考になる。
メモメモφ。
- 91 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:35:23 ]
- Springだとどのインターフェースでアクセスすればいいのかがわからないために
仕様書眺めて使うようなタイプになっちまう
>>89
タイプセーフってのは大きいよ
コンパイルが通るだけでもモジュール定義とか失敗してないのがわかるわけで
IDEのサポートがないならなおさら重要
あと実装ベースでDIする場合モジュール定義がいらないので手軽な疎結合にも十分な価値がある
おもにJavaSE側でGUIクライアント側で使う場合や小規模実装にすばらしく重要
- 92 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 02:02:47 ]
- >>89
だな。コンパイラがチェックしてくれるのはかなり大きい。
IDEが使える環境ならxmlもチェックしてくれるが、
使えない環境では実行時にしか分からないのが痛い。
IDE使っててもリファクタリング何それ？な奴が殆どだけどな
- 93 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 00:44:49 ]
- いいよGuice
- 94 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 22:42:09 ]
- >>92
一番はありえないだろjava使ってたらさ…とまじれす
- 95 名前：デフォルトの名無しさん [2007/04/06(金) 22:43:10 ]
- ×一番はありえないだろjava使ってたらさ…とまじれす
○一番下はありえないだろIDEでjava使ってるならさ…とマジレス
- 96 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 09:06:57 ]
- >>95
いや、ありえる。
リファクタリングとユニットテストの関係を分かってない奴だと、１度動いたソースを修正することに抵抗が在る奴らが多い。
- 97 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 09:40:44 ]
- リファクタリングって別にIDEでの一部の機能だけをさすわけじゃないから
動いてるソースをいじるのは誰だって抵抗はあるだろ
- 98 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 09:52:09 ]
- つーか
Guiceがリファクタリングにコレまで以上に貢献しているってわけでもないような・・・・
- 99 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 15:02:07 ]
- >>97
jUnitできちっとテストコード書いてる
テストファースト信者なおれは抵抗ないがな
- 100 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 16:17:24 ]
- >>99
単体テストが通るのは当たり前
それ以外の抜けが問題になる場合もあるわけで
- 101 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 16:24:59 ]
- >>100
それは仕様漏れでリファクタリングには関係ないだろ
|
 |
