- 1 名前：デフォルトの名無しさん mailto:sage [04/02/23 00:51]
- www.springframework.org/
乱立するフレームワークと競合するプロトコルの嵐のなかで、
リスクの高い決断を余儀なくされているJavaデベロッパ、プ
ロジェクトマネージャに対する福音です。
語るべし。
- 237 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:44:57]
- 強い型付けだからこそ、DIコンテナが生きるんだよ。
ビーン定義ファイルは型による事前検証が可能だしね。
- 238 名前：デフォルトの名無しさん [04/12/06 00:59:40]
- コンパイル時に検証できないうえにファクトリでダウンキャストしないといけないのに？
- 239 名前：デフォルトの名無しさん mailto:sage [04/12/06 03:47:22]
- >>238
> コンパイル時に検証できないうえにファクトリでダウンキャストしないといけないのに？
周辺ライブラリを使えばダウンキャストは不要。
例えばStrutsのActionに最初から依存Serviceへの
参照がセットされてるとか。
というかむしろダウンキャストしない使い方が標準。
- 240 名前：デフォルトの名無しさん mailto:sage [04/12/06 11:23:48]
- >>238
Javaソースを検証するコンパイル時に、Bean定義を検証する必然性はあるの？
別でいいじゃん。
- 241 名前：デフォルトの名無しさん mailto:sage [04/12/07 00:01:00]
- ま、大きくなったらわかるさ。
- 242 名前：デフォルトの名無しさん mailto:sage [04/12/07 01:01:32]
- >>241
今知りたい。
コンパイル時に検証したい理由。
たとえばantで別の検証タスクを作ってもいいし、簡易なら、単にビーン定義を読み込むだけの検証用プログラムを作ればいいと思うんだが。
- 243 名前：デフォルトの名無しさん [04/12/09 00:31:01]
- >>239
なるほど、やっぱダウンキャストは勝手にやってくれって感じだよな
>>242
Javaしか知らん奴には弱い型付けとか言ってもわからんのだろう
藻前は却下
- 244 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:12:30]
- >>243
弱い型付けってなんですか？
- 245 名前：デフォルトの名無しさん [04/12/09 01:38:48]
- >>244
www.google.com/webhp?hl=ja
ほれ
- 246 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:47:22]
- >>245
「弱い型付け」で検索したら、Server Errorでますた(T-T)
- 247 名前：デフォルトの名無しさん [04/12/09 01:53:30]
- >>246
釣りはいいからさっさと調べろボケ
- 248 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:53:33]
- 型の指定が「無い」ことを「弱い型付け」と呼んでいいんですか？
- 249 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:54:12]
- >>247
ほんとに出たんだって。
GoogleのServer Error
- 250 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:58:01]
- ところで、Bean定義がコンパイル時に型解決できないのを、コンパイルとは別にBean定義の検証してもいいんじゃないの？っていう疑問は解決できませんでしたよ。
- 251 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:51:24]
- 設定ファイルの不備が実行時でないと検出できないってのは効率が悪すぎる。
で、自分はこんな感じでAntを使用してチェックしてるんだが、どうよ？
1.spring-beans.dtdを利用して、DTDレベルの妥当性のチェックをする。
2./beans/bean/@classの値がクラス名として正しいのか検証する。
1.はAntのXMLValidateタスクを使用。
2.はXPath + java.net.URLClassLoaderを使用しAnt拡張タスクを自作して使用。
まぁ、DTDレベルの妥当性チェック + クラス名チェックなんで完全とまではいかないが、
実行時前にチェック出来るんで、だいぶ楽になった気がするな。
- 252 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:53:16]
- >>251
だから、とりあえず設定ファイル読み込むだけのプログラム作って、それでエラー検出してもらうんじゃだめなの？と。
なんならそれをAntのタスクにしてもいいし。
- 253 名前：デフォルトの名無しさん [04/12/10 01:18:09]
- java房は世の中javaしかないと表ますね
- 254 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:31:46]
- 別に普通にJUnitでテストしたらいいじゃん。
- 255 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:44:05]
- テスト至上主義は現実を考えるとどうかと思うよ。
毎回すべてをテストすることは難しいし。
- 256 名前：デフォルトの名無しさん mailto:sage [04/12/10 23:44:01]
- >>255
ANTやMavenでプロジェクトに組み込んでしまえば
自動でやってくれるじゃん。
- 257 名前：デフォルトの名無しさん mailto:sage [04/12/11 03:45:44]
- >>256
テストを自分で作らないかぎりは、自動でテストしてくれない。
- 258 名前：デフォルトの名無しさん mailto:sage [04/12/11 10:02:07]
- そこでJTestですよ。
- 259 名前：デフォルトの名無しさん mailto:sage [04/12/11 11:05:36]
- >>251
SpringIDEが、それぐらい、やってくれるんじゃないの。
- 260 名前：デフォルトの名無しさん mailto:sage [04/12/11 11:39:36]
- コンパイラは誰でも必ず起動するってことだろ。テストはやらない人もいる。
というかやらない馬鹿もいるわけで。でも馬鹿でもコンパイルだけはする。
- 261 名前：デフォルトの名無しさん mailto:sage [04/12/11 12:48:25]
- >>257
つまらんテスト仕様書を書く（しかもExcelで！）
よりテストコードを書くほうが楽しいと思わないか？
細かい修正のリリースの度に
テスト仕様書に則ってテストするのは
本来ならあたりまえの作業のはずなんだが
殆ど真面目に実行されていない。
テスト仕様書なんか納品前にでっち上げられる始末。
（銀行の勘定系とかはちゃんとやるけど）
それがmake（の相当品）に組み込まれているなら
便利だと思わないか？
- 262 名前：デフォルトの名無しさん mailto:sage [04/12/11 14:05:56]
- >>261
> 細かい修正のリリースの度に
> テスト仕様書に則ってテストするのは
> 本来ならあたりまえの作業のはずなんだが
> 殆ど真面目に実行されていない。
細かいメソッド作成の度に
テストファーストに則ってテストを作成するのは
本来ならあたりまえの作業のはずなんだが
殆ど真面目に実行されていない。
というのと違いはあるのかな？
- 263 名前：デフォルトの名無しさん mailto:sage [04/12/12 00:32:30]
- >>262
目視テストでは修正リリース時に毎回再実施のコストがかかる。
「真面目に実行」されていないのはリソース不足が理由。
自動テストでは上記の再実施のコストは激減する。
「真面目に実行」されないケースは開発者のスキル不足と
腐敗アーキテクチャが理由。
以上。
- 264 名前：デフォルトの名無しさん mailto:sage [04/12/12 02:57:00]
- >>263
> 自動テストでは上記の再実施のコストは激減する。
再実施のコストが激減しても、テスト初回のコストは激増するわけだろ。
> 「真面目に実行」されないケースは開発者のスキル不足と
> 腐敗アーキテクチャが理由。
これが通常のテストに当てはまらない理由と
> 目視テストでは修正リリース時に毎回再実施のコストがかかる。
> 「真面目に実行」されていないのはリソース不足が理由。
これがテストファーストに当てはまらない理由を教えてもらいたい。
- 265 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:58:07]
- >>255
俺もそう思わんでも無いけど、そう思うのは自分の技能不足だということに気づいた今日この頃
- 266 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:59:42]
- JUnit in Action 嫁。
- 267 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:12:50]
- >>265
チーム全員、すべてのプロジェクトで徹底するのが難しいんだよ。
- 268 名前：デフォルトの名無しさん mailto:sage [04/12/12 21:09:02]
- >>265
つまり、ユニットテストというのは、個人の能力に依存することになるんだよね。
で、ユニットテストに依存するということは、チームの個々人の能力に依存することになる。
安定して開発するための一般的な手法としては、テストファーストはお勧めできない。
- 269 名前：デフォルトの名無しさん mailto:sage [04/12/13 00:10:47]
- そういうことを想定してたからこそ、ペアプロって発想が出てきたんだと予想してみる。
- 270 名前：デフォルトの名無しさん mailto:sage [04/12/13 01:28:06]
- ペアプロって人月が倍になるように見えるんだけど間違ってる？
典型的な請負DQNシステムの場合、そういう余剰な工数ってどこから
捻出できるの？
- 271 名前：デフォルトの名無しさん mailto:sage [04/12/13 01:49:37]
- XPの本で読んだだけだけど、研究によると、ペアプロをするとコーディング時間は
確かにのびるが、２倍の200%ではなくて、115%くらいになるそうだ。でその15%分、
品質が15%あがるらしい。どうやって計ったのかは知らない。
- 272 名前：デフォルトの名無しさん mailto:sage [04/12/13 11:56:23]
- そうじゃなくて2人分の金が必要って話になるんじゃないかってことだろ。人月だから。
- 273 名前：デフォルトの名無しさん mailto:sage [04/12/13 13:03:39]
- 二人分の金が必要なのは当たり前だ。二人いるならね。どんな手法だろうが
二人いるなら二人分の金がかかる（奴隷でない限り）。
で二人で一緒に仕事すると、一人で別々にやる場合と比べて生産性が半分になりそうな
ので、費用も倍になりそうだという話じゃないか？
実際には別々にやった時と同じくらいの生産性を（つまり二人で二人分）を出す（らしい）と
いうことなんだが。
まあほんとかどうかは知らない。
- 274 名前：デフォルトの名無しさん mailto:sage [04/12/13 13:20:16]
- 問題は、プログラムには単純作業的なものが多くて、ペアプログラミングの効率のよさが得られるところが少ないってことじゃないのかな？
データベースからとってきた値をJSPに流し込むのって、ただの作業だし。
- 275 名前：デフォルトの名無しさん mailto:sage [04/12/13 20:04:55]
- >>273
> で二人で一緒に仕事すると、一人で別々にやる場合と比べて生産性が半分になりそうな
> ので、費用も倍になりそうだという話じゃないか？
そうそう、そういいたかったんだ。ありがとう。
- 276 名前：デフォルトの名無しさん mailto:sage [04/12/13 21:49:00]
- >>268
それはユニットテストだのＴＤＤだの以前に、
きちんとバグのないソフト作るとか、きちんとテストできるとか、きちんとデバッグできるだとか、
ある程度個人の能力に依存するのは当然だと思うぞ。
１００人の人間がいて、１００人とも皆が同じ答えを出すっていうのは人間じゃないぞ。
- 277 名前：デフォルトの名無しさん mailto:sage [04/12/13 22:11:52]
- >>276
コンパイラでチェックできるのなら、100人の人間がいて、コンパイルに通っていれば、100人とも皆が書いたコードがチェックに通っている。
- 278 名前：デフォルトの名無しさん mailto:sage [04/12/13 23:48:13]
- なんだかいつの間にかテストの有効性の話になってるが、もともとは、
コンパイラで型チェックさせるなんて意味あんのか、別の方法でチェックしても
いいじゃん、という話だったんじゃないか？
おれは>>260と同じ理由で価値があると思ってるけど。
- 279 名前：デフォルトの名無しさん [04/12/25 14:58:37]
- 今月のJavaWorldの記事でGeronimoの記事を読んでたんだけど
コア部分はDIコンテナなんだね。MBeanで定義した各サービスをDIコンテナを使って依存性注入したり
独自のサービスをMBean化して公開出来るようになるらしい
記事には書いてなかったけど、そのDIコンテナってSpringを使ってるそうだし
今後は、APサーバーがDIコンテナを核として構築されるのが主流になっていくのだろうか
- 280 名前：デフォルトの名無しさん mailto:sage [04/12/26 00:04:13]
- 俺様フレームワークを作るときにいつも困ってるのが「Factoryの提供の仕方」だったからな。
GBeanという形でFactoryを隠すことで、コンポーネントの利用者はサービスのみを享受できる。
サービスを提供したいのに、サービスを利用する準備から伝えないといけないのは、提供側も利用側もめんどくさい。
DIコンテナがあれば、提供者が好き勝手にFactoryを準備できる。
来年からやるプロジェクトではぜったいDIコンテナ使う。
S2よりはSpringだな。
- 281 名前：デフォルトの名無しさん mailto:sage [04/12/26 00:18:57]
- >>279
内部がSpringって、あのAOPが自分のインスタンスメソッド呼び出しには適用されない問題は
大丈夫なのかな。（クラスＡのset.*にaspectを適用したら、最初に呼び出したsetHogeには
Aspectが適用されるけど、setHogeからthis.setHageを呼んだらAspectが適用されない問題）
実装の仕方みて「あーなるほどこりゃ自分で自分のメソッド呼んだら適用されないなー」と
思いはしたが、AOP的には困ったもんなのでまじなんとかしてほしい。
- 282 名前：デフォルトの名無しさん mailto:sage [04/12/26 00:32:48]
- 一番使われるトランザクションとかログてきには、あまり困らないのでなんとかしないんじゃない？
するかな？
- 283 名前：デフォルトの名無しさん mailto:sage [04/12/26 00:40:09]
- おい、「setなんたらというのが呼ばれたら全部ログ吐け」ってのが、ちゃんと
動かない（ことがある）ってことわかってるか？
- 284 名前：デフォルトの名無しさん [04/12/26 00:44:11]
- >>281
GeronimoはAOPは標準では提供しないらしいよ。コアに持っているのはあくまでDIコンテナで
AOPについては既存のものがGBean対応してくれるのを期待してるらしいね
AOPをコアに置いているJBossとは考え方が違うのかな？
- 285 名前：デフォルトの名無しさん mailto:sage [04/12/26 01:32:44]
- >>283
でも、ログが重要なのって、オブジェクトの入り口のメソッドだから、急いで対応するほど問題になってないんじゃない？
- 286 名前：デフォルトの名無しさん mailto:sage [05/01/06 01:32:25]
- proxyタイプのAOPじゃそれが限界だろ。いやならAspectJだ
- 287 名前：デフォルトの名無しさん [05/02/15 01:33:40 ]
- Springしかり、最近のORMしかり、マッピングファイルうざい。
そんなさ、余計にバグ増やしてるようなもんじゃん。
補完も出来ないし面倒なだけだ。
- 288 名前：デフォルトの名無しさん mailto:sage [05/02/15 01:57:26 ]
- まあマッピングファイルがうざいということには賛成だな。
DI Containerは便利だし使ってるけど、たしかにマッピングファイルを書くのがかなりうざい。
ある程度自動化できるとは言ってもなあ。
- 289 名前：デフォルトの名無しさん mailto:sage [05/02/15 02:17:31 ]
- 今のところだいたいXDocletで書いたもので用が足るから、あまり困ってない。
Strutsタグ+α程度で。
- 290 名前：デフォルトの名無しさん [05/02/15 02:38:31 ]
- そもそも、何でもマッピングファイルにすれば保守性、拡張性に
優れるって発想は誰からのものなんだ？
増えすぎると逆効果だぞ・・・
ＪＡＶＡの世界って品質よりも名前だよな。著名な製作者が
提唱すると、何でもスタンダードになっちゃう。
- 291 名前：MARU-CHAN [05/02/15 08:12:56 ]
- ところでSpringとEclipseを使った場合ってMVCはEclipse方式でEJB（セッション管理など）の部分をSpringでやるっていうイメージなのでしょうか？
- 292 名前：MARU-CHAN [05/02/15 08:14:04 ]
- ごめんなさい、２９１はEclipseじゃなくてStrutsの間違い。
- 293 名前：MARU-CHAN [05/02/15 08:25:38 ]
- ２９１は間違いダラケでした・・・書き直すと
ところでSpringとStrutsを使った場合ってMVCはStruts方式でEJB（トランザクション管理など）の部分をSpringでやるっていうイメージなのでしょうか？
です。すんません。
- 294 名前：デフォルトの名無しさん mailto:sage [05/02/15 12:12:02 ]
- >>293
MVCというのがどういうことか正確にわからんが、StrutsのActionとActionFormはそのまま使って、ActionServletをSpringに置き換えることになる。
HTMLフォーム→JavaオブジェクトまではStrutsに任せて、あとはSpringでって感じだな。
- 295 名前：デフォルトの名無しさん mailto:sage [05/02/28 10:26:54 ]
- アマゾヌで Spring In Action 発注したが 3/11 配送予定。
予約じゃなかったから仕方ないところか。
>293
Struts はコントロールとビューだけに専念して
ロジックを POJO で記述して Spring に管理させる感じかと。
Spring 独自の MVC フレームワークもあるらしいけど
そっちってどんな感じなんですかね？
Struts の servlet API べったりな感じが
どーも Spring の POJO マンセー思想に合わない気がする。。
- 296 名前：デフォルトの名無しさん mailto:sage [05/03/06 14:23:38 ]
- POJOなんて、スローガンに過ぎなかった、と。
- 297 名前：デフォルトの名無しさん mailto:sage [05/03/10 12:25:54 ]
- Spring in Action がまだ届かない
- 298 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:07:16 ]
- SpringってWebじゃない普通のアプリケーションでも使えるの？
- 299 名前：デフォルトの名無しさん mailto:sage [05/03/10 23:29:18 ]
- 使おうと思えばつかえるけど、そういうのにはPicoContainerのほうが向いていると思われ。
私はPicoContainerの、何にでも使えるところが気に入ってます。
- 300 名前：デフォルトの名無しさん [05/03/16 19:21:26 ]
- Seaser>>>>>>>>>>>>>>>>>>>>>Spring
- 301 名前：デフォルトの名無しさん mailto:sage [05/03/17 10:43:16 ]
- Seaserなんて存在しないから、ということがいいたいのか。
- 302 名前：デフォルトの名無しさん mailto:age [2005/04/08(金) 15:20:13 ]
- 6月にやるJavaWorldのイベントにロッド・ジョンソンが来るみたい。
www.javaworld.jp/jwday/session/index.html
生ロッド見に行こうかな。
- 303 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 00:26:06 ]
- DIのよさが分からん。。。
インスタンスを設定ファイルで与えられるって事がそんなにいいの？
アンチDIというより「DIってすげんだぜー」って言えるように
実は洗脳して欲しかったりする。
DIが出てきてどんな所が楽チンになったのよ？
- 304 名前：デフォルトの名無しさん [2005/04/09(土) 01:12:55 ]
- コンポーネント指向が強制される所？
インターフェイス経由で操作するのは、前から言われてることだし。
- 305 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 01:20:32 ]
- >>303
EJBを使ってみれば、以下にSpringが楽で、「ああ俺だったらEJBのこのめんどくせえ
ところ、こうするのに！」というところを見事に解決していることがわかるよ。
- 306 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 01:28:17 ]
- 以下＝如何
- 307 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 09:16:59 ]
- 303じゃないけど俺も同じような感じ。
EJBを使わない俺にはメリットのない話ですか？
クラスどうしの依存性が減り、シンプルになり、
ユニットテストがやりやすくなるという利点は分かるのですけど、
その代わりにXMLファイルがごちゃごちゃして手に負えなくなる。
勘違いしてる？
- 308 名前：303 mailto:sage [2005/04/09(土) 09:21:03 ]
- >コンポーネント指向が強制される所？
あるレベル以上のメンバーと組むことが出来る漏れとしては、
そんなもんｲﾗﾈ？
>インターフェイス経由で操作するのは、前から言われてることだし。
インターフェースは好きじゃないっス。デバッグやりにくいっス。
（あくまでDIのためにインターフェース作るのはね。プラグイン開発
とか機能要件として必要な場合はもちろん使う）
>EJBを使ってみれば、以下にSpringが楽で、「ああ俺だったらEJBのこのめんどくせえ
>ところ、こうするのに！」というところを見事に解決していることがわかるよ。
漏れもEJBはめんどくさいって思ってる。なのでHibernateつかってる。
AOPでトランザクションはいい感じだけど、DIのよさはまだわからっス。
- 309 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 09:23:51 ]
- >>307
ハゲドウ!!
- 310 名前：303 mailto:sage [2005/04/09(土) 09:25:00 ]
- 309は漏れです。。。
- 311 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 10:29:11 ]
- >>308
インタフェース経由で作らないと、使い回しがしにくいだろ？
Spring以前の問題。
あるレベル以上のメンバーの中で、308のレベルだけ低いのか、
あるレベルというのが低いのか。
- 312 名前：303 mailto:sage [2005/04/09(土) 11:07:08 ]
- うぬー。使い回ししやすい、しにくいはインターフェースに
かかわらずクラス設計しだいじゃないの？
上にも書いたけどインターフェース自体を否定してるわけじゃないよ。
インターフェースとImplクラスが1つずつしか作らない場合
は面倒だなーって思います。
- 313 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 13:39:51 ]
- そうだな、インターフェースを使ったプログラミングをしようとすると、
ファクトリをつくらなくちゃいけなくなるだろ。だって、newでインスタンス
を作っちゃうと、newしている部分は具象クラスに依存してしまうから。
なんで、ファクトリ用クラスをつくって、ファクトリ経由でオブジェクト生成する。
とここまでは誰でも実装すると思うんだよ。
で、ここでファクトリを書く方法を考えてみようや。クラスごとにファクトリを
別に書くなんて馬鹿げてる。じゃあ、インスタンス生成メソッドの引数でクラス・オブジェクト
かクラス名を引数で取ることにしよう。
じゃあ生成メソッド内で、渡されたClassに対してgetInstanceすることにしようか？
これはできない。渡されるClassは、インターフェースだろうから。
じゃあif文で、渡されたClassなりClass名なりで分岐して、具体的な生成クラスを
特定しようか。これも馬鹿げてる。クラスを追加するたびにファクトリにif文を追加
して、コンパイルし直すのか？ 分かりやすい記述法で外部ファイルに記述したい
ところだ。
そういや、具象クラスを生成するときのコンストラクタに引き渡す引数はどうしよう
か。ファクトリの生成メソッドにObject[]として引き渡してもらおうか？ 生成後に
setXXXX()で全部セットしてもらおうか。どっちにしても、具象クラスのコンストラクタ
なりプロパティに依存してしまうよねえ。
さあ、どう実装しようか。外部ファイルで具象オブジェクトを特定して、具象オブジェクト
生成時に内部状態の初期設定も行うファクトリだ。
そんな話を説明しているのがロッド・ジョンソンの本「J2EEシステムデザイン」。いろんな
アイデアを具体例を使って披露していく。このアイデアを実装して公開したのが
Spring Frameworkだよ。
- 314 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 15:18:41 ]
- >>308
> 漏れもEJBはめんどくさいって思ってる。なのでHibernateつかってる。
> AOPでトランザクションはいい感じだけど、DIのよさはまだわからっス。
EJBめんどくさい→Hibernateつかってる
となるということは、「EJB = EntityBeanのみ」ってことなのか？
DI Containerが作られた契機となった問題点って、Stateless Session Beanを
つかったビジネスロジック層の作り方があまりにもめんどくさい、ってところだっ
たと思うんで、ロジック層をDIパターン以外の方法で効率よく解決できるんなら、
「DIいらね」ってことに出来ると思うけど、Hibernateではそこは解決できんよね。
Hibernateで永続化層はクリアしたとして、ロジック層のオブジェクト生成は
どうするわけ？ newしてるってこと？ EJBは論外として。
- 315 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 16:24:18 ]
- インターフェイスを使う利点が少ない状況ってのはやっぱりある罠。
上にも少し出てたけどプロジェクトメンバーの技量があまりに低い場合には
プログラム中で全てif文で分岐した方が効率がいい場合もあるかもしれない。
インターフェイスの使い方をよくわかってない人はまだ意外といる。（職場によるだろうけど）
「外部ファイルで具象ファイルを指定することにより具象ファイルを変更することが可能」というのも
それによる恩恵を受けられる環境と受けられない環境があるんじゃないだろうか。
自社システムやそれに近いぐらいに自分のところで管理しているシステムで
かつ頻繁な拡張や似たようなもの作る機会が多いなら強力だと思うけど
作って納品して終わりとか拡張がまるでなかったりしたら自分たちにとっての利点はあまりないかも。
>>311が理想だと思うけど状況次第では>>312の言うこともわかる。
俺はSpring好きだしどんどん使っていきたいと思ってるけど使ってもおいしくない状況ってのはやっぱりあるんジャマイカ。
ところでSpring in Action邦訳☆⌒ 凵＼(＼･∀･) まだぁ?
- 316 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 17:02:49 ]
- そう、だから、インターフェースを使う必要がないならファクトリも必要ないんで、
DIパターンの利点がほぼなくなる。
あとは、コンテナが提供するAOP機能が使いたいかどうかだけだろう。
でもインターフェースを使ったことによる利点が出てくるのって、実は開発の
後の方（変更が入った時）なんで、最初のうちに「この開発ではインターフェース
使うほどじゃないだろ」とか判断してしまうと、後半で泣きを見ることもあるから、
先行投資としてインターフェース中心でいくんじゃないかね。
- 317 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 17:11:58 ]
- インターフェイス主体でプログラム作るときの面倒さが減ることがDIのメリットなら、DI自体にはメリットはないみたいになるな。
- 318 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 17:45:35 ]
- >>317
詳しく
- 319 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 18:03:51 ]
- いや、DI「コンテナ」の、インターフェース生成時の実装隠蔽ファクトリとしての利点はなくな
るだろうけど、インスタンス生成時に依存性を注入して、すべてのプロパティが構成済みの
オブジェクトを作成するというDIパターン自体のメリットは残るだろう。
インターフェース主体でないからって、DIパターンなしだったら、
インスタンス生成→他の依存インスタンス生成（このインスタンスにも依存インスタンスがある）
→インスタンスのプロパティに依存インスタンスをセット
ってのを自前でやらないといけない。newして、関連オブジェクトをnewしまくって、関連
オブジェクトの全プロパティをセットして、で、最初にnewしたオブジェクトに関連オブジェクトを
セットしないといけない。
そんなめんどくさいこと、ファクトリでやってよ、と思わないか？
- 320 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 18:28:24 ]
- ファクトリでやるのはめんどくさいから、それぞれのオブジェクトでやってよ、と思ってはだめですか？
- 321 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 19:33:43 ]
- >>319
先日迷ったあげくSpring無しで書いたんだけどいちいちnewしてセットは確かに面倒だった。
これを面倒だと思うのはある程度Springに慣れてるからだと思うけど
それ以上に苦痛だったのは後で変更が発生したときの修正が面倒そうだと思いながら書いてたからだな。
でも>>319の一番のメリットは
具象クラスが変わることで具象クラスが必要とするオブジェクトが変わってもファクトリを修正せずに対応できること
（つまりは具象クラスの差し替えのしやすさ）
じゃないのかな。
それも具象クラス差し替え時に生きてくるメリットな気がする。
俺はSpringやDIコンテナ、もちろんインターフェース多用するのも否定するつもりはないんだけど
仕事場の環境次第ではSpringわからない人もまだ多いし
>>318の言うような先行投資の効果が目に見えて出ない時も多々ある。
それを考えると設定ファイル書いたり周知したりで面倒さが前面に出てくる人がいるのもわかるな、と。
後々俺が作った物を他の人が管理することになった時にその人はSpringを知っていてくれるだろうか、
俺がこれまでにしたつもりの先行投資は最終的にプラスになるのだろうか、
とちょっと悩んで書いたのが>>315なんだ。
チラシの裏って書いた方が良かったかもな。すまん（´・ω・｀）
- 322 名前：303 mailto:sage [2005/04/09(土) 20:29:45 ]
- >>314
>ロジック層のオブジェクト生成はどうするわけ？ newしてるってこと？
うん、newしてる。
>>315
そうだね、頻繁な拡張とかはないです。
>>316
>でもインターフェースを使ったことによる利点が出てくるのって、実は開発の
>後の方（変更が入った時）
うーん、開発後方でImplクラスを丸ごと挿げ替えるほどの変更は
ないなー。Implクラスの実装を修正するだけじゃすまないって事デツか？
あー、>>319 見て分かった。ビジネスロジック層の作り方がそもそも違うんだ。
漏れは、依存オブジェクトをプロパティ経由でセットしないデツ。なので、
ビジネスロジック層のオブジェクトの殆どが状態を持たないです。
ただね、このOOPらしくない所が良いのか悪いのかは漏れも迷ってる。
- 323 名前：デフォルトの名無しさん [2005/04/09(土) 21:16:39 ]
- ＯＯに反するコード＝劣悪なコード
- 324 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 21:37:54 ]
- ステキなOOの概念がこの2年で大きく変わっている現実
- 325 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 22:15:37 ]
- > うーん、開発後方でImplクラスを丸ごと挿げ替えるほどの変更は
>ないなー。Implクラスの実装を修正するだけじゃすまないって事デツか？
ただのロジック変更ならソースの修正で済むけど、対象によってロジック分岐とかだと
if instanceof else if〜 で分岐するのは全くエレガントじゃないから
Strategyパターンにしたほうが後々いいでしょ、って事だな。
拡張性とか関係ない部分ならいいかもしんないけど。
- 326 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 00:22:16 ]
- うーん、最近の流れは勉強になるなぁ。
いつまでも独学は不安なので、自分の独学部分が正しいか
検証することも踏まえて、なんか本を買おうと思うのですが、
・これは読め
・これは糞だから読んじゃだめ
などありましたら、ご紹介いただけますか?
- 327 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 00:27:43 ]
- >>322
＞ないなー。Implクラスの実装を修正するだけじゃすまないって事デツか？
機能追加の場合には新しい機能向けのクラス作って
条件によってどちらを使うか切り替えればわかりやすいと思う。
また、別のユーザー向けに似たようなシステム作る時には
クラスごと差し替えることができればとても楽。
＞漏れは、依存オブジェクトをプロパティ経由でセットしないデツ
引数で渡してるの？
インターフェース使わないならそれでも困らないと思うけど
インターフェースで実装の切り替えをするような場合には引
数がビジネスロジッククラスの実装に依存すると困るのよ。
ある実装ではこのオブジェクト使うけどこの実装では使わないとなると引数が統一できないから。
その点>>319のように依存オブジェクトを初期化時に設定ファイルで指定して
プロパティやコンストラクタでセットするようにすれば
呼び出し側からは実装の違いを全く意識する必要がないことになる。
- 328 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 01:11:57 ]
- Springを使って3ヶ月程度のプロジェクトをやってみた。
俺はPMの立場で実装はやらないが、コードレビューする程度。
結論は、SpringにするかはともかくIoCコンテナなしの開発は、もう考えられない。
最初にかならず行っていた低レイヤー部分のフレームワーク作りをしなくて済むのだから。
いつもなら、実装がぶれるのが嫌で、最初のうちに低レイヤーのフレームワークを作ってから
プログラマに渡していた。
最初にこう書くべきだというサンプルを見せてやれば、
newbieでもそこそこのものを書き上げてくれる。
Springのソースを読んでて、interfaceは多重継承できることを初めて知った。
Javaには自信を持ってたのに、自分に少しがっかりした。
- 329 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 02:32:31 ]
- >>326
>>313にも出てるけど、ロッド・ジョンソンの「J2EEシステムデザイン」はお勧めできる。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4797322888/250-2144330-3153039
DI(あるいはIoC)コンテナ登場前夜に、EJBの問題点を詳細に書き表して、なおかつ
解決するための方法論を具体的なコードを交えて説明した名作だ。この本で紹介された
アイデアがそのまんまSpring Frameworkの基礎になってる事は有名。AOPの実現方法ま
でおんなじだし、Springの解説書か？と思えるほど。
まあロッド・ジョンソンがSpringの開発者なわけであたりまえなんだろうけど。
一方読む必要がないのは、「Java ブループリント」だな。人生を無駄遣いする事になる。
- 330 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 02:53:18 ]
- >>328
そう、それだ。
エンタープライズ向け開発だと、いろんな技術レベルの人間があつまるから、かならず
基礎アーキテクチャを技術レベルが高い人間で実装するよな。
つまり技術レベルの低い人でも、決められた実装方法に従って普通のJavaプログラムと
して作れば、あとは基礎アーキテクチャが何とかするよ、という状態を作るわけだ。
そういうものの大部分って、ロジック層のシングルトン・オブジェクトをどうやって生成するか
とか、初期化を間違わないにはどうしたらいいかとか、EJBを取得するのにJNDI参照したり
RemoteExceptionを処理し忘れたりしないようにするにはどうしたらいいか、とか、
めんどくさいことばっかりなんだよな。
Springはそういうものの大部分を吸収してくれるし、EJBの利点の一つ、宣言的トランザクション
もサポートしてる。
正直、リモート呼び出しの必要性が無ければEJBを使う意味を見いだせない。
- 331 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 03:25:34 ]
- 思うに、Spring自体が、EJBのめんどくさいところを解消する過程で産みだされたところを
ふまえとかないと、なんで「Spring楽だー」という輩がいるのか理解できなくて、>>307のような
感想になっても仕方がないと思う。
>>307
>その代わりにXMLファイルがごちゃごちゃして手に負えなくなる。
EJBのディプロイメント・ディスクリプタというXMLファイルは、SpringのXML定義の１０倍は
ごちゃごちゃしてて手に負えないんですよ。Springの構成ファイルは分かりやすいよ。
しかも構成ファイル一つでリモート呼び出しを除くEJBの機能を実現できるんだったら、
EJBに苦しめられた輩が採用しない理由はないよ。
- 332 名前：デフォルトの名無しさん [2005/04/10(日) 03:39:21 ]
- ふむ、ageとこう。
- 333 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 03:46:18 ]
- ＿
r-､' ´ ｀ヽr-､
ｨ7 /l: ハヽﾊ ﾄヾ 駄スレを保守することは、この俺が許さん！
'|l |'´_` ´_ ｀| || 信念に基づいて行動する。
| |´ﾋ} ﾋ}｀! l| それを人は正義と言う。
__ノﾞ). 从 l, _'_. |从 今俺が行ってることは、荒らしではない。
,_'（＿ ﾉ_ヽ ヾl.＞ - ,イ;ﾘ 正義という名の粛清だぁ！
{ f:ﾃ} {'f:ﾃ}',／＼ヽ--/／ヽ
ヽ,r─‐ ､ｨ .､､ i l＞Y＜! i '､ バーニング！
/ iゝ＿ﾉ iヽ /l |l l ',
lﾝヽ/ムノじ
- 334 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 08:58:20 ]
- >>328
Webじゃない普通のアプリについてはどう思ってるか教えて欲しい
- 335 名前：328 mailto:sage [2005/04/10(日) 10:12:52 ]
- >>334
今回は、通常のアプリとWebアプリとどちらでもSpringを使った。
Webアプリのほうが制約があり、通常のアプリのほうがより自由というのが回答。
Springの構成は、まず通常のJavaアプリで使えるコアがある。
optionalな形でSpring WebなどのWebアプリ用サポートがある。
Springは、BeanFactoryという汎用のファクトリに識別子を渡して生成してもらうのだが、
このファクトリのインスタンスをどこかに保存しておく必要がある。
保存しない場合は、ファクトリのインスタンスを毎回newする必要が出てくる。
これは毎回設定を解釈するというコストをかけることとイコールだ。
で、通常のアプリならメインクラスのメンバにでも入れておけばよい。
これがWebアプリだと、applicationスコープのアトリビュートに放り込むことになる。
BeanFactoryのアトリビュートへの設定と取り出しを管理するクラス自体は、Spring組み込みで提供されてる。
しかしServletContextを使える場所でしかBeanFactoryを取得できないという制約が生まれる。
ちゃんとクラス設計していれば問題は生じないけど、
ちょっと工夫してあげなきゃならない場面もでてくる。
まああれだ。たぶん大丈夫だよ。
心配なら一度ファクトリ部分のソースを追って、中身を確認したらどうだろう。
変な制約はないし、シンプルで、不安は生まれないと思う。
- 336 名前：334 mailto:sage [2005/04/10(日) 13:11:02 ]
- >>335
さんきゅ
- 337 名前：デフォルトの名無しさん mailto:sage [2005/04/11(月) 02:58:25 ]
- Spring In Actionよりも、ロッド・ジョンソンの「Expert One-on-One J2EE Development without EJB」
を邦訳してほしいな。「J2EEシステムデザイン」の続編みたいな本だ。
|
 |
