国産オープンソースDIコンテナSeasar V2(S2)
またJavaのゴミフレームワークかよ。
いい加減スレ一本化しろよ。
下火言語が調子に乗るなよ。
うほぅ！これ激しくイイ！
他のフレームワークに対する利点と欠点をまとめてくれ。
利点 - 国産
欠点 - 資料なし
終了。
資料無しはダメダメだね
/// 糞スレ終了
資料って？マニュアル？チュートリアル？
フレームワークというよりはお手軽なライブラリじゃねえの？
・クラス間の依存性を減らす（DI）
・ORM難民でも使える便利なS2DAO
・各種フレームワークとの連携（S2Struts,S2Tapestry,S2Hibernate,S2OpenAMF)
10get
11 ：
デフォルトの名無しさん：04/08/09 23:53
とりあえず使ってみた上での批判レスがあんまり無いね。
ageるなヴォケ
javaみたいな糞がいくつもスレたてんな
>>11 使ってるやつがいないんじゃないの(ﾌﾟｹﾞﾗ
>12 こんな僻地の板で堅いこというな、言語でどうこうホザくのはなんかヴォケ通り越して哀れだぞ。
>>14 煽る暇あったらネタ振ったら。
ないなら終了だな。
時代はLL
Javaは糞
よって終了
普通本スレであまりにその話題が多すぎて
スレから追い出される形で専用スレ立てるのが常識なのにな。
本スレってどこよ？
>>1立て逃げせずにちゃんとネタ振れよ
＞＞１７
２ｃｈの常識（藁
>>16 LLのイベントには Groovy と Pnuts のプレゼンがあったわけだが。
>14 おまいのレスからほとばしる知性と知見でまともに一行書いてやってくれ、Groovyも対応してるしな。
時代はヘブライ語でもPythonでもRubyでも何でも良いわ、外でLLとか略すと恥書くぞ。
>15 ネタって？マニュアル見たら、この板に徘徊してんなら技術的見地から突っ込めるだろ？笑いが欲しけりゃ他あたって下さい、すまんな。
今日も暑いな
ああまったくだ
漏れはS2使ってる
このスレに書き込んでる輩は、
みんあひがさんに合ったことあるに違いない。
俺はないが何か？
2次ドキュメントがないのかと思ったら、1次ドキュメントがまったくないのな。
JavaDocすらついてないし。
DIファイルに何が書けるかももちろんどこにも載ってない。
S2Hibernateのドキュメントが特徴的なんだけど、コメントもないソース列挙しておいて
「簡単に利用できるということが分かっていただけたと思います。」
と書いてしまう感覚の持ち主。
ダウンロードファイルがjarになっているのは、jarも解凍できないやつは使うな、というメッセージなんだろう。
お友達に便利に使ってもらえればいい、っていう、とってもローカルなライブラリだね。
ひがさんのお友達以外には、使う価値はありません。
パッケージソフトみたいなものを作るとき、S2を使えばソースを直接いじらなくても、
カストマイズできるようになる。カストマイズ→出荷、を何回も繰り返せれば、
S2投入のオーバーヘッドは回収できる。
もちろん再利用を前提とした作りにしなければならないけど、実はこれが難しい。
反対に受託とかで、毎回違うものを開発しているところはS2のメリット無いでしょ。
単に作って納品するだけなら、S2を使わない方が速い。教育のコストもあるしね。
再利用を考えないなら、１つのプログラムを、あんな風にいくつものファイルに分割して
散在させるのは無駄というもの。
S2の作者さんが働いているような大手SIerなら利用価値はあるけど、それ以外はどうかな？
>>29 > ダウンロードファイルがjarになっているのは、jarも解凍できないやつは使うな、というメッセージなんだろう。
Java使ってるならjarの解凍は普通出来ると思うんだが
>>30 S2に限らず、POJOを利用するDIパターンなら兵隊の教育は不要なんだが……。
>>30 > 再利用を考えないなら、１つのプログラムを、あんな風にいくつものファイルに分割して
> 散在させるのは無駄というもの。
お前、Java使った仕事してないだろ？ プログラムとかファイルとかいう単位ってなんだよ（ｗ
何かドキュメント粘着多いようだが
漏れは落としてきて普通に使えたぞ
ちょっと触ればすぐわかるだろこれくらい
>>32 > S2に限らず、POJOを利用するDIパターンなら兵隊の教育は不要なんだが……。
S2をどこまで使うかにもよるけど、裏側で何をされているかは理解させないと
まずくない？つーか、それがわからなければS2を使う価値ないよ。
>>34 > 漏れは落としてきて普通に使えたぞ
それは、強いて言えば
「簡単なサンプルプログラムが動いた」
「実戦投入して客に納めた」
のどちらかな？そこが問題だ。
釣られすぎですよ
JSP使ってるのにServletの仕組みを理解してないヤシがいるほうがまずいくらいだがな
フレームワーク使うってそういうもんだ。全員がフレームワークの裏側まで知らないといけない
というようでは意味がないだろう
漏れはS2で作って納品しましたが何か？
一人有限なので今年はこれで十分かと思ってますが何か？
>>29 > DIファイルに何が書けるかももちろんどこにも載ってない。
components.dtd見れ
>>29 > ひがさんのお友達以外には、使う価値はありません。
なんだひがさんに嫌われてるやつの粘着か。つまらん。
>>39 > 一人有限なので今年はこれで十分かと思ってますが何か？
そーだよな。自分ひとりでやるなら、自分だけわかってりゃいいからな。
そうだな。頭悪い奴とこれ以上一緒に仕事できねーって思って
独立したから一人で出来る程度しかやらないよ。
ちゃんと保守契約も結んでるから問題ナッシング。
さくっと納品できたので金額を考えるとおいしい仕事だったよ。
S2はありがたいよ。
そんなつまらんことでスレ立てたのか。
まったくスタンドプレーの好きな迷惑な奴だな。
>>43 > そーだよな。自分ひとりでやるなら、自分だけわかってりゃいいからな。
漏れのとこは、無理だな。
旗振ってもついてこねーだろうし、上司もいい顔しねーよな。
なんだ、単なる宣伝スレか。
ならもっと宣伝してよ。
>>49 よかったよね。サポートを欲しがる客でも
安心して提案できるようになるね。
これでもっとS2を使っていきやすくなるよ
SRAを忘れるなよ＞日本発のオープンソースビジネスかな？
>>51 > SRAを忘れるなよ＞日本発のオープンソースビジネスかな？
作者が日本人ということでは、多分初めてじゃないかな。
Rubyはどうなんだろ。
>>49 > S2の作者の会社(電通国際情報サービス)で、有償サポートの検討開始だってさ。
そのうち「S2認定技術者試験」みたいなもんもはじめたりして。
上のほうで絡んでるヤシは正にそういうのが欲しいんじゃないの＞認定
何かオプソ使うの好きなタイプじゃなさそうだし認定なら当然ドキュメントとか出てくるだろうし
>>30 > 反対に受託とかで、毎回違うものを開発しているところはS2のメリット無いでしょ。
> 単に作って納品するだけなら、S2を使わない方が速い。教育のコストもあるしね。
お前は仕様が完全に固まってから作れるのか。うらやましいぞ。
仕様変更のときにこそDIは便利なんだがな。お前触ってないだろ。
別にS2でなくてもいいからDI触ってみろ。Picoとかわかりやすいぞ。
>>53 > そのうち「S2認定技術者試験」みたいなもんもはじめたりして。
で、その前に認定試験対策研修が開催されると。
恐ろしく具体的な話の出ないスレだな
使ってない人間ばかりだからだろう。使ってる人間は来てないようだな。
>>41 サイトのトップページで「優しさや易しさを重視」って書いてなければ問題ないんだが。
と思ったら、「優しさや易しさを重視」の記述なくなってるね。
じゃあ、問題ないよ。
それより、Springがある状況で、Seasarにどういう価値があるのかよくわからないんだけど。
ソースのインスタンス変数名の"_"がイヤ。
あとは完結でいい
>>59 > それより、Springがある状況で、Seasarにどういう価値があるのかよくわからないんだけど。
WebSphereやWebLogicがある状況で、JBossにどういう価値があるのかわからん、といってるのと同じだよ。
それはさておき、DIという一種のパターンに対して、実装の形はいろいろあるってことだな。
SpringはBeanにこだわりすぎて結果として色んなものがどんどん密結合していっていると漏れは感じる。
S2はバラバラであることとつなぎやすさを優先している。理念と現場の違いじゃないかな。
両方触れば実感できることだ。トップページごときをとやかく言う前にどっちもダウンロードして触ってみろ。
ここはプログラム板のはずだ。Spring以外にもHiveMindやPicoContainerとか触ってみてくれ。
個性の違いを感じられると思う。DIの面白さを実感してみてくれ。
JBossはフリーだし、AOPも楽しそうだし。
なんか、Springでできることをやりなおしてる感じだと思ったんだが。
できることの違いじゃなくて、やりかたの違いなのか。
それにしても、ここまでドキュメントがないと、実際に使うのは怖いな。
仕様がないので、いつ使い方が変わってもおかしくない印象。
ソースとか見ればメソッドはわかるけど、それってメンテナンスで変更されたりしないの？みたいな。
>>62 ほとんどの機能はドキュメントで説明されているはず。
記述が足りないところはあると思うけど。
なんで、ドキュメントがないといいきっているのか分からん。
>>62 > 仕様がないので、いつ使い方が変わってもおかしくない印象。
そうだね。
J2EEみたいにSpecificationがあって、それに沿った実装が開発されているわけじゃないしね。
そういうリスクを取ってでも取り組む価値があるかどうかは、人によりけり。
>>62 > JBossはフリーだし、AOPも楽しそうだし。
S2もフリーだし、S2のAOPは楽しいですよ。
> なんか、Springでできることをやりなおしてる感じだと思ったんだが。
> できることの違いじゃなくて、やりかたの違いなのか。
それをいったら、Geronimoとかどうするんですか（ｗ
> それにしても、ここまでドキュメントがないと、実際に使うのは怖いな。
> 仕様がないので、いつ使い方が変わってもおかしくない印象。
> ソースとか見ればメソッドはわかるけど、それってメンテナンスで変更されたりしないの？みたいな。
ドキュメントのあるなしとメソッド変更のはなしは別でしょ。
Java自体だってそういうことはあるわけだし。
S2に限らず、DIって今のJ2EEでの開発に困ってないなら別にいらないよ。
今の状況に困っているなら、解決策のひとつとして検討する価値はあると思う。
>>64 > J2EEみたいにSpecificationがあって、それに沿った実装が開発されているわけじゃないしね。
> そういうリスクを取ってでも取り組む価値があるかどうかは、人によりけり。
そうだね。別にS2だけじゃなくて独自規格って多いしね。
共通規格がないものは使わないっていうのも大切だと思うよ。
S2はSpring同様にAOPアライアンスに準拠しているっていうけど
AOPアライアンス自体が公的な機関じゃないしね。
>>63 >
>>62 > ほとんどの機能はドキュメントで説明されているはず。
> 記述が足りないところはあると思うけど。
> なんで、ドキュメントがないといいきっているのか分からん。
そうだね。そもそもS2って機能が少ないから、あれで一通りの説明にはなっている。
言葉足らずのところはあるかもしれないが、サンプルのコードとあわせて読めば
実際に使うのに必要なことはわかるよ。
>>62が気にしているのは、どんな風に使えばいいのかってことなのかもしれないね。
でもそれってSQLのマニュアルを読んで「プログラマのためのSQL」みたいな書籍に
書いてるようなことが書いてないじゃないかっていってるようで、ちょっと違うんじゃないかと俺は思う。
>>67 > 共通規格がないものは使わないっていうのも大切だと思うよ。
そこでC#でつよ！ dotNETマンセー！！
>>68 >
>>62が気にしているのは、どんな風に使えばいいのかってことなのかもしれないね。
> でもそれってSQLのマニュアルを読んで「プログラマのためのSQL」みたいな書籍に
> 書いてるようなことが書いてないじゃないかっていってるようで、ちょっと違うんじゃないかと俺は思う。
うん。そう思う。現状S2のドキュメントって「何ができるか」が中心で、「どう使えばいいか」みたいな
ところまでは行ってない。だから使い手の力量が問われる。もっともその辺は有志(?)も気が付いて
いるはずで、サンプルプログラムの開発が進んでいる。単に使い方を知りたいという人は、それが
出てきてからでも良いんじゃないかな。始めるのは。
>>62 > それにしても、ここまでドキュメントがないと、実際に使うのは怖いな。
少しでも実際に触ってみた？ 何か全然S2を触ってないように見えるんだけど。
>>68 逆で、「プログラマのためのSQL」みたいなHOW-TOは書いてあるけど、「SQLのマニュアル」がない。
えーとね、ソースをざっとみたところ、
フレームワークはほとんどinterfaceと実装クラスの組からできているので、
仕様の大幅な変更は少ないと予想できる。
実装の変更はあるだろうが。
で、S2のコア部分はシンプルなことしかしていない。
色んなクラスへのアクセス方法とライフサイクル管理、Weaving、これらを提供するのみ。
便利なコンポーネントは作ったのだが。
じゃあどうやってそのコンポーネントにアクセスするの？
ファクトリクラス？するとファクトリの作り方がコンポーネントごとにばらばらになっちゃうね。
JNDI経由？するとレジストリにコンポーネントを登録するのは何が担当するのかな。
コンポーネントの処理を変えてみたいんだけど、ソース改変はバグの元だね。ソースなかったりするし。
というのを、ぜんぶS2が面倒見ますよん、というわけ。
コンポーネントを取得したあとは、それぞれの作法に従ってクライアントコードを実装するだけ。
ま、Seasarはドキュメントを軽んじてるから、このままじゃ大きく普及するのは難しいだろう、と。
大きく普及することに意味があるかどうかは別として。
もまいは使わんでよろしい
何か妙にドキュメントのことばかり話題になっているが
マニュアルの不備を指摘してる人は
S2の技術的なことについてはどう思ってるの？
ドキュメントがちゃんとしてないと使えないくらいS2は複雑だっていいたいのかな？
それともドキュメントさえ整備されればS2がもっと普及するのに勿体無いっていいたいのかな？
>>77 後者。
せめてJavaDocとDICONファイルに何がかけるかのリファレンスは欲しい。
見てみたらソースにコメント全然ないね。。。
Aspect関連のクラスにちょっとだけ日本語コメントがある
コメントも含めて何でそんなにドキュメント話ばかりなんだ？
他にもっとネタはないのかよ
>>81 > コメントも含めて何でそんなにドキュメント話ばかりなんだ？
普通の人にとってドキュメントは使い物になるかどうか判断する大切な材料の一つだから。
「今あるドキュメントで十分だろ」という人は、そういうことに気が付かない。
もっともそういうことを気にする立場ではないから、そう思って当然なんだけどね。
今はまだ「分かってる人が使える」存在のもの。
EarlyAdopterがそれこそS2に限らずPicoContainerとか色々試してる段階。
俺みたいに、仕事で使うには標準であることのメリットが甚大だという理由でEJB3.0を待っている人間もいる。
ドキュメント整備は、それこそ普及戦略の上での問題だな。
もちろんもっとあったほうがいいというのには同意。
ドキュメントがあろうがなかろうが、いわゆる「厨」は一定比率は発生してしまうがな。
実務優先でやってるから、ドキュメントより実装が先ってのは分かる。
ちょっと前の大きな仕様変更で痛い目見たんだが、ドキュメントが沢山
あるとああいう場合に大変だよね。
だからドキュメントが必要最低限なのかなーと思ったりする。
便利なのは間違いないんだけど、現状じゃあんまり他人に勧められん。
コアの部分が大きく変わることはもう無いんじゃないかと思うけど、
あったら辛いしなあ。
ミドルウェアを標準先決めで作ると、CORBAみたいな恐竜が出来上がることがしばしば・・・
そういう意味では仕様文書を整えるよりも実装＋HowToを先出しするという方針もありだとは思うけど、確かに現状で手を出すのはちょっと怖いような。
>>84 一応、ひがさん本人は、もうコアの部分に大きく手を入れることはない、と言ってるしね。
チュートリアルで、とりあえず使うことはできるんだけど、リファレンスがないから
「できないことがわからない」
機能を網羅したリファレンスがあれば、設定項目に用意されてないのが確認できれば、できないというのがわかる。
もちろん、設定を組み合わせて実現するようなものは簡単に「できない」というのはわからないんだけど。
よくもまあこんなに無内容な長文をダラダラと書き続けられるもんだな
>>83 今のEJBも標準だけど、使えないわけだが。
EJB3が使えるようになるのはまだまだ先。
使えるものになるかも分からないしね。
重要なのは今何を使うかじゃないの。
>>90 × s2-framework-2.0.14.jar
○ s2-framework-2.0.15.jar
だろ。
縮小再生産を作っておいて「Springには負けない」とか言われてもね。
まあその発言が勇み足だったとして、そもそも真似してる先人を全く
リスペクトする気が無いみたいで、Springのここがだめだとか、作者を
からかうような書き込みとかばかりだし。そういう文化、体質が本当に嫌だ。
組織として責任を持つプロダクトならばともかく、オープンソースな
ソフトウェアは、そういったコミュニティに対する印象も使うかどう
かに大きく影響してくると思うんだが、そういう自覚は全く無いみたいだな。
もちろん全員とは言わないが。
93 ：
デフォルトの名無しさん：04/08/16 02:52
コミュニティーの印象がどうであれ、良いプロダクトであれば、使うと思うけど。
あと、先人じゃなくて、ほぼ同じ誕生日だし。
S2で言っているType4を、後から取り入れたのは、Springだし。
その辺は、どっちも、どっちじゃないか？
まず、プロダクトの事実をちゃんと見たら？
>>92 要するにS2のコミュニティに粘着したいだけだろオマエ
実際にどれだけ触ってるんだ？ オマエの好きなSpringについても
S2の作者より触ってないんじゃねえの？
Springを引き合いに出すなら、具体的な比較とか書いてくれよ
長文の癖に技術的な話が全然ないしうざすぎるよ
そんなに粘着したいならマ板に逝け
しかし絡んでる奴すごいな。いつもドキュメントかコミュニティのことばかり。
他に何にもないのが気持ち悪い。しまいにはストーカーになるんじゃないか。
>>97 実装の大変さを分かってる人は無言実行タイプが多いからここには書き込まない。
ひょっとして熱烈なSpringファンが絡んでるのかと
思ったがあまりの内容のなさにそれじゃSpringが
可哀想だと思った
100ｹﾞﾄ
>>97 モノはいいんだから、ドキュメントどうにかしろ、っていってるんだよ。
>>101 > モノはいいんだから、ドキュメントどうにかしろ、っていってるんだよ。
どのへんがいいのさ？
国産でオープンソースなところ
質素で日本的なところ。
質素というのは言い得て妙かもしれない。
良い意味でDIコンテナ部が全てだしな。
コンテナ部のドキュメント書き直されてるじゃん。
2chの無責任な書き込みにもちゃんと反応するのにビックリした。
いい人じゃないか作者さん。S2応援したくなってきたよ。今晩触ってみる。
ドキュメントドキュメントっていうけど
PowerPointの奴わかりやすかったけどなあ
>108
（´д｀）?
>>106 かなりまじめに見てるらしい。
それを知ってるので、厳しいことかいてますよ > ひがっち
ひがっちっていうんだ
最近責任のある立場ではっきりものをいえないへたれ日本人が増えてるよな。
２ｃｈが流行るわけだよ。
と無責任に意見をのべる114
で、藻前らぼちぼち技術的な話題はできないのか？
S2のコンテナ部分の特徴の一つにOGNLを使っていて、
SpringのPropertyEditorに相当する部分が不要な点が
あげられると思うんだけど、そのへんどうよ。
<arg>new java.math.BigDecimal(1)</arg>
みたいな。
>>119 > <arg>new java.math.BigDecimal(1)</arg>
どの位使う機会があるかわからないけど、便利なのは確か。
こっちの方が自然でわかりやすい。
>>119 Springのref,valueタグの役割をOGNLがやってるんだね。
EJBが難しくてよくわかんなかった俺でもS2はなんとか使い方がわかった。
くーすってやり方で設計してみたが、なんとか筋の通った設計書（らしきもの）ができた。
さて、あとはこのまま S2 で実装に落とせるかどうか。
自分が書いたシーケンス図を見ると、インターフェースやクラスにのっける機能が
明示されてるようにみえるけど、信じていいのかこれ。
書いた本人が信じないで誰が信じるんだよw
でも考えてみりゃソフトウェアって書いた人間が一番信じてないことがよくあるな。
>>122 よく読むと不思議な文章だな（ｗ
よくわからないけど設計が出来てしまうのか
設計って考えながらやるもんだと思うんだが
実装始めたけど初手から躓いた。ドキュメントとサンプルを睨みつつ七転八倒。
結局ＤＩを理解してなかったことに２日かかって気づく。頭わるすぎ orz
なんというか、歴史あるクラス先輩に対して「そんな依存性は修正してやる」と殴りかかってる感じ。
で、さぁやってやるぞとS2Dao組み込んだら、Tomcat 起動中に s2containor の Servlet#init() で例外。
原因分からず。先が長そうでちょっと泣けた。
ガノタかよ（ｗ
Servlet#init() での例外、原因判明。
S2DaoのBEANアノテーションが内部クラス扱いになって別の.classファイルが作られてた。
で、それを JBuilder が war に入れないでやんの。関連チェック、デフォだと外れてるのか orz
そんなこんなで、やっと JBuilderX で S2 + S2Struts + S2Dao が動いた。
これ幸せかも。なんだかソースがとってもキレイ。
もう少し作りこんでからまた。
130 ：
デフォルトの名無しさん：04/09/10 00:02
S2Tapestryの情報って無いですね。
ドキュメントもしっかりしてないので苦労してます。
ソース嫁っていうポリシーだから。
132 ：
デフォルトの名無しさん：04/09/10 08:39
>>131 マンドクセー
そんな時間掛ける気ねーよ。
はやくS2JSFでねーかなー。
そっちならソース読んででも習得したいな。
どういうことで苦労しているのかを書けばいいんじゃないの？
使い方を調べるのに苦労します・・・とか？
135 ：
デフォルトの名無しさん：04/09/10 14:24:29
>>133 つーかさあ、JavaDocで作成したドキュメントぐらいはねーのかよ！
137 ：
デフォルトの名無しさん：04/09/10 18:15:38
S2タペのサンプルなんて足し算するだけじゃねーか！
もっと実用的なサンプルねーのか？
TapestryとS2Tapestryのアプリケーション作成時の違いってこれだけ？
あとはTapestryのドキュメント読んで作ればいいのかな？
・S2ContainerServletの設定 (web.xml)
・エンジンをS2用に変更 (*.application)
・ページ仕様にサービスの定義追加 (*.page)
・ページクラスにコンポーネントのプロパティを追加して
サービスメソッドを呼び出す (*,java)
依存性注入、っていうのがやっぱり今ひとつピンとこないんだが、
要は「論理設計（インターフェース設計）先行で開発せよ」ってこと？
くーすでやってると、まずインターフェースを書かないとなにも出来ないんで、
「とりあえず動くものを書け。話はそれからだ」っていうのを禁止してる感じがする。
140 ：
デフォルトの名無しさん：04/09/10 22:21:02
さんぷるがほしいな。
S2Tapestry ＋ S2Dao
で、フレーム、セッションオブジェクトをバリバリ使ってるやつがいいな。
>>139 >別にDIでなくてもこういう考え方はありだと思う
それはそうなんだけど。「依存性を注入する」って、注入先を先に用意しないと成り立たない。
その注入先がインターフェース。この場合のインターフェースの役割って、業務システムのフレームワークでしょ？
それってつまり、DI で業務システムを組むってことは、詳細設計なき実装を不可能にする手法なのかな、と思ったわけ。
・・・作った後から仕様書書いたら切腹？
>>141 詳細設計なき実装が不可能？
おかしくないか？ 手続きのみの言語じゃあるまいし、設計書が無くても
コード書く前に普通、クラス構造は頭に思い浮かべるだしょ。
>>141 すまん漏れには何を言ってるのかよくわからん
DI関係なく藻前がどんな風に普段作ってるのか
教えてくださらんか？
>>140 フレームやセッションオブジェクトをバリバリ使うとS2は関係ないと思われ
>>144 TapestryでのFRAMESETの扱いや（S2とは関係ないけど）、
認証関係でセッションオブジェクト使って、
AOPで認証チェックやってるS2Tapestryのサンプルが見たいです。
ところでS2TapestryにすることでS2Daoの扱いが変わる（使いやすくなる）の？
>>143 Webは Struts で簡単な情報参照系しかやったことないので、
Windowsで作った受注出荷管理のときを例に。
１）システム機能仕様書、ERD、画面仕様書（レイアウトと処理内容、IO先）を同時並行に書く。
２）DB設計。
３）コーディング。複雑なロジックはコメントでクドクドと説明。
DBはデータ保障をトリガにおまかせ、SQLで気ままにアクセス。
基本的に１画面1クラスで機能を詰め込む。同系画面で継承は使うけど。
こんな感じ。
>>146 では次は 「DI は詳細設計なき実装が不可能」 と思った理由の説明を頼む。
ところで 1 画面 1 クラスってのは、どういう構造よ。
Action にビジネスロジック書いてるの？
それとも色々な Action クラスからある 1 画面の機能を詰め込んだサービスを
呼出してんの？
前者は推奨されてないし（10画面くらいのシステムなら別にいいとおも）、
後者はモデルの切り分けがおかしい。
で、同系画面では継承してる？
構造が分からないけど、サービスで切り出すのが綺麗だとおも。
継承では再利用性、メンテナンス性も低い。
簡単な情報参照系なら、Struts使う必要もないな。
149 ：
デフォルトの名無しさん：04/09/11 13:02:27
作者、これまた大きくでたな。
ttp://d.hatena.ne.jp/higayasuo/20040911 ------------------------------------------------------
まずは、Nirvanaと組んだS2JSF。JSFは、リリースされたから結構経つのに、いっこうに
使われる気配がありません。これは、ツールベンダーの思わくが先行し、現場を見てない
結果だと思われます。
しかし、それも変わってきます。HTMLをテンプレートにし、DIコンテナと組みあわせる。
これなら、現場での使用にも十分に耐えられるでしょう。
くさったJSPなんかさよならです。重厚なEJBなんてさよならです。長いこと開発者を苦しめて
きた2つの技術。JSPとEJBに終止符を打ちます。
次は、S2Flex。時期的にはこっちの方が早く出ます。リッチクライアントも、試行錯誤の時期を
終え、いよいよ普及期に入ります。
2004年。これほど開発手法が激変する年は恐らくもうないのではないでしょうか。
開発手法の激変といっても、Javaローカルな話だね。
処理系依存。
まずは、DI を組み込んだ SeasarV2。 S2は、リリースされたから結構経つのに、いっこうに
使われる気配がありません。これは、作者の思わくが先行し、初心者に易しいを
ポリシーにしていたものの、実は初心者が理解できる代物ではなかったと思われます。
>>146 ロバストネス分析やシーケンス図を基にして「インターフェースを作る」ことを”詳細設計”と了解してる。
「設計」って考える作業でしょう。で、インターフェースって考えないと作れないから設計かな、と。
クラスそのままの引き写し構造でつくればいいってもんじゃないんでしょ。
インターフェースさえ作ってしまえば、あとは力仕事的にゴリゴリ書けそうだなと。
実装のうまい・へたはともかく「インターフェースの設計」のおかげで動きは保障されるだろうと。
お前はクラスを考えて作ったことが無いのかと問われると、たぶん頭の中でしかない。
せいぜい、主要部分のヘッダファイルを書くくらい。チームの時は実装担当者にお任せしてた。
んー。うまくまとまんないけど、DIの「構造と実装を分離する」ってのが、
・単なる実装レベルの一手段で、便利ツール的なものなのか、
・それとも設計手法に関わってくるほどのものなのか、
ってのが分かってないのかも。
>ところで 1 画面 1 クラスってのは、どういう構造よ。
勘違いされてるような。前述の例はWin32アプリ。具体的にはC++Builder。
細かい業務ロジックはフォームクラスに配置したUI部品のイベントハンドラに直書き。
重要な処理は private なメソッドに閉じ込めて、イベントハンドラから呼び出し。
たしか５０画面以上あるけど、その画面でやってることが基本的に１ファイルにまとまってて、
ほかの画面からも独立してるから頻発する改造に対応するには手っ取り早い。
Web だと通用しないかもしれないし、相当荒っぽいやり方だとは思うけど。
S2ﾀﾍﾟの作者もここ見てるね。
はてなに書いてたよ。
要望があれば書いてみれば。
メールしたほうがいいとは思うけど。
154 ：
デフォルトの名無しさん：04/09/12 01:04:48
で、結局Springとどう違うの？
舶来か国産か
>>150 そうか？ .netだってSpring.netみたいなDI出てくるし
変わってくると思うけど
>>149に挙げられてるものはすべてJavaローカルなものだし。
.NETの人たちがMS以外のフレームワークを積極的に使うとは思えんし。
さらに言えば、コーディングレベルの話なので、本質的な変化ではないからなぁ。
仕事のやり方がかわるよりは、仕事に携わる人の種類・層が変わることの方が劇的な変化だから。
>>153 作者じゃないってさ。
ま、メンテナでもいいんだけどね。
確かにどうすれば普及するのかねえ。
なんかS2JSFが出てくると更に普及の可能性が低くなりそうな気がするね。
S2タペというよりはタペの話になってくるのかな。
しかしそのメンテナ曰く
＞＞そもそもドキュメントを読まなきゃ使えんと言うのが問題。
じゃ、どうやって使うんだろう？
今までマニュアルやリファレンス読んで作りながら習得してきたんだけど、
そのやり方には問題ありって事なのか？
もっと手っ取り早く習得できるやり方があるのなら大歓迎だけど．．．
補完してったらなんとなくわかる、ツールで適当にやってればできる、というのがいいということかな。
ドキュメントを精読しないと使えんというのは問題だろうが、だからといってドキュメントがないのも問題だな。
補完していくだけでセッション管理やトランザクション管理なんかが分かるフレームワークができればそりゃ普及するだろう。
というか、ウィザードで処理の雛形作ってくれるだけでも全然違うだろうね。。
つーか、そもそも補完する取っ掛かりが分からないからドキュメント見てるんだけど。
同様に、コメントなしでわかるプログラムが理想だが、だからといってコメントを書かなくてもいいわけではないな。
>>161 オブジェクト指向で書かれたプログラムでコメントなしってつらくねー？
JavaDocでもなんでもいいからオブジェクトの説明ぐらい要るだろ？
>>162 だが、クラス名だけで出来る限り分かるようにすべきだ。
たまにコメントがなければ、さっぱり意味の分からないクラスを見かけるが。
JavaDocは仕様を書くところで、
実装の説明じゃないから、
そこんとこヨロピク
>>163 英語分からない奴が無理やり英語の名前でクラス名つけたりするとそうなるよな。
わかんねーなら日本語をローマ字記述でクラス名書け！つーの。
しかし、KensyuとかHuriwakeとかHojyoとか、許せないローマ字はやめてほしい。
もうね、jyoだけはやめて欲しいよ。
>>167 英語と混じるとはげしく違和感のあるローマ字記述法ですね？
>>170 英語と混じれば違和感あるのはどっちも同じ。
英語に出来ない業務用語って多くね？
>>172 EJB は問題外です。今更 EJB 3.0 では DI や AOP と取り込んで
すばらしいものになりますってか。しかも 2.0 まで利用者の怒りが怖くて
互換性を残すと。金儲けする人も大変ですね。
EigoNiDekinaiGyomuYogo?
177 ：
デフォルトの名無しさん：04/09/13 22:26:30
S2TapestryってAOPで認証チェックとかできるのですか？
そんなサンプルあれば欲しいです。
InterceptorでVisitオブジェクトをgetするために、
MethodInteceptorインターフェースを実装させてBasePageクラスを継承させるの？
なんか変ですよねえ。。。
どうすればいいのか教えてください。
いちいち、Pageクラスで認証チェックするのは手間です。。。
AOPじゃなくてもFilterとかでうまくできるのでしょうか？
日本語→英語→カタカナ
にしたときに違う意味になってしまうものは困る。
え、スレ違い？
話題ないんだからいいじゃん。
>>181 だったら
>>177に答えてやれよ。
>>177 どうやらS2TapestryのPageクラスではAOPは使えないらしいぞ。
Tapestryは使ったこと無いけど、昨日のひが氏の日記に書いてる。
Tapestryは内部的にオブジェクトを生成するので、S2でインスタンス生成を握れない。
だからouterでDIを使うことはできるけど、S2AOPは使えない。
認証部分をS2から取ってくるコンポーネントに任せればいけるかも。
やったことないからわからんけど。
それでできるなら、もちろん認証部分のコンポーネントはDI可能。
そろそろS2JSFでる頃かな？
期待age
S2JSFは期待したいね。Kijimunaも良くなってきたから楽しみだ。
186 ：
デフォルトの名無しさん：04/09/28 09:55:02
そもそものJSFのオープンな実装って出ないのかなぁ。
ともあれ、こういったコンポーネントはSpringの方が充実していくだろうから、オレとしてはSpringでDICONが使えるようにして欲しい。
今みたいな、同じ役割のメジャー&めんどくさいフレームワークとマイナー&お手軽フレームワークが並列する状況どうにかならんもんか。
軽いフレームワーク -> メジャーになる -> 要望に応えて重量級になる
>>188 核の部分は変わらないし、OGNL使ってるから高機能だし、Springに比べてお手軽なのは変わらんと思うよ。
SpringでDICONが使えるようになってほしい。
もしくはSeasarでSpringXXXが使えるようになってほしい。
>>189 そのDICONってなに?
Spring固有の機能使ってなければ、SeasarでSpringXXXはうごくんじゃないの。
>>190 Spring固有の機能使うからSpringXXXなんだと思う。
なんかFlexに力入れてるからS2JSF遅れそうだね
その分S2Tapeが強化されそうだし気長に待ってもいいんじゃない？
Tapeなんて使いもはん。
>>189 その使いたいSpringXXXってどんなやつ?
>>195 SpringHibernateとかSpringDAOとかJSF Springとか、Seasarでも並行開発されているヤツ。
今後もSpringの方が先行しつつ並行開発されていくヤツ。
>>196 素直にSpring使うほうがいいんじゃないか？
SpringXXXを使いたいならSpringを使うほうがいいだろ。
漏れはS2DaoのためにSeasarを使ってるし。
S2JSFがそのうち出てくるのに今更S2Tapeやる気は起きない。
YSFとかでも勉強しとくかな。
お前らの会話は訳が分からん。
今後は文章に含まれる英字の量は全体に対して1%までと
規定するから、厳守するように。
SeasarのSpringより優れている点ってどこ？
NirvanaとかMyFacesがあるでしょ ＞186
＞202
国産・マニュアルが日本語、イベントも国内
今のところ、S2本体のソースがシンプルで追えなくもない
S2DAOが凄い、一方でS2HibernateもありO-Rマッパーの選択肢がある
Flash、Flexといったフロントエンドへの対応が進み出している
blog、MLでダイレクトにひが氏やコミッタにリクエストや質問を投げれる、
且つ、即座に採用されたり、回答がある
今のところ、Springと比較すると学習がお手軽、Spring MVCなんかを
DIって何？ってな新人さんに説明するのは難しいかも
お客さんのオプソ懸念に対して保険として国内での有償サポが準備？
まだ提唱されて間もないが、くーすといった開発方法論が芽生え始めている。
>204
S2Daoは確かに凄い。SQLを使える人なら間違いなく感激すると思う。
DB周りのコードがほとんど消えてなくなるんで、なんだか騙されてるような気がしてくる。
くーすは考え方はすっきりしてて分かりやすいけど、いざ実装しようとすると困る。
Strutsでいうと、Actionクラス＝くーすのコントロールで実装してみて一応それっぽくなったけど、
「ロジック層が業務フローを制御する」って言われると、コントロールがStruts依存になってるから駄目っぽいし。
でもコントロールをわざわざActionクラスと別に書くなんて面倒くさいし。書けといわれれば書くけどさ。
広く使われるには、誰かがくーす用のFramework的なものを書かんと難しいんじゃなかろうか。
NirvanaってJSFタグ吐き出すだけだと思ってた。
実装もあるんだ。
>>204 SpringMVCはWebでは使う必要なさそうだね。
S2DAOとSpringDAOの違いってどうなの？
定数アノテーションっていうのはCayenneと同じでおもしろいと思うけど。
OGNLと定数アノテーションがSpringとの大きな違いなのかな？
WEB+DB PRESSに解説記事が載ってたけど、ムダに大きいデータ構造で、ムダに本質的ではなさそうな部分が長いサンプルに読む気が萎えた。
それにしても、オープンソースプロジェクトってある程度広まって使えるようになったころに、プロジェクト自体があぼーんするからなぁ。
あまり大きなフレームワークは使いたくないというのが本音だ。
Seasarも、某社が会社の事業としてサポートするような、法人としての取り組みができるようにしたほうがいいと思うな。
そのためにはSeasarで利益が出せるようなしくみが必要になるんだけど。
でも、そうしないと、オープンソースプロジェクトって長続きしないよね。
209 ：
デフォルトの名無しさん：04/10/01 12:18:22
>>208 一応、電通国際情報サービスがサポートするらしいね。
ところで、S2Daoでディスクキャッシュ機能があるとか昔日記に書いてあったが、
どうやればできるの？
>>209 SpringやらSeasarは今後3年くらいかけて浸透するだろうから、機能をあわてて実装するよりも、プロジェクトが5年10年続くようにがんばってほしいな。
>>210 浸透ってのがどの程度を言ってんのか分からないけど、俺はなんか違うとおも。
例えば Web アプリと言えば、Tomcat や Struts は浸透してるとおもう。
これが 3 年後に Tomcat と Struts、んで DI コンテナは何？ ってなことにはならない希ガス。
汎用 DI コンテナはフレームワーク作成者や新しいもん好きが使うものであって
システム構築者には汎用的すぎる。特化してるっぽい S2xxx や Springxxx とか
あるけど、まだ DI 使うとこんなすごいことができるみたいなオモチャに見える。
DI コンテナが浸透するんではなくて、フレームワークやライブラリが DI を
使用するのは当たり前になり （DI は自前でも良いし、cglib、javassist、BCEL、asm
なんでもいい） DI を冠することも無くなり、開発者に意識させないと思う。
>>211 もちろん、DI+AOPは基盤技術になるわけだから、本来表に出るもんではないと思うよ。
オブジェクト指向のためにJavaを使うんじゃなくて、Javaって便利だけどこれってオブジェクト指向に基づいてるらしいよ、みたいな。
なんかめっちゃ楽なんやけど、これってDIとかAOPっていうもののおかげらしいで、と。
ていうか、使用するのは当たり前ってことは浸透してるということなんじゃないかと。
ただ、そのためには実装とそれに基づいた実用部品が必要で。
その実装として、今はSpringとSeasarがあるわけだ。
あと、DI自体は使うのが非常に楽で、使えば結構自動的にアプリケーションの多層化やら部品化ができるから、やっぱりその利点を認められて広まると思う。
AOPは、末端開発者が積極的に使うものというよりは、コンポーネント提供者が利用して、末端開発者は何も考えなくてよくなる、という仕組みだと思ってる。
AOPこそ、開発者に意識させないものだと思うな。
使う言葉が違うだけで同じことを言ってる気がしなくもないが。
そういえば、誰かDIconファイルを視覚化して編集するツール作ってるみたいだけど、あれってもうちょっと発展させたらなつかしのAPPGALLERYみたいになるね。
ありがちなビジネスロジックの呼び出し仕様を集めたインターフェイスを登録しておけば、そいつを視覚化したものを配置して、メソッドつなぎあわせればアプリケーションになる、と。
呼び出し先の引数と同じ型のプロパティ持ってたらそれを自動的に渡して、みたいな。
ダブルクリックしたらそこのソース編集とか。
よくない？
>206
スマソ、HTML2JSP、JSFのコンバータだった。
>209
キャッシュはまだ未実装な筈
>>205 Actionは、業務ロジッククラスの一つのメソッドを呼ぶだけに白ってことだから
そんなめんどくさいことないだろう。
これまでも、Actionにロジックをおくなって言われてたわけだから、
そんなにかわんないだろう。
ひが君の日記より
> 実装上は、バウンダリから呼び出されるメソッドは、インターフェースになり、
> コンポーネント内からしか呼び出されないメソッドは、実装クラスのpublicメソッドに
> なります。
> 内部からしか呼び出されないのに、実装クラスのpublicメソッドにするのは、
> テストをしやすくするためです。別にprivateメソッドでもリフレクションを使って
> 呼び出せますが、コンポーネントを使う方は、インターフェースしか見ないので、
> 特にpublicでも問題ないと思います。
内部メソッドを public にか。俺はこれをダサいと思わん神経を疑う。
ひが君の日記より
> くーすは、というより私は、各開発者のスキルをまったくあてにしていません。
> ドライに聞こえるかもしれませんが、現実のプロジェクトを乗り切るには、
> そう考えざるを得ないのです。そして、どんな人でも一定の品質のものを
> 作り上げるための仕組みを考えるのです。
要は
S2 使う側の香具師はバカかアホしか居ねーから簡単に使えるようにしますよ w
バックエンドの難しい仕組みはスキルのある俺様しか理解できないですよ w
と。
正論だが、それを公開日記でいうおまえはどうしようもないバカだ。
このご時世に「ダサい」という言葉を使う神経を疑う
>>218-219 なんか嫌なことでもあったか？
こんなところで愚痴ってもしょうがないぞｗ
奴の日記読んでるんだったら、
奴が２ちゃんなんか読まないし仮に読んだとしても気にも留めない奴だって分かってるだろ。
ここじゃなくて奴の日記にコメントしろよ。
面と向かって文句言えないから陰口叩くちゃねらーの典型だなｗ
ちなみに私はＤＩコンテナ信者です
>>221 別に嫌なことなんか無いが、奴は最近方向が少しずれてきた希ガス。
確かにS2もいろいろなところで取り上げられてるしね。
調子に乗るのもわらなくはないけど。。。
まあ周りの取り巻き連中が持ち上げまくってるのかもしれないね。
個人的には調子に乗ってもいいから、S2JSFをきっちり作り上げて欲しい。
それと、S2Dao。
この２つさえきっちり作ってサポートしてくれれば持ち上げまくってもいいよｗ
別に調子に乗ってるようには見えないけどな。正論なら公開の場で書いてても
いいんじゃないかと思うし間違ったことは書いてない。
そもそもフレームワークってそういうもんだろ。そんなに嫌いなら見なきゃいいのにｗ
嫌いなら見なきゃいい、みたいな生産的じゃない発言増えたなぁ。板的に。
嫌々見て２ちゃんで愚痴ってるのが生産的だとも思わないなぁ。漏れ的に。
既存のRUPなんかで提唱されている手法を実践しようと
して苦しんだことがないから馬鹿にされているように感じるんでしょ。
くーすが嫌なら一般的にいわれているようなユースケース駆動
なんかの設計でやってみればいいじゃない。俺はやってみて
これがだれでもできる方法だとは思えないからくーすの
思想には賛成できるけど。(具体的な手法に関しては置いといて)
>219
>S2 使う側の香具師はバカかアホしか居ねーから簡単に使えるようにしますよ w
バカかアホしか居ねー「と考えないと現実的に回らない」
>バックエンドの難しい仕組みはスキルのある俺様しか理解できないですよ w
バックエンドの難しい仕組み「を全員が意識しなけりゃならない状況は現実的じゃない」
曲解はやめような。
それ以前に、沢山の人を使ったことがあるかってことだな。
沢山の人の能力を全部把握して適切な仕事を振るなんてできやしないんだから、
全員が並の能力でも大丈夫な方法を模索するのは正しいと思う。
そういう意味ではくーすはある程度の人数を想定した開発・設計プロセスなのかな。
たとえばうちみたいに一人二人で1-3ヶ月やるようなプロジェクトでくーすに従って。。。というのはどうなんだろ。
232 ：
デフォルトの名無しさん：04/10/03 09:37:22
>>231 ひとりふたりだと、プロセスがなくてもまわるっちゃまわる。
それでもプロセスの採用は有用だと思うよ。
>>219 その日記は明らかにプロの現場を指してる。
あの子が欲しい、この子は要らない、相談しましょ、そうしましょ
ってできないし、勝手に配人されるし、何より初めて会った人が
何をどこまで知ってるかなんて分からない。
アレとソレとコレを知ってる人が居ないと回せませんとか言った
ら、それこそ自分自身が要らない子になってしまうｗ
日記の内容なんて本当は関係ないんだろうな。
粘着したいだけなんだろきっと。口実が欲しいんだよ。
そんなことよりもS2JSF激しくキボンヌ！出してくれたらひが氏ラブｗ
心配するな。
ひが君は、ちゃんとここ読んでるから。
なんだひが「君」に釜ってほしいだけか
ひがたんにカマ掘ってほしいＹＯ
238 ：
デフォルトの名無しさん：04/10/03 15:30:17
ひがたんが・・・
ウホッ・・・！！！
>>230 > 全員が並の能力でも大丈夫な方法を模索するのは正しいと思う。
俺が正論って言ったのをフォローしてるだけか。ってか、おまい、奴の言った
「各開発者のスキルをまったくあてにしていません。」
に自分が含まれていないって曲解してないか？
「易しいこと、優しいこと･･･」
一人のサポーターが挙げてくれた S2 の哲学的ともいえるテーマを、
ひが君琉に言うとこうなるのか。本質は同じだが、明らかにひが君はうんこ。
あのファウラーでさえ、自分はまだまだ未熟と言ってるのに（ry
そんなにひが君のうんこを食いたいのか藻前はｗ
藻前が粘着したおかげで易しさと優しさがサイトから
消えたんだから満足しろよ。ひが君に優しく易しくして
欲しいのか？
実際易しかったのかもしれんが、優しくはないからな。
使えばわかる、ソース見ればわかる、だもん。
>>242 半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ
>>245 あんたよく見てるな
ほんとだ。感動した！
＞244
使わないと「知った」だけで「出来た」にも「判る」にもならんと思う。
誰もに優しくは努力目標にしても、マニュアルもかなり改変されてるしな。
AOPとS2DAOなんかは更に判り易くなったんじゃなかろうか。
板が荒れるとフォモか巣加戸炉になるな。
板は荒れてない。荒れてるのはスレだ。
荒れているひとりがいるだけなんだがな。
>>244 使ってみる。ソースを見てみる。は、技術者として当然の行動文法。
教えてくれるのが当然君は芯でいいよ。
まあソースを見ろとまでは言わんけどな。見ると勉強になるのは間違いないが。
ここで粘着してひが君を自分の思うとおりに動かしたい奴がいるってことだろ。
S2とか技術には興味が無いんだよ。興味があるのはひが君そのものなんじゃないの？
だから取り巻きも気に入らないしスキルがどうこう書いてると自分のことを責められてる
気がして可愛さ余って憎さ百倍になってんだな。ホモのストーカーって恐いな。
そうか、見てるのか・・・・・・・
なんか急にこのスレも格調が上がった様な気がしないでもないｗ
ほらほら新しいバージョンが出ましたよ
S2JSFもちゃんと作るってさ
なんかなあ
漏れは219でもないし、219を擁護するつもりなんざ全くない（むしろ叩きたry）けど
ここじゃなくて自分のblogで批判つーか「来いや」はな・・・
はぶ氏にどんな事情があってここに書き込まないのかは知らんが、
どっちもやってることのレベルは大して変わらんな
自分の署名になる自分のブログで書くってのは
意味はあると思いますがどうでしょう。
255さんの意見がハブ氏の（あっカタカナで変換したら
これまた沖縄くさい感じに！）ブログに書かれていたら
結構面白いんじゃないかなあ。
でも2ちゃんで書き捨てる気楽さも確かにあるし
それだけにあけすけに本心も出る面もありますな。
S2JSF期待age
ひがひがとはぶはぶは、こんがらがることもあったりなかったりするけど、重さ的にだいぶ違う。
>>249 そういう考え方は、それはそれでいいと思うけど、それを「優しさ」というのかな、と。
>>255 いや、ちゃんとそこらへんに書き込んでると思うが。
なんにせよ、2chの書き込みに反応するのは意味があるにしても得策ではない。
>259
誰に優しいか、っていうと「ビジネスする技術者に」なんだろう。作者と同種の人が対象なんだよ。
効率的な実装手段を求めてもがいてるような。教えて君や駆け出しの新人は入ってないと思われ。
それに、ソースはうまくいかんときにデバッガで追うくらいで十分。
ソース読まなきゃ使えないほど難しくもないし、声高に叫ぶほどドキュメントがないわけでもない。
>>262 もう記述は外れてるからどうこういってもしかたないんだけど、「初心者にもやさしい」というニュアンスだったような気がするんだけど。
「ドキュメントが豊富です」と声高に叫ぶほどドキュメントが充実してたわけでもないし。
要は、宣伝文句と実情が異なってたからどうよ、と思ってたわけさ。
>>263 J2EEとコンテナ、アスペクトの初心者には充分やさしいと思う。
さすがにJava初心者にはやさしくない。ていうか、インターフェースでプログラミングすると
いうことをSQLできます、COBOLやってました。という人々に理解してもらうのは、すげー難しいぞ（W
まあ、問題は初心者っていったときに、なにか勉強しはじめた人のことではなくて「初心者という生き物」のことを指してしまうことがあるからなぁ。
宣伝文句と実情が異なってたときに、オレとしては実情の方をあわせて「これでどうよ？」となってほしかったのだけど、宣伝の方が取り下げられてしまったのは残念だ。
マンパワーの問題もあるだろうし、しかたないのだろうけど。
実情が伴ってきたときに、またあの宣伝文句を掲げてくれれば、と思う。
>>255 ここに実名で書き込むヤシはいないだろ。
>>265 マンパワーの問題というよりも、ここでの粘着振りに
ひが氏がうんざりしちゃったんじゃないのかな
コンテナのドキュメントが急に書き換わったり
意地になってた気がする。
268 ：
羽生：04/10/04 11:07:35
羽生と申します。2chで本名で書くのもどうかと思いますけど、けじめはつけておきます。
まず、ここに書き込まない理由は、
１．私は長文になってしまうので「長文ウゼー」って言われるからです。
改行が多すぎて書き込み出来ません、ともなります。
２．誰がどの書き込みをしたのかわからないので、脊髄反射的な会話に
しかならないからです。ハンドル名であっても一貫していれば、書き込みの
流れから行間を読むことで解釈のずれを埋める工夫が出来ますが、
そういう機能がないため「書き手の気持ち」を類推することが出来ず、
結果として言葉尻だけを取り上げることが多いからです。
これは、「私には」しんどいことです。
３．追いかけるのが大変だからというのもあります。自分の発言にレスがあったら、
きちんと返さなければという強迫観念があります。blogの場合は、あくまでも「コメント」ですので、
それに対してレスをしなければという気持ちは大らかでいられるのですが、
掲示板などだと常にウォッチしなければということで、日常に入り込んでしまいます。
忙しいときにはそれが苦痛になるので、控えています。これはMLもそうです。
４．自分が発する言葉は自分の心からしか出ません。ですから匿名であっても
責任が生じます。しかしトリップをわざわざ取ったりなど、仕組みとして「自分の責任」を
表明するのが面倒です（取ったこと無いし取り方を調べるのも面倒^^;）。
ですからここで自分の名前によって書いても、騙りと思われたりする可能性を考えると
blogのほうが確実だと考えています。
以上です。その上で、もう少し書きたいと思います。
269 ：
羽生：04/10/04 11:09:45
まず、「優しさ」ということを掲げることについては、誰も反対はしないと考えています。
要点は、これを「理念・目標」と捉えるか、「宣伝」と捉えるか、でしょう。
では、これについて、
「私は宣伝と受け止めた。ついては宣伝に反している。改めるべきだ」
と考えた場合に、意味のある形につながるように取れる行動として、
例えば次のようなことがあるのではないか、と思うのです。
「優しさ、と書いているが、自分には優しさが足りてないように感じる。
ついては、まず、こういうドキュメントを追加してみてはどうだろうか。」
そして、ほんの少しでも叩き台として出していただければ、それが呼び水となります。
ゼロから1への最初の一歩が大変なのです。マンパワーの問題もありますが、
そもそもご指摘があったように、知ってしまっている人間にとっては、ここが足りてないのか
という最初の気付きは難しいものです。
せっかくオープンソースであり、しかも英語圏に比べれば圧倒的に身近な国産のプロジェクトなのですから、
前向きな小さなはじめの一歩をいただければと思うのです。これをMLに投げてもらうだけでも随分と有効です。
MLも別にyahooメールで書いてもらっても構わないのです。同じ問題意識の発露であった場合に、
少なくとも、ここで汚い言葉でののしるよりもどれだけ有効で、どれだけ他の人の役に立つでしょう。
ですから、私はここで文句を言ってるだけというのは、実はこういう問題意識を持ってのことではなく、
それはポーズであって、実は別の感情が潜んでいるのではないか、という風に感じてしまいます。
このスレに書いたことでさえ、ひがさんはちゃんと受け止めて反映しています。
JavaDocプロジェクトも徐々にですが着実に進んでいるのも、例えばからさわぎで
「2chでも指摘されてますが、JavaDocいる人ってどれくらいいます？」というようなやり取りをして、
そこからちゃんと取り組みが始まっています。拒絶はしていません。
ですから、もっと誰もが受け入れやすい形でご提案いただければすごく嬉しいです。
270 ：
羽生：04/10/04 11:11:34
引き続きですみません。
さて、私はこのスレの位置付けというのは初心者にとって大きいため、
ここで不当に貶されるのは、S2へのアンチマーケティングをされていると考えています。
というのは、Seasarで検索するとこのスレがヒットします。知識のないひと（スキルがない
のとは別です）が、ここを見てどう思うか、ということを考えると、必ずしも実情が伝わる
とは思えないのです。
というのは、「優しさ」という言葉尻とその周辺のことばかりが取り沙汰されていますが、
では技術的にどうか、などのことは全然触れられていません。端的に言えば、ひがさんや
取り巻き（この表現の意図もよくわかりませんが）の人格に対する話しかないのです。
ということは、人格に関する情報だけで技術水準を判断されてしまいかねません。
つまり「優しさ」の守り手たらんとしている誰か（誰か、としかいいようがありません）の
発言が結果として、「優しさを必要としている人」の無知識につけ込んでいるようにも感じます。
私たちがやっていることが、全て必要にして十分なレベルにあるなどとは到底いえませんが、
残念ながら客観的に評価されているようには思えません。
こういう部分は優れている、こういう部分はもっと改善が必要だ、というように、要素ごとに
きちんと評価して総合判断を提示するのが、技術者の基本ではないかと私は考えています。
その評価結果が厳しいものであってもそれは謙虚に受け止めてさらに取り組みます。
その意味において、残念ながら非常に一方的な負の感情のみで書かれているようにしか
見えないものが多いのです。ここでまた、S2そのものに対するのではなく別の感情が潜んで
いるのではないかと考えたりもします。
271 ：
羽生：04/10/04 11:16:01
とりあえず最後です。
このようなことを踏まえた上で、他人を「うんこ」だの何だのという言葉を使うというのはどうなんですか？
実名で「これを書いたのは私です」と胸を張って公の場でいえますか？ いえるのであれば結構です。
是非、私と会いましょう。いえないのであれば、それは後ろめたいという気持ちを持っているのです。
後ろめたさを自分で作って抱え込んでどうするのですか。匿名であろうとなかろうと、言葉は自分の心からでるものなのです。
その負の感情をなだめようとして匿名でさらに汚い言葉を使っても、それは悪循環に陥るだけです。
その負の感情の源泉が、Seasarプロジェクトの不出来さに起因するのであれば、わざわざ自分の気持ちを
痛めつけるのではなく、お持ちのスキルとその問題意識を良い方向に発揮してください。歓迎いたします。
もし、Seasarプロジェクトに起因しているのでないなら、それは申し訳ありませんが八つ当たりに過ぎません。
自分の心で解決していくことです。ただそれも、例えばからさわぎのような場所で、普段会わないような
広い範囲の方々と話をするだけでも、何かが見えてくるかもしれません。
実際、からさわぎはJavaは殆どわからないという方も多く参加されています。
そして宴会の場で、技術ではないことでも意見交換が出来て非常に役に立ったという感想を
お持ちの方も多くいらっしゃいます。
「来いや」は確かに言葉が乱暴かもしれませんが、本心です。多くの方が前向きに（S2に対して、ではなくて、
自分の将来に対して）取り組んでいる場に触れるだけでも全然気持ちが変わります。
私も別に年中元気なわけではありません。しかし皆さんとお会いすると元気をいただけます。
私も少しでも皆さんの元気のお役に立てるようになりたいと思ってます。
是非、お会いしましょう。前向きなケンカは必ず第3の素敵なアイディアを生み出します。別にケンカしなくてもいいんですけどね(^^)
今後ともS2およびSeasarプロジェクトへの叱咤激励をよろしくお願いいたします＞all
尚、やっぱり恐いので基本的にここでは書きません。2chで実名出すのはやっぱりドキドキしますよ（ｗ
心配しなくても、実名の人に対して叩くほどの度胸はもちあわせておりませんよ。
トリップは適当に「羽生#seasar2004」みたいな#のあとに何かつけたらMD5かなんかの文字列になるだけなので、つけたほうがよさげです。
長文ｳｾﾞｰ
ハブカブアガル。微妙に。ちょっとだけ。
つか、
>>242 >>に自分が含まれていないって曲解してないか？
含まれてるのを前提として
>>230を読み直しても、全然問題ないんだけど。
どう読んだら
>>230がそういう曲解に見えるんだ！？
おまい、ひがさんの直下のプロジェクトやったことあるんだろ。
うらやましいなぁ。漏れは馬鹿にされるぐらいの勢いでケアしてもらった方が、安心できるけどな。
11月のからさわぎには絶対参加しよう。
>>277 はぶたんには、長文乙と伝えてくれ。
ひがたんには、うほっと(ry
それよりオマエら、S2のSがSpringのSとまぎらわしいと思ったことはないか？
オレはある。
プレフィックスはまぎらわしくないものにするべきだ。
ここは「夜の」をつけることにして大人の雰囲気を醸し出すようにするのはどうだろう？
つまり「S2Struts」「S2Hibernate」「S2Dao」を「夜のStruts」「夜のHibernate」「夜のDao」とするのだ。
これでSpringより大人な感じが伝わるのではないかと思う。
それは素敵な案だが少し淫靡な香りが漂う気がする。
そこで大衆の支持を得るために「冬の」をプレフィックスに
するというのはどうだろうか。春（Spring）に対抗するのだ。
「冬のStruts」「冬のHibernate」「冬のDao」とするのだ。
これでSpringよりも婦女子の人気もバッチリだろう。
私はどちらかというと方法論者(Methodologist, 社内でRUPとかの推進をしています)で，その立場からSeasarを応援(期待)しています。
理想的には純粋なOO分析，設計でRUPなのですけど，スキルやリソース，コストの観点からは最低レベルの技術者でも一定の枠組みに従って開発できる仕組みと方法論が必要というのが現実のところです。Seasarと「くーす」はその一つの回答となっていると考えました。
こちらでもはぶさんのおっしゃられているようにもう少し建設的な意見があると良いかなと思うのですがどうでしょうか。
>>281 そんなに否定的な意見ばっかりかなぁ？
否定的意見に対する反論もあるし、後は読んだ人が自分で判断することなのでは。
>>281 匿名の場合、ネガティブな部分が大きく出て、建設的な意見は出にくいと思う。
ナイスアイデアは名乗ってから言いたいからな。
逆に、否定的な意見をここで拾えばよろしい。
>>279-280のようなとても建設的な意見もあるが。
っていうか笑わせるな。ひさびさ腹いたくなった。
否定的なことを建設的に書けばいいんじゃないかな。
特定個人をとやかくいうんじゃなくて例えばJavaDocがない
とかならS2DaoのここだけでもJavaDoc書けやゴルァとかな。
何をやればもっと良くなるのかを指摘してやればいいんじゃないかな。
全体的な指摘だと、こうするべきっていうのは書きにくいからなぁ。
現状サイトが貧弱だし、最初の入り口になるナビゲーションが非常にとぼしい。
最初になにをすればいいかわからないしな。
何度も言ってるけど、使ってみないとなにができるかわからない。
DIやAOPがなんであるかを知っていないと、使おうと思わないだろうな。
こういうのは、「ここをこう」みたいなヒトコトじゃ指摘できないんだよね。
ま、とりあえずホームページの体裁を整えて欲しい。
作者のブログとはいえプロダクトとはあまり関係ない話題を引用してきてどうこういうのはどうかと思うが。
トップページは何の更新もないし、タイムスタンプで新しくなったのがわかっても、ダウンロードするまで何がかわったかわからないし。
で、よくみたらブログにはちゃんと書いてあったりする。
>>287 それははなからブログをチェックするのが正解かと。
>>281 ２ちゃんのスレは「小さなはじめの一歩」次第でどうとでも変わります。
一旦方向性をみつけると、良くも悪くもそちらへ爆走します。
どちらに向いて爆走するかは「小さなはじめの一歩」次第です。
太田氏が「方法論者(Methodologist, 社内でRUPとかの推進をしています)」であるなら
その現場で培われた成功例(例えば、知識のない人にどう啓蒙していったのか、どうや
って教育したのか、何を見せどう説明したのか等など)を書き込んでもらえると、このス
レにとって「前向きな小さなはじめの一歩」に成り得ると思うんですが・・・・・・・・
勿論、ただの要望で「もしよろしければ」という話です。
>>288 そういう情報は、「公式サイト」には書いてないからねぇ。
別に広めるつもりがないならかまわないけど。
雑誌なんかでSeasar知った人が、ブログをチェックしないといけないとは考えないだろ。
「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。
291 ：
デフォルトの名無しさん：04/10/04 21:59:47
国産じゃデファクトスタンダードには間違っても為らないワケで。
国産唯一の利点は「ドキュメントに読みやすい日本語が期待できる」だが、
それも無いし。
結論：ｲﾗﾈ
デファクトスタンダードは難しいだろうけど、ニッチでもいいじゃん。
世の中みんながトヨタやフォードに乗ってるわけでもなければ、
OracleやDB2を使ってるわけでもないんだから。
つーか、デファクトはEJB3.0なんじゃないの？
実際の小さい仕事で使ってみて今、基本部分が出来上がったとこ。
業務ルールとそれのつなげ方を分けて管理できるライブラリ、って感じで使ってみたけど
なかなかイイよ。俺は手抜きしてついつい業務ロジックを大きく作っちゃうんだけど、
単純なクラスをDICONで連結する構造が、結構自然に簡単にできた。
慣れるまで１週間くらいはかかったけど。さすがに１時間じゃ無理ぽ。
あと、バックエンドが簡単になったらフロントの Struts の辛さ倍増。
はやくS2JSF使わせてけろ。
>>292 使ってみれば、いいことはわかるんだよ。
そのための情報が少ないのが問題だね。
ブログ騒ぎで「ここだけの話」を見てみたら、リリース情報が逐一載っていた。
唖然とした。
公式サイトのチェックはしてて、新しいもののリリースは最近ないものだと思っていた。
294 ：
デフォルトの名無しさん：04/10/05 00:05:04
公式サイトのwhat's newが欲しいってのはわかるなー。
MLでは逐一リリース告知されているわけだが
sourceforgeにも、リリースメモがあると思うが。
要するに興味ないくせに文句だけは言いたいわけだ
探さないのが問題だとも言えるし、探さないと見つけられないようなのが問題だとも言えるかも。
>>295-298 「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。
とりあえず、公式サイトは吉田カバンなみ。
ていうか、Seasarに文句言ってるヤシは、Springを使ってるの？
あとはオブジェクト指向分析・設計の研修ですと，
やはりみなさまオブジェクト協調関係の生成をどのオブジェクトがどういったタイミングですべきかについて悩むが多いです。
そこで，Robert C. Martinのオブジェクト指向の基本原則などとからめて，DIコンテナを説明し，
もっともとっつきやすい(私の主観ですが)，Seasarを紹介するという形です。
モノ自体の仕組みとしてはとっつきやすいと思う。
SeasarのBean定義はSpringより少ない記述量でできる。
だから、わかってる人が近くにいれば、とっつきやすいと思う。
問題はわかっている人が近くにいないとき、Springの方が情報が得やすいということ。
>>305 >Springの方が情報が得やすいということ。
そうか？
Springは機能やら専門用語が多すぎて、わけわからん。
>>306 書籍に記述もあるし、網羅したリファレンスもあるし、そのモノが難しいというのは置いておいて、情報は得やすいと思う。
AOPのための記述とか、Seasarに比べるとアホみたいにめんどい。
もっと簡単な記述があるのかもしれないけど。
308 ：
デフォルトの名無しさん：04/10/05 14:58:08
S2のJavadoc、@authorの下の行にコメント書いてある。
作者はJavadoc使ったことねぇのかな？少し笑えたぞ。
「2chに悪意を持って書き込む奴がいる」って何をいまさらｗ
善意がないだけで、悪意もないと思うんだけどね。
無責任なだけで。
「Seasar2はインストールするだけでシステムが不安定」とか事実ではないこと書けば、それは悪意があるんだろうけど。
>>309 ところで、どこに書いてあるの？
それ。
なんか、サイトの構築始まってるね。
左側のメニューにWhat's newが欲しい、とか、ロードマップが欲しいぞな、とかは思うが。
まあとにかく要望は出せばキリがないからほっといて、早いトコサイトインできるようにがんばって欲しいね。
せっかくWEB+DB PRESSに寄稿したり、JAVA PRESSに記事が載ったりしてんだからね。
記事みてサイトにアクセスして迷子になってあきらめる人がいるだろうから。
307を書き込むときに、AOPのドキュメントってこんなに充実してたかなぁと思ったんだけど、やっぱり書き直されてたのね。
サイトの更新履歴も欲しいぞな。
ブログベースってことで、どうなるのかしらんけど。
まあ、関係者のブログの関連するネタを整理して、アイドルネタを省いたものになるという感じか。
314 ：
デフォルトの名無しさん：04/10/05 21:38:25
EJB以外を使う香具師は、厨房。
>314
そんな餌（ｒｙ
というか、厨房でもなんでもいいから、動くものを早く手軽に、ってことだな。
いくら高尚で美しい設計でも、利用開始に間に合わないんじゃ仕方ない。
>316
他のコンポーネントやテーブル設計を待たずに実装とテストのフェーズに入れる＞S2Unitによるリードタイムの短縮
S2OpenAMFやS2FlexみたくWebベースでHTML以外のUIの選択肢でも連携する手立てが用意されてるのもS2の良いところかもな。
>317
他のコンポーネント→他の’関連する’コンポーネント’の実装’
>313
S2DAOのドキュメントも刷新されてますね。
真剣に「くーす」で設計してみようと思って、ひがさんの↓
ダイコン事態の設計手法と、その２
を読んだ。
最後の「何か合コン誘われたから行ってくるわ」が気になったので読んで見た。
関係ねーじゃねぇか＞くーす
もう帰る。ｳﾜｧｧｰﾝ
>316
御意＞いくら高尚で美しい設計
美しい設計はあくまでメンテナンス性の為の一手段に過ぎない。
そうありたいし、心掛けてるが納期に間に合って、利益を生むのが大々前提。
で、プロジェクトには新人さんも（使用するテクノロジーに）不慣れな人間も居るのが当たり前。
彼らが、この先淘汰されるかどうかは知ったことでは無いが、現実の案件をデスマらせない
には、個々のスキルに任さないのは一つの立派な考え方。
数を集めるより少数精鋭の方がコストメリットもあるとは思うけど、愚痴をたれても仕方無い。
というわけでS2が選択肢としてあって、使ってるんだが。
>319
御愁傷様（藁。くーすについては大阪のからさわぎの資料がテンプレも付いてるので興味深いな。
じゃあDIは美しくない設計なのか、というと、そうじゃないんだよね。
むしろ、DIだと設計をしなくてよくなるので、美しいとか美しくないとか判定する必要もない。
各機能各層について独立したクラスを作って、ゴンゴン組み立てればいいわけだから。
どこでオブジェクト生成してどこに保持してどうやって受け渡すか、それをいかに美しい設計で実現するかなんて考える必要はないんだから。
もちろんミクロやマクロの設計はしないといけないけど、それはEJBだって助けてくれるもんじゃない。
それにミクロやマクロの設計は楽しいし。
323 ：
デフォルトの名無しさん：04/10/05 23:19:30
without hairとか、禿げ本、禿げ会とかさー、言語の壁を隠れ蓑にして、
先人（Rod）をリスペクトしない姿勢が、鼻につくんだよ。
お前ら、Rod本人に向かって、禿げって言えんのかよ。
他者に優しいのが、XPのペアプロに代表される少数精鋭の徒弟制度。
「スキルの無い奴」とか
「彼らが、この先淘汰されるかどうかは知ったことでは無い」とか、
結局お前、自分に優しいだけちゃうんかと。
>324
少数精鋭のXP、って時点でスキルの無い奴がはじき出されてるぞ。
仕事なんだから、最低水準の質を確保する仕組みってのは求めて当たり前でしょ。
そこから先、どう仕事に取り組むかは個人の問題なんだから。
>323
コミッタでも近しい関係者でも無いよ。確かにイクナイ ＞お前ら、Rod本人に向かって、禿げって言えんのかよ。
禿しく同意だ。が、ひが氏本人が言い出した訳でもあるまい。
323本人の発言ではないと思うが、かといって逆にウンコ呼ばわりしたら同じ穴の狢でしょ？
>324
少数精鋭の徒弟制度がすくすくと育てば、ある意味で素晴らしいと思う。
で、’まず’自分に優しいのは当たり前だろ？社内のみならず協力会社を含めた遍く全ての他者が
今後、どう身を振るかまで慈悲深く’優しく’すんのかい？
つーか難癖つけすぎ。
粗探しばっかりでは面白くない。
330 ：
デフォルトの名無しさん：04/10/06 02:24:16
まぁ、１のことを１０の言葉で語る人のことはさておき
（cocoon本のころは良かったのになぁ）、ちょっと本質的なネタを
振ってみたいな。
(1) S2を使うと、本当にテストがしやすくなるのか
(2) S2を使うと、本当によいものができるのか
(3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか
(4) S2を使わないと、上記のようなことはできないのか
(5) 成果物全体がS2に汚染されるけど、それはOKなのか
まぁこの際S2をDIコンテナと言い換えてもいいや。
いくつかモノを作ってみたが、(1)はまぁ同意できる。
EJB使ってるとFactory駆使しないと結合を切れないが、
その辺をフレームワークとして統括できるのは便利。
(2)～(3)は、ツールで解決するものか？という気がぬぐえない。
あと、テストパターン研究会でも話題になったが、ソースコード
トレースがし難くなるのは避けられないという問題もある。
(4)は程度の問題か。(5)はメリットとの天秤になるのかな。
インテグレーションクラス周辺だけ使う、というのが現実的か。
ところで、S2が正しくinjectionしてくれるかどうかの
テストはどう書けば？（汗）
というわけで皆の意見を聞きたい。
似たような方向の技術ならスタンダードなものを選んで習得するのが鉄則。
となると、EJB以外の選択肢は無い訳で。
332 ：
sage：04/10/06 05:47:27
>>330 >ソースコードトレースがし難くなるのは避けられない
これはDIの概念を読んだときからずっと気になってた。スキルの低い技術者が
出入りする大規模なプロジェクトでは影響がでかくない？
モデリングがちゃんとできる人がインターフェースの設計まで
きっちり終えてからコーディングさせないとメンテ不能なソースになりそう。
ひが氏はクラス図すらいらないみたいな事をどこかで言ってた気がするけど。
開発者もメンテナもくーすに従えば解決するのだろうか？
sage間違えて恥ずかちぃ
>>323 何だSpring派がS2叩きしてるだけか
>>324 スキルのない奴が淘汰されるのは当然だろ？
>>323 で、オマエはRodの言ってることどれだけ理解して実践してるの？
で、お前等結局
１）S2が邪魔
２）ひがが嫌い
３）羽生がウザイ
のどれYO？
俺のおかげでスレも伸びたし S2 も注目されたわけだ。感謝汁！
羽生ウザイ
羽生はキチガイ
羽生はデブ
羽生はウンコ
羽生は氏ね！
>323
Spring派とかいうわけでも無いんじゃね？
>331
EJBとがどこがどう似てるんだろ？スタンダードってのは
2.0なのか、それとも先の3.0のことを指してるんだろうか？
先のことを指すんであればそれこそJDOも含めて、流れが
どうなるか判らんと思うんだが
>330
(2)、(3)は今後のくーす次第かな、S2を使うからどうなるわけでもない。
(4)は疑問自体が難しいな、逆にどう思います？
(5)についてはDIコンテナが依存性を注入するので汚染？と
言われてもと思うんだけど
だからトレースやりづらくなるというのは判らなくもない
>340
ID表示が無い板だからといって朝から釣りはやめような
＞＞３４２オマエ羽生だな（ｗ
羽生氏ね（藁
219頑張れ！219は正しい！219はネ申！羽生氏ね！
>343
釣れて小躍りしてるかもしれんけど赤の他人だ、
数少ない君の人生の喜びを奪って申し訳無い。
>332
どうだろう？メンテナというかカットオーバーしてチーム
が解散、保守は引継ぎってところで発生する問題点は
まだ言及されてないんじゃないかな。
diconのまとめかたを含めて330のトレースの問題が
出てくるかもしれない。
>>330 全て、S2やSpringを使えば無条件にというわけではないというのは前提。
> (1) S2を使うと、本当にテストがしやすくなるのか
コンポーネントが独立するので異なる環境で動かしやすくなる。
> (2) S2を使うと、本当によいものができるのか
よいものの定義にもよる。
同じものであれば早くできるようになると考えれば、よいものにするための時間が多く取れるのでよいものができる確率が高いといえるかも
> (3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか
スキルが低い人が一定の品質を保てるのではなくて、スキルが低い人がいても一定の品質を保てる、だと思われ。
コンポーネントの独立度が高くなるので、スキル低い人の影響が減らせる。
> (4) S2を使わないと、上記のようなことはできないのか
DI+AOPを使わないと、初期コストがかかりがち。
ただし、その場合はプロジェクト用フレームワークをかっちり作ることになるので、DI+AOPを単純に使う場合よりも楽にできるかも。
でも、同じ努力をDI+AOPを使ってやったらもっとやりやすくなるだろう。
> (5) 成果物全体がS2に汚染されるけど、それはOKなのか
設計がDI前提のものになるだけで、個々はあまり依存しない。POJOだし。
だから、S2とSpringを切り替えることも、S2を使わなくすることも、個々の部分には影響なくできる。
と思う。
ソースコードのトレースが難しくなるって
んなもん、ＯＯＰになってから諦めてますよ
ただ、インターフェースの設計をかっちりやらないとダメなのは同意
くーすでは単なる単体テストがやりやすいとかでなくて、
設計やら仕様のテストについても言及があってしかるべしだとおもうんだが
今更だが。
>>245 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 17:56:40
>>半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ
スペースが入ってるほうが見やすいだろ？
Java 標準 API ドキュメント日本語版や Eclipse 言語パック適用後みたいにな。
それとも、こいつらも珍しいから直してもらうか w
>>349 いや、キミを判別しやすくて便利だから構わんのだけど。
>んなもん、ＯＯＰになってから諦めてますよ
俺的にはOOPになってから、スキルの低い人が書いたソースは
前(構造化設計)より酷くなったけど、スキルが高い人が書いたソースは
前と比較にならないくらい読みやすくなったと思う。
クラス図を見ればどの実装がどこにあって、それぞれの責任範囲が見えてくるから。
ヘボが書いたソースは不可思議なところにメソッドが実装されていて
ソースを追うのが困難。スキルはそこそこだけどオブジェクト指向に慣れていない技術者は
画面または機能ごとにクラスを作っていて、「これじゃC言語を構造化設計で
ソースファイル分割していたのと大して変わらんなあ」というのが多い。
要するに、クラス図があればオッケーってわけで、
なければやっぱりトレースしにくいと思う。
ソースだけで一番追いやすいのは、最後の
「スキルそこそこオブ不慣れ」のソース。
勿論良い悪いは別ですよ。
きちんとドキュメントは残しましょうって事ですかね。
ああそうか、diconファイルが上手いこと
ドキュメントになりゃいいのか。
354 ：
デフォルトの名無しさん：04/10/06 18:48:42
そりゃそうだ。
DIベースのプログラミングの従来型からの違いはそこにあるわけだし。
>ソースだけで一番追いやすいのは、最後の
>「スキルそこそこオブ不慣れ」のソース。
それは確かにそうかも。
diconからドキュメントにするのはどうかなあ。シーケンス図をかかないと
そのインターフェースで必要十分なのかどうか判断しづらいと思う。
実装に入ってからレビューすると修正作業が多くなるので、やっぱり
あらかじめクラス図とシーケンス図を元にPLがちゃんとレビューして、
修正が終わってから実装に入った方がトータルでは楽じゃない？
まあくーすとは路線が違うのかもしれんが。
DIコンテナのBean定義ファイルは、オブジェクトの関連図になるよね。
コラボレーション図になるのかな。
>>355 そうだよなー。だから開発プロセスについて
あーだこーだ盛り上がるわけだ。
オブジェクト指向のおかげで（せいで？）
ゴリゴリ書いて動けばおしまいってのじゃ
済まなくなったと。
くーす本、楽しみです。
実業務に則して、要件定義から見積もり提示とか
そういうのまで含めてくれるととても嬉しい。
あー、見積りは嬉しいかも
くーすは、要件定義がインプットになるから、要件定義とか見積りとかは無い。
くーすでなくてもいいから、見積りは欲しい。
結論：EJB3.0 >>> Spring >>>>> S2
EJB3.0が本当に良いならS2EJBが出るような気もするがな
SpringならGeronimo::Springがすでにあるけどね。
プロジェクトだけ。
>360
比較できるほど三つとも使い込んでいるのか。
どこでどう差がつくのか是非教えて欲しい。
>360
リリースされてないしさ。まだまだ仕様は変わっていくので
比較は出来ないでしょ。
是非
>>360にEJBとJDOの統合による将来像というのを教えてもらいたい
ひがさんがここを見てるかもしれないんですよね？
ってことはこの板で一番要望が高いS2JSFで「こんなんほしい！」ってのを
書き込むと良いんではないでしょうか？＞ほしがってる方々
はぶ氏が作ったサイトにアクセスしてみたけど、かなり頻繁にMySQLのエラーを吐くな。
もちっと余裕があるサイトに引っ越したほうがいいような。
368 ：
デフォルトの名無しさん：04/10/06 23:48:29
ロジックとデータの分離って、やりにくくね？
>>366 自分でひが氏のブログにコメントしろ！
ちゃんと返事来るぞ。
>>368 やりにくい部分もあるけど、やれる部分のほうが多くない？
371 ：
330：04/10/07 00:25:56
みんな朝からありがﾄﾝ
提案目的は、S2が使えるシチュエーションと注意事項を確認したい、ということね。
330で提示した中で、
(2)と(3)を聞いた意味は、自然なモデリングを変に崩すことになったり、制約が変な方に
働いて妙なものができてこないか
(4)は、書き方がまずかったが、DIパターンの目的である「依存関係のreasonableな分離」
を実現するためにS2は適切なのか
(5)は、importが云々という話の他に、例えば、「コンポーネントはsingleton、状態はク
ライアントが持つ」という考え方に染まったコードになり、理解者（というより共感者？）
以外は気持ち悪い思いをするよね？ということ。
個人的に気になるのは、作成するソフトウェアの複雑性を緩和するブレイクスルーがない
ように見えることなんだよな。
例えば、状態はクライアントに持たせ、コンポーネントはステートレスという思想という
か制約。データとロジックを分離させる方が有効なケースがあるのはわかる。コンポーネ
ントを作りやすくなるケースがあるのもOK（小規模な場合しか想像できないが）。
ただ、一般的には複雑性が増すわけで、適用箇所次第では、複雑性のしわ寄せがクライア
ント側にくるだろうし、コンポーネントも組みにくくなる。
さらに、346が言うように、思想を理解させなければ、こうやって組まれた構成の第三者
の理解およびメンテナンスが困難だ。
というわけで、ぶっちゃけた話、ある程度大きなアプリの適用例とメイキングオブが知り
たいわけだが。これは身をもって体験するのが一番か？
S2に限らず、J2EEのメリットが出るような規模のサンプルって、ほとんど表に出てこない
しね。抽象的か、短すぎる事例報告だけ。というわけで、もーちょっと様子見かな。
372 ：
デフォルトの名無しさん：04/10/07 00:27:23
>>370 「構造体と関数」って感じで慣れないな。
どうしてもドメインモデルで考えてしまうYO。
ロジックをビジネスロジックとビジネスルールに分けて、
ルールの方はドメインオブジェクトに記述するのはどうだろ。
問題はS2DAOでとってきたEntityに他との関連をインジェクト
しないといけないとこだな。
373 ：
330：04/10/07 00:27:49
あ、ソースコードトレースがしにくいってのは、メタデータ使う
フレームワーク全般に言える事ね。オブジェクト指向レベル
どうこうというよりは、頭の中の回路を頻繁に切り替えるのが
おっくう。該当箇所探索もフレームワークのメタデータ特有の
探索方法に特化した知識や支援手段が必要になるのがウザイ。
だいたい、インピーダンスミスマッチがないレイヤーで、
別言語(?)によるコンフィギュレーション使う必然性って
あるんかいな。
テスターは再ビルド権限がないとか、SIerには再ビルド許さん
けど自由度は与えたいとか、そういう運用的理由なら、
わからんでもないが。
というわけで、DIコン使うならPico/HiveMind派（しょーもない着眼点だな、おい）。
374 ：
デフォルトの名無しさん：04/10/07 00:33:41
・言葉がダサイ
「ダイコン」「くーす」「から騒ぎ」ちょと恥ずかしい。
・オタくさい
から騒ぎの後、アニソンカラオケ大会。きしょい。
375 ：
デフォルトの名無しさん：04/10/07 00:48:22
Web層 フレームワーク固有のオブジェクト
↑
DTO
↓
ビジネスロジック層 DTO or ドメインオブジェクト
↑
ドメインオブジェクト
↓
ビジネスルール層 ドメインオブジェクト
↑
ドメインオブジェクト
↓
データアクセス層
こんな感じか。
376 ：
デフォルトの名無しさん：04/10/07 00:51:41
戻り値にDIするインターセプタかな。
>372
スマン、ここでのビジネスルールの粒度がイマイチ判らなかった。
揚げ足取りじゃないんだけど、ビジネスって曖昧な伝わり方もするんで、
例えばで良いんで教えて貰えますか？
PicoもHiveMindもよく知らないんだけど、どんな手順でDIするのかな？
>373
S2と関係無くメタデータと上手く付きあわないかんのもしゃあないでしょう。
ひょっとすると、今後は基本設計レベルではメタデータ定義するだけってな
思想になるかもしれんし。実装のソースコード書く人と完全分業みたいなことにも。
>374
ベタベタなほうが伝わりやすいってのもあるしさ。
あ、あとブログ読むと、アニオタ臭いのはコミュニティのごくごく一部な気もする。
ちなみに、から騒ぎ→からさわぎ、な。
378 ：
デフォルトの名無しさん：04/10/07 01:33:48
>>377 思いつきなんで、はっきりとはしてないんだけど、例えば
・計算フィールドの導出
単純な計算ですむ場合もあるし、導出にStrategyパターンを使う場合もある。
・他エンティティとの関連
User.isMemberOf(Group)みたいなメソッドが欲しい。
ロジック層でisMember(Group, User)ってなるとヤだなって思う。
ビジネスロジックをアクティビティ図で表すとき、それぞれのアクティビティ状態
をルールって呼ぶような感じかな。
>>371 ソフトウェアの複雑性というのは、結局かわらないんじゃないかと思う。
単純に言えば、作るものが決まると、そのプロダクトのエントロピーの下限というのが決まるんではないかと。
そして、管理のしやすいソフトウェアというのは、エントロピーが低いソフトウェアだといえると思う。
フレームワークを使うというのは、エントロピーをフレームワークに押し付けて、コア部分のエントロピーを下げることになる。
ライブラリというのも、エントロピーをプロジェクトの外に追いやる手段だね。
あと、JavaのコードはBean定義ファイルに比べて情報量が多いから、コードを書かかずにBean定義を書くということはエントロピーを下げることにつながる。
そうやって、プロジェクトが管理する成果物のエントロピーを低い状態に保つというのが、すごくざっくり見たDI+AOPの効果ではないかな。
そういう意味では、無限の可能性をもつJavaコードを書く変わりに、数限られたXMLタグで同じことを実現する仕組みであれば、なんでもエントロピーが下げれていいんだよね。
XMLタグの表現力が上がると、それぞれのタグの情報量があがっていくから、またどこかにエントロピーを追いやる必要が出てくるわけだけど。
それを推し進めると、浅見たん提唱のXMLによる伝票指向アーキティクチャになるのか。
記述の選択肢が少ない、というのが肝ね。
S2はマンセーだけどくーすは疑問
DI（IoC）に関しては >380の言うエントロピーの軽減が目的ってことでFA。
どのコンテナがいいか。
SpringやPicoと比べると、設定の手軽さと機能の豊富さでS2が一番だと思う。
欲しい機能があったとき、Rod Johnsonにメール出すより、ひがさんのblog
にコメントする方が敷居が低いし、レスポンスも速い。
Springはクドい。
くーすは、今公開されているサンプルやトライアル程度では、実際のプロジェクト
になったときに上手くいくか判断しかねる。
本を執筆中ということだけど、付録CDに実装までのサンプルでもあればいいのだが。
今までの開発手法（ユースケース駆動とか）も、本では上手く言ってるけど、
実際大変じゃんってことで、くーすを考案中なんだし、くーすも同じ轍を踏まない
とも限らんすね。
おれはDIコンテナってのは、ファクトリを自前でがりがり書く代わりにコンテナに
お願いできる（ファクトリ機能の外出し）ってことで理解してる。
それ以外の部分（Hibernate連携とか）はあくまでオプションだと思ってる。
くーすはよくわからん。資料がたりん....
くーすの内容をみずにレス
よくある開発手法は、一般的にやろうとしてたり、実装と独立しようとしてて、使えなくなってると思われ。
くーすの場合は、業務システムをSeasar使って作るという具合に、用途を限定しているから、変に一般化しようとしなければ問題ないんじゃなかろうか。
>>385 資料っていうか、資料へのリンクがない気がする。
たぶん、探せば資料はきっとある。
くーすは特にSeasar2に限定されるものではなかったような。
限定じゃなくて、前提だね。
ごめん、はてなの解説を「Diconを使ったときの・・・」と読み取ってしまってた。
あのへんのブログをぐるぐる回ったけど、くーす自体にはたどり着けなかった。
もうこういうの飽きた
っていうか、くーすってどこにあるの？
392 ：
371：04/10/07 03:10:42
>>380 大筋で同意。うまく言葉にできなかったことを、シンプルな言葉でまとめてくれてありがと。
オブジェクト指向はデータとアルゴリズムをバインドさせることで、エントロピーを低減させた
と考えることができるが（C++普及前夜に、関数ポインタを構造体に持たせたコードが増えたのが
なつかしいな）、そういう視点でのブレイクスルーがあるの？ということを
言いたかった。
自由度が小さい記述方法を使うことで局所的なエントロピーは下がると思うが、
全体的にはどうなんだろ。フレームワークと、その根底に流れる思想を理解するための
情報量の扱い、という意味で。
「くーす」という哲学を理解というか納得した者同士は、下げられるって
ことなんだろうな、たぶん。
393 ：
デフォルトの名無しさん：04/10/07 03:25:19
クレクレ君ばっかだね
397 ：
デフォルトの名無しさん：04/10/07 03:53:58
>>383 > 設定の手軽さと機能の豊富さでS2が一番だと思う。
設定の手軽さで一番、というのは理解できん。
XMLのvalidation考えると特に。
ある程度大きな、例えばconstractor injectionの
インスタンス数が100とか言い出すと、コストが逆転する
かもしれんけど（まぁそこまでいくとXMLも専用エディタ
使わんと苦しいな）。
フィーリングとしてどれくらい？＞リーズナブルな規模
機能の豊富さはXMLの表現力と等価なわけで、情報量が（略）。
相手が日本人だと楽、というのは同意。自分も含めて
技術者として情けないがな……。一時期、Xalanコミュニティ
とかに顔つっこんでみたことがあるけど、やっぱりスケール
の違いを感じた。ロシア人の英語はよめねー。
>>384 そうね。個人的にもそこがコアだと思う。
AOPはそれを効率よく実現するための手段という考え。
そもそも「FactoryやAFactoryはDIコンテナで代用
できます！」ってのは、DIがFactoryの一流派だけ
なんじゃないかと小一時間（略
しかし、こういうリフレクション全開のしくみが定着すると、いままで語られてた
「型安全性」だとか「コンパイルによる事前検証」のメリットってどうよ？と思わないでもない。
>>399 大いにそう思う。
いままでだと、型の安全性ってのは基本的にコンパイラが
あるていどの保証(とはいってもぴんきりだが)を
してくれていたわけだが、そういった部分に頼れないと
いうことだからね。
強い型付けはJavaのウリでもあるけども、オブジェクト指向的な利点を
徹底利用しにくいところもあったね。たとえばListnerを使ったコールバック的な
委譲モデルでも、おれはListnerインターフェイスをimplementsするんじゃなくて、
モデル側にMethodオブジェクトを渡してやるほうがなんぼかましじゃないかと
思ったりもするし。
たとえばThreadにRunnableオブジェクトを渡すんじゃなくて、実行して
ほしいMethodを渡して、Thread側ではinvoke()するとかのほうがもっとフレキシ
ブルなんじゃないかと。Runnableをimplementsする必要すらなくなるし。
こういう、型なんて関係ない、メソッドがあればいい、という使い方は本来、
オブジェクト指向ならではだったわけで。
DIコンテナの場合、利用側ではインターフェイスをもとにしたプログラミングを
行なうわけで、型安全性も十分保証できてると思うし。
キャストごりごりのコードになるよね？
>>401 C#のデリゲート、MSがJavaの仕様に入れようと提案したら
Sunに断られたそうで。
そうだな、DIコンテナ使うとキャストは増える。Object型返すしなあ。
たしかにそこでの型安全性は低くなってると思う。Cast例外って
実行時例外だったよなあ。
キャストは増えない。setter使えば勝手に入れてくれるから
最初の入り口さえどうにかすれば、あとは大丈夫という感じだね。
そういえば。
オブジェクトの遅延生成ができるともっといいね。
遅延というか、オンデマンド。
getXxx使ったときに生成されるような。
じゃないとイモヅル式にオブジェクトが生成されてしまう。
できるんだっけ？
>>405 いやコンテナ内のオブジェクトはいいんだよ。増えるところは
S2の例：
Hello hello = (Hello) container.getComponent(Hello.class);
この部分ね。まあ対した問題じゃないんだけどね。文法上
cast失敗を気にする必要もないだろうし。
使うとわかるけどcontainerの外でcontainerを使う方が珍しいと思う
409 ：
sage：04/10/07 20:27:27
まー依存性注入するところでcontainer使うんだから、
奇麗に設計できている場合はそうね。
インスタンスがいもづる式に生成されまくるという問題ってないの？
インスタンスはcontainerが保持しているから問題なし
そのメモリはどこから出てくるの？
413 ：
デフォルトの名無しさん：04/10/07 21:24:48
>>380はエントロピーって言葉に何か間違ったイメージを持ってるな
>410
基本はSingletonだ
ソフトウェアにおけるエントロピーの定義を教えてくれませんか？
>>414 そうすると、ソフトウェア中で必要なオブジェクトがすべて生成されてしまうことにならないかな。
>>413 その言葉のもつ本来の意味を知らず、また、知ろうともせず、
単に語感やニュアンスだけでカッコいい言葉を使ってみる、
というのはどこに行ってもありがちだけどね。
>>380の言わんとしていることは分かったけど。
>>415 ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
整理されてなく、どこになにがあるかわからないソフトウェアはエントロピーが高い。
Javaのコードは選択肢が多いから、一行の情報量が多い。
対して、SeasarやSpringなどのBean定義ファイルは選択肢が少ないので情報量が少ない。
また、規模の大きいソフトウェアも、行ごとの情報量が大きくなる。
系が閉じているときのエントロピーの総和は一定なので、どこかのエントロピーを下げようと思うとどこかにエントロピーを押し付ける必要がある。
整理してどこになにがあるか推測しやすい状態で、選択肢の少ないコーディング技術を使って、コード量を少なくすると、エントロピーが低くなる。
作成するソフトウェアのエントロピーを下げようと思えば、ライブラリやフレームワークを使うことのほかに、開発管理がある。
管理された成果物のエントロピーは低いけど、管理作業自体のエントロピーが高いから。
>>417,419
ありがとうございました。勉強になりました。
421 ：
デフォルトの名無しさん：04/10/07 22:58:07
くーすを実案件に適用した例ってあるのかな？
いまオフショア開発でやってるんじゃなかったっけ？
>>420 -log(p(x))っていうのが情報量ね。確率の対数。で、エントロピーは情報量の平均(期待値)
×確率の対数
○確率の逆数の対数
文法のルールが多いほどコードのエントロピーは低くなる。
だから、Javaのコードは型の緩い言語よりエントロピーが低くなるんだね。
そのかわり、文法を勉強するためのエントロピーが高くなる。
>>416 すべて生成したとしてもデータを持たないオブジェクトという前提ならそれほど問題ないのでは？
>416
ソフトウェア中で必要なすべてじゃなくて、DIContainerに登録されているものすべて。
prototypeとouterを除く。
なんでもかんでもDIContainerに登録するわけじゃないよ。
多分416が思ってるほど多くはない。
JFrameとかを登録する方針にしたら、えらいことなりそうだけど。
VBとかDelphiで起動時に全フォームクリエイトしておいて
使うときにはShow()するような感じ？
Delphiでちゃんとしたアプリ作るときはちゃんと生成・消滅を管理するけど(VBはシラネ)、
そう、そんな感じ。
JFrameはシングルトンにしなければいいのかな。
430 ：
デフォルトの名無しさん：04/10/08 03:27:40
＞ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
…ヲイヲイ…。
431 ：
デフォルトの名無しさん：04/10/08 03:43:00
JFrameをDIContainerに登録するなら、prototypeになるはずだから
問題なしだ。VB、Delphiは良く知らんが、一つだけインスタンスを
生成しておいて、必要な時はコピーを生成してShow()するようになる。
これくらい分からんような奴らが、「ドキュメントすくねえ」とか
「全然優しくねえ」とかほざいてるのであれば、ひが氏は気に留める
必要ない。ドキュメント整備した所で使えねーよ。
S2Daoの機能強化やS2JSFの方に注力して欲しい。
432 ：
デフォルトの名無しさん：04/10/08 05:12:15
前に羽生さんに粘着してた香具師がいたような。。。
ここにもいたりしてw
>>433 俺≠430だけど、こんな感じじゃない。
持ちうるデータのバリエーションの許容量⇒情報量
それの系全体(平均)⇒エントロピー
あるいは、バリエーションの許容量ではなく
絶対量そのものを指す人も多いかも。
どちらにせよ、Wikipediaのと違いはないと思う。
>>435 実は、情報量と書いてる部分も、エントロピーと書くべきだった気がする。
情報量っていうのは、たとえばJavaコードを1行取り出したときに
S2Container container = S2ContainerFactory.create(PATH);
だったときにどれだけ意外性があるか、という、それぞれの事象に対する量だからね。
>>431 こういう、足りない点を指摘するやつをバカにする方が、スレを荒らしてるわけだが。
こうやって評判落とすようなマネするのって、ヒガさんに実は恨みがあるから？
>>437 恨みはないかもしれないが
妬みややっかみを持っている
ヤシはいるんだろうな。
>>439 で、ひがさんを擁護するフリをして、Seasar2は敷居が高い、とか、欠点に対する指摘を受け付けない、とかそういう逆宣伝をしてるわけか。
>>440 羽生さんがいるところには常に粘着するわけか。
大変だな。羽生さんも追っかけもｗ
恨みを買ってもしょうがないようなところあるからな。
人の話を遮って自分だけ延々と喋るし。
たいていは人の話に耳を貸さないくせにそれは相手によるし。
嫌いなやつは多いだろう。
>>443 まあそういう話はスレ違いってことで。
呼び出しくらうよ。
>>443 何だオマエ知り合いなのか。
本人に直接言ってやれよｗ
直接言えないから粘着してるんだよｗ
それにしても、よく観察してるね。
448 ：
デフォルトの名無しさん：04/10/08 11:22:09
DIの利点って、分からん奴らにはメソッドの仕様だけ渡して、
その部分だけ他に影響を与えずに作らせることができるという
ことだと思います。
Rodの本なんかを読んだり、ソース調べたり、自分で試したり
できる人とできない人で、Seasarに関わる人は分化されるのです。
S２を作る人、使う人、使われる人の３種類になるのでしょう。
それぞれのスキルにあった役割を与える。これも優しさです。
使われる人は、他に問題を波及させずにとりあえず、与えられた
メソッドの実装を行えばよくなります。
使う人は、実装を外注しやすくなり、Springと比べてもテストや
設定が格段に楽になります。
その点の説明が公式サイトにないので（日記にはあるが）使われる人が
勘違いして、ちょっと調べれば分かることをここでゴチャゴチャ騒いで
いることでしょう。
ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。
449 ：
デフォルトの名無しさん：04/10/08 12:01:27
何だ羽生氏に話を聞いて欲しい奴が騒いでるだけなのか？
ひが氏もいい迷惑だな
>>448 ＞ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。
禿同
ひが氏にはどんどんS2を磨いていってもらいたい
とりあえず2.1期待ageだ
>>449 話をさえぎられて自分の出番を取られてしまった人じゃないの？
やられたらやりかえせｗ
>分からん奴らにはメソッドの仕様だけ渡して、
>その部分だけ他に影響を与えずに作らせることができるという
ちゃんと詳細設計ができてれば普通のOOPどころか構造化設計でもそうです。
ドキュメントがどうとかは(俺は言ってないけど)せっかく匿名で本音を吐いてくれてるのに
それを粘着呼ばわりする被害妄想は止めて欲しい
DIだと、影響を与えないための労力が少ない、ってことじゃね？
枠組みとして用意されているのでいろんなスキルの人がまざっても
平準化しやすい、という事なら納得できるけど。
というか詳細なインターフェース設計をしてからじゃないと実装始められないよ、
ということか。それはいいかも。でも実装し始めてから設計ミスを直すのが
めんどくさそうな肝汁
strutsがMVCモデルを強制してもActionにビジネスロジック書く奴がいて、
結局ちゃんとOOAしないとMVCのメリットがでない
↓
ちゃんとOOA出来る人がいたらstrutsの仕組み必要ない
(設定ファイルの手間が増えるし。taglibは便利だけど)
みたいな事にはならないのかな？全然Seasarの話じゃなくて申し訳ないが
DIというか、クラス名やらメソッド名を外部設定ファイルに埋め込むと、リファクタリング機能が効かないから不便かも。
strutsのMVCはアプリケーション全体でいえばVの中のローカルなMVCだからしかたないね。
>>448 >使う人は、実装を外注しやすくなり、Springと比べてもテストや
>設定が格段に楽になります。
まじ参考までに教えて欲しいんですけど、Seaser2がSpringと比べて
テストや設定がしやすい部分ってどういうところなんでしょうか？
SpringとSeasar2の比較をいろいろ探したんですが、どれもいまいち
ピンと来ないもので。
>>452 人をうんこ呼ばわりしてあげつらったヤシが
いるんだから被害妄想もある程度仕方ない
と漏れは思う。ひが氏の日記が大人しくなって
しまったのが個人的には残念だ。
459 ：
デフォルトの名無しさん：04/10/08 21:39:32
外注というと書かれるコードの中身は汚くてもいいという印象があってよくない
461 ：
デフォルトの名無しさん：04/10/08 23:06:46
外注はよくないけど、とりあえずS2について言うと、
欲しい機能を（Javaでやるという前提であるならば）考えられうる限りできるだけシンプルに実装できるもので
割と好印象。
462 ：
デフォルトの名無しさん：04/10/08 23:10:56
少なくともJ2EEを作った香具師より頭いいのは確かだ
先にinterfaceありきと考えると
仮にコードが汚くてもUnitテストさえ
クリアしていれば安心が得られると
いう利点があるかなと思うけどどうかな？
464 ：
デフォルトの名無しさん：04/10/08 23:18:59
>>463 テストをするのは当然で
汚いのはリファクタリングの原則に反するのでよくない
もちろんそうなんだけど
外注に出して汚いコード
だったとしてもまだ安心度が
保てるように思うんだが
466 ：
デフォルトの名無しさん：04/10/08 23:27:35
設計は変わるもんだ。外注にやるとプログラマからのフィードバックが得られない。
S2は外注向けと考えるならそれは間違い。もともとソフトウェア開発はそういうものじゃない。
ほんとはみんなデスマが好きなのさ。
どっぷりとデスマに浸かることで、
自分は仕事をしているんだ！
という満足感が得られるからなのさ。
さらに、デスマを解消したり
回避する方法を考えるのは
もっと好きなのさ。
なんでかというと、
自分はこんなすごいことをやったんだ！
という優越感が得られるからなのさ。
Seasarってのはそうやって生まれたの。
外注に出さないプロジェクトって、小さなプロジェクトか小さな会社くらいでは？
>464
汚いのはリファクタリングの原則に反する、ってのはどういう意味？
リファクタリングの対象になる、ならわかるけど。
ついでにいうとユニットテスト通ってるならリファクタリングも気楽にできるね。
>>468 S2の話とはもう違うだろ。
外注に出すところのコスト構造って本当に酷いよ。
DI 使うとデバッガ使えないの？ テストうんぬんではなく、
ステップ実行とかできないの？
>>467 おかげでデスマにならずに済むなら漏れはありがたい。
>>471 S2のコードも全部放り込んでおけばいいんじゃない？
473 ：
デフォルトの名無しさん：04/10/09 01:51:38
>>472 デスマはなくならないよ。
まず
>>467でいう満足感と優越感がなくなっちゃうからね。
それに、新たな方法論を導入して解決するのは
「今までのステージにおけるデスマ」であり、
「次のステージにおけるデスマ」が控えているんだよ。
デスマあってのSeasarであり、
デスマある限りSeasatは進化し続け、
そしていつまで立ってもデスマはなくならない。
しかし、これがみんなの幸せにつながる。
＞デスマあってのSeasarであり、
( ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
(；ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
_, ._
（；ﾟ Дﾟ） …?!
'`,､'`,､('∀`) '`,､'`,､
475 ：
デフォルトの名無しさん：04/10/09 02:58:52
>> 457
設定ファイルやテストコードを書くためのタイプ量がS2の方が少ない。
DIを使うと、これらの煩雑さが問題となってくる。
>471
DIは問題ない。初期化より後は普通だから。
でもAOPを使うとデバッガで追えない。
バイトコードいじってるやつ全般に言えることだけどね。
>>476 AOPを使っても追えるよ。
意味不明なクラスに行くけどそこもトレース実行すればその後は問題なかった。
>>476 デバッガで追えないのは、AspectJ。
S2は普通に追える。
>>462 J2EEっていうかEJB？
後だしじゃんけんだからなぁ。
DynamicProxyのおかげの部分もあるし。
>>479 S2はDynamicProxyは使ってないけどね。
cglibでバイトコードいじっているから同じようなものだけど。
・・・そうなんだね。
cglibのページの「Open source projects use cglib」に載ってないのが寂しいけど。
バイトコード操作してる地点で実案件に使えるのかなぁ。。
とても使わせてもらえなそうだが。。
オイオイ、どういう判断基準なんだ？
といことはcglib使ってるモノはすべてだめなんだね。
HibernateとかSpringとかも。
>>483 コンテナ部分は使ってないぞ。Spring。readme.txtに書いてある。
なので、AOPやDAO機能を捨てれば非バイトコード操作なDIコンテナとしては使える。
あと、PicoContainerも非バイトコード操作なDIコンテナだよね。
>>482 なので、あくまでもDIコンテナが使いたいならS2以外の選択もある。
AOPを利用したい時にはS2のほうが簡単だと思うけどね。
AOPなければ、意味がかなり減るんだけども。
SpringのAOP定義はめっさめんどり。
>>403 偉いなMS。蚊帳の外でもコミットしようとするなんて。
これだけ見るとSUNだめだな。
空のインプリメソッドがゴミのようにある俺のソース…。何とかしてくれ。
いろいろ考えたんだけどさ、EJBとかDIコンテナとか
やっぱりなんかくだらない気がしてきた。
アプリケーション毎に必要な機能って違うじゃんか。
（負荷分散・クラスタリング・動的再配置・トランザクション・必要になるパフォーマンス、とかいろいろ）
シンプルな実装をアプリケーション毎に作ったほうが、ムリヤリ共通して使える実装を探さなくてもいい。
シンプルに構造を分割する考え方（～層、とかいろいろ）の話を延々としているほうがいいと思うよ。
実装はアプリケーション毎に行こう。
>>487 それはアプリ毎に必要な機能じゃなくシステムの構成・設定。
487の言う「いろいろ」こそ共通して使える実装部分じゃろ。
>>330 > ところで、S2が正しくinjectionしてくれるかどうかの
> テストはどう書けば？（汗）
キジムナ使へば下に出るぞ。singletonだけかもしれんが。
それをキャプチャしたのをテスト結果とすると良いかも。
>>399 >>400 キジムナ使え。事前検証バリバリだぞ。
>>作者
コード補完機能ｷﾎﾞｿ
>>487 だから、アプリケーションごとに違う非機能要件をAOPを
使って処理するんじゃん。
>>486 俺もMSの態度は偉いと思う。
片思いなのがこれまた哀愁がただよってて
ヘンに共感してみたり。いやそりゃヨタだけども。
でもコーディング量が増えても
インターフェイスという考え方で統一したいって
気持ちもちょっと判るんだよねー。
>>490 トランザクションの基盤なんて単純なものならほんの数行のコードで実装できるし、
動的再配置するためのライブラリ（ちょっとしたネームサービス）あればいい
クラスタリングや負荷分散となると、それはアプリケーション毎にかなり違うもんだと思う
あんまり仰々しいフレームワークを用意されても、結局複雑にしてしまうだけではなかろうか
>>487 そんなこといったらJDBCもいらんってことにならんか？
何を持ってシンプルな実装というかだな。
>>494 ぎょうぎょうしいフレームワークって何。
S2はシンプルだと思うけど。
POJOが基本で、コアはDIとAOPの機能だけ。
コア以外の機能もいろいろあるけど、
使えるものは使えばいいし、無理に使わず自前で実装しても良い。
ただ、クラスタリングや負荷分散を自前で実装するやつは、
よっぽどのツワモノだと思う。
>>487 EJBはくだらないが、DIはくだらなくないよ。
アプリケーション毎に、というより、アプリケーション内で必要な機能をアプリケーション内で共通して使うためにDI+AOPが有効だと思われ。
>483
SpringもHibernateもDynamicProxyで代用できませんでしたっけ？
#フル機能使えなくてもさ
DIコンテナってテストが簡単とか、複雑じゃないとか利点ばっか挙げられてるが，
商用EJBコンテナが提供するような分散・スケールアウト手法は確立されているの？
>496
毎回毎回自分で実装できるような奴ならいらんのでしょ。
負荷分散・クラスタリング・動的再配置・トランザクションをシンプルな実装で
アプリケーションごとにバグ少なく作成できるような凄い人はうちの周りには
いないけどね。
>>499 負荷分散・クラスタリングって、パフォーマンスとの兼ね合いでいろいろ調整いるだろうから、
自分で実装っていうのが基本では。
それを補助く小さなライブラリ（タプルスペース扱うやつは便利だ）があれば満足。
>>500 スーパーな人発見。
釣りじゃないならすごいね。
そういうのは、アプリケーションサーバか負荷分散装置だとかに
任せるものだと思っていたよ。
まぁ、EJBとかに比べると仰々しくは無いのだけど、
Lightweightなプログラミング言語を使っているとどうしても大げさに感じてしまうのよね。
>>500 バイトコードいじくるものより、自分で組んだ負荷分散やらクラスタリングのほうがあてにならんなぁ。
トランザクションも、基盤は数行でも、いろいろなところに埋め込まれて、そっちの方があてにならんなぁ。
Lightweightなプログラム言語使ってる人って、ライブラリやフレームワークを勉強して数行でまとめて書けるコードを、頭使わず勉強せず数十行あっちこっちに書くほうが手軽だと思いがちだよねぇ。
スケールアウト、負荷分散いらないんじゃそもそもEJB使ってねえぞ。
これらの機能提供しないのに，EJBの代替物と歌われてもねぇ、、、
507 ：
デフォルトの名無しさん：04/10/10 13:33:55
>>505 作っているものによると思うけどね。
一体どういうものを想定している？
HTML文章返すだけのウェブサーバとネットワークゲームのサーバではそりゃ負荷分散の手法は違ってくる
基本的に業務システム以外は対象外だからねぇ。
というか、ネットワークゲームのサーバーでEJBがどうのこうのいうほうが間違ってる。
>>509 そこはそれ、アプリ層のインプリだけ構造を統一するためにEJBの
スタイルを借りて、サーバー部分は最適化したものを自作、デスよ。
…ほんまかいな。
ネ申？
自ｲ乍ﾈ申
513 ：
デフォルトの名無しさん：04/10/10 14:48:56
どの層で分散がいるかなんて、これはアプリケーション毎に違うでしょ？
どでかいコールセンターで検索したい人が多いなら単にデータベースを大量に水平に並べればよい。
核爆発シミュレーション計算の分散も基本的にはコンピュータ並べるが、自作率は後者のほうが多くなるだろうな。
>506
EJBの代替物とは謳ってないんじゃない？
J2EEの機能を使いやすくする、でしょ。
J2EE=EJBだと思ってるなら間違い。
ついでに言うとまだ発展途上なのに「全部無いなら使わん」とかいうならご自由に。
使いたいとこ、使えるとこだけ使えばいいんだ。
あとは自作なり他製品と組み合わせるなり。
語尾に「なり」をつけるやつは嫌いだ。
>>513 とりあえず対象となってない分野をもってきて、使えないとかわめくのって、悲しいね。
>>506 いつからEJBの主目的が負荷分散になったんだ？
EJBの代替物にもなってないしねぇ。
いや、当初から主要な目的の一つではあったが…。
負荷分散しないのにEJB使っても今ひとつ甘みが無い。
520 ：
デフォルトの名無しさん：04/10/10 15:16:25
>>516 クラスタリング・負荷分散に共通して使える対象なんてありえないってことを示す例
業務システムに絞れば、共通して使えるしくみはあるんだけども。
で、とりあえずS2が話題にしてるのは業務システムなんだけども。
S2に限らずDIな連中が言ってるのは
EJBを使うのは大袈裟なシステムが
世の中には多いんだから別の手を
使おうぜってことでしょ。EJBが必要な
人はそっちを選べばいい。
まずは軽快なJavaを読めということでFAだな
それは負荷分散をしないって手？
負荷分散なんて、DBやアプリケーションサーバーにまかせればいいから、プログラムでは考えなくていい。
いくつかの注意点はあるけども。
APサーバに任せるメジャーな手段が、EJ(r
つか、なんかどーでもよいことに話がいってない？
負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。
（てか、んなことまでサポートしだしたらLightweightなコンテナじゃなくなるじゃん）
もう少しS2自体の話があるとうれしいのだけど。
>>520 フレームワーク外の作りこみ一切禁止なんて縛りがあるわけでもないのに、
なぜそこで完璧を目指す必要があるのか理解できない。
パレート原則で言う8割の側を押さえるだけで十分では?
しってる難しそうな言葉をならべて賢くなった気になる遊びですた。
>>529 理解できない会話に無理に加わる必要はないよ、坊や。
2chだな～
>>527 > 負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。
だってDIコンテナの作者らがEJBｲﾗﾈって言ってんだもん。
533 ：
デフォルトの名無しさん：04/10/11 02:28:34
J2EEを使った業務システムで、そこまで必要なシステムって多くないし
その程度のシステムでEJBはイラナイだろ。
>532
DIコンテナの長所挙げるとき散々*EJB*と比較して、
難しいとか、テストが大変とかEJBの短点ばかり挙げるのにな（ｗ
535 ：
デフォルトの名無しさん：04/10/11 04:37:42
遡ると、なぜJavaを選択するのかという話にならないか
短いコードで表現力の高いプラットフォームなら他にあるだろうに
>>532 負荷分散やクラスタリングは、ロードバランサや
HttpSessionでやった方が良い。
EJBでやるよりよっぽど実績がある。
537 ：
デフォルトの名無しさん：04/10/11 07:38:11
>>536 HTTPって、それは単にウェブサーバの負荷を分散ではなかろうか。
素人なんだけど、業務アプリの場合、データベースのバックアップも兼ねた
クラスタリングが重要になるのでは？
>>537 業務ロジックは、Servletコンテナと同一VMで動かすのが
パフォーマンス的には良い。
スケーラビリティがなんて言うやついるけど、
業務ロジックよりもWebの部分が先にボトルネックになる
ケースの方が多い。
データベースへの接続も負荷分散装置使えるよ。
EJBコンテナで負荷分散やクラスタリングしているシステムなんて
ほとんど見たことないけど。
540 ：
デフォルトの名無しさん：04/10/11 09:05:44
>>539 いや、しかし、世間的にはどうか知らんが、
漏れの経験では業務アプリでウェブベースなほうがむしろ稀だった。
ウェブベースなのは補助的な用途の場合が多い。
そういうときって、やはりクラスタ機能ある常駐プログラム
作る必要あるわけで、それはJavaで作るならばejbかdiコンテナか選択するんだろうな。
業務アプリに必要なのって、サービスを管理するライブラリだよね。
インストールはコマンド一発。
DHCPでIP振られたら自動的にデータベース起動して、アプリサーバ起動して、
クライアント探して・・・ っていうのを自動でできるようにしなきゃいけない。
（でないと導入コスト高いんだ）
>>540 S2の用途は539の言うとおりだと思う。
S2が自分の用途に向かないなら他を探すのが良いと思う。
今のトレンドはStatelessだよな。EJBを使うにしてもだよ。
ということは負荷分散をEJBコンテナがやらなければならない
ケースは少ないといえるんじゃないのか。しかもHTTPだろ。
俺ならロードバランサを前に挟むけどな。
>>537 そういう場合は、DBの機能を使うよ普通。
OracleならRACとかな。EJB使うほうが当てにならん。
>>532 実際要らないシステムが多いだろ。デプロイが楽だからWeb使うだけで
大したトランザクション量じゃないシステムも多いよ。
>>534 そりゃそうだろ。DI自体がEJBに対するアンチテーゼだからな。
インコンテナのテストなんて面倒だろうに。
当のEJBだってPOJOに方向転換じゃないか。
EJB*だけ*がスケーラビリティ確保の手段だと本当に思ってるのか？
PHPで大規模やってる連中だっているだろ。そいつらが
どうやって負荷分散やフェールオーバを実現しているのかを見れば
EJBのレイヤーでなくてもやれることがいっぱいあるのはわかるだろ。
頭が固いか不勉強か単なる言いがかりかのどれかに見えちゃうぞ。
>>534 EJBの長所が負荷分散だというなら
それはEJBでなくても他に汎用的で
実績のある代替手段を使えばそれで
済むんだからEJBｲﾗﾈってことになるな。
EJBのテストが面倒なのは事実。
性能が出なくて変なテクニックばかり
横行するO/RマッピングもHibernateや
S2Daoのほうが便利で性能がいい。
EJB-QLなんて何の意味がある？
EJBの長所は何があるんだ？
DIがなくてもEJBにはウンザリしてるよ。
>>537 フェールオーバとロードバランスは別だよ。
でもってどっちもDIとかEJBとか関係なく
考えるべきものだから。クラスタリングは
EJBの専売特許ではない。
>540
「DIコンテナ」部分だけ使うなら、他を自作しても邪魔にはならないよ。
S2開発者が主軸に考えてるのがWebだってだけ。
周辺プロダクトはそれに合ったものからでてくるけど、別に必須ってわけじゃない。
業務機能と非業務機能を全部自作するにしても、DIコンテナで管理できると楽だ。
>>540 なんか、もっとすっきりできる気がするが・・・
diconファイルはシンプルだけど、それでもいろいろ書き間違える。
Kijimunaがないとやってられない。
Kijimunaってどれくらい使われてるんだろう。
SpringIDE(?)と比べるとどう?
>>550 「どれくらい使われているか」より「どれくらい使いやすいか」の方が大事
>>551 最新バージョンは使いやすいよ。
何が自動インジェクションされているかも分かるし、
コンポーネントの定義からソースにも飛べる。
553 ：
デフォルトの名無しさん：04/10/12 01:45:36
Strutsでページ遷移の単体テストにS2Struts使うと楽になりますかねぇ？
JBossで座絶したんだけどこれ結構使える？
ちょっとずつ始めれるので、挫折しにくいよ。
何に挫折したのかを書くと世話焼きが相手をしてくれるぞ
Servletで挫折したならそれはJBossのせいじゃないからな。
インストールで挫折しますた。
ダウンロードに挫折しますた。
はぶにっき、訳分からん。突然切れチョル。
日記だからっちゅうても、雑誌に「S2はblog駆動」とか書いてるん
だから、何について言ってるんかハッキリするか、非公開にするか
せんと。
自分、さんざん内向きにアピールしちょるやないけ。
ひが氏が２chの戯言にまで耳を貸して、開発やドキュメント整備に
尽力しとるのを、足ひっぱっとりゃせんか？
車やコンピュータや家電だけが産業と違うじゃろ。
ハードウェア屋がコスト削る部分なんざ、ソフトでいえばコンパイル部分よ。
ここがこれ以上ないぐらい最適化されとるんやし、全品オーダーメイド
で、掛かる費用ほぼ人件費な状態を、車と一緒に考えられんわい。
「客に向け」「この業界に先はない」っちゅうんは至極まっとうだと思うが。
ttp://d.hatena.ne.jp/habuakihiro/ メインフレーム時代からコストどれだけ下がったか。
562 ：
デフォルトの名無しさん：04/10/13 10:59:26
>>560 あれは基本的に経営側の人間であって開発側の人間ではないのよ。
だから、経営の視点で開発の人間を判断して、当人としては歯がゆい思いを感じているんだろう。
といって、偉そうなこと言う割にはべつに経営で成功しているわけではないあたり、
文句たれている相手と同じ程度の人間であることをさらしてしまってるのだが、
それに気付いていない無知の無知がちょっとイタい。
>> 562
人格はどうでもいい。
つうか、はぶ氏個人の評価はスレ違い。
「経営側に回れるだけレベルは上」と考えてるんだろう、ある意味間違ってないが
>>560 http://capsctrl.que.jp/kdmsnr/diary/20041012.html#p05 ここへのコメントの続きじゃないの？
ここの人、若いんだけど、いっつも歯に衣着せぬ物言いなんで
（あ、若いからか）、いっつも微笑ましく読んでたんだけど
さすがはぶたんですなー、容赦せんもん。
上記サイトの人、今会計の仕訳の勉強とかしてるみたいで、
そういう勉強中の人に「DOAなんて否定的な表現」うんぬん言われると、
むちゃくちゃ厚い債権債務帳票とか出したり、
やったらきっつくて頭の切れる、出禁とかすぐ口に出すお客さんと
仕事した事あるのかなあ、と思ってたので、
ちょっとだけ溜飲が下がったよ。
はぶたん徹底して「顧客」って言わないね。お客様、と言う。
ちょっと気持ち悪くは感じたけど、プロなんだなとは思った。
まあなんつーか、たまに余人に見えないモノが見えてるヒトではあらぁね、
ソレが天才だからなのかデムパ受信してるのかはむろん余人に分かろうハズは無く…
ナニが言いたいかつーともーすこし他人の目を意識して書いてくださいと
＞金持ちに寄生して搾取してるだけじゃん。狭い世界の中で偉そうにしてるだけですよ。
＞OOもDOAも構造化も全員そうだよ。コバンザメでしかないよ。世界中が腐ってる！
コメント化って空のコメントがあるだけなんだけど
なんか書いてあったの？
相変わらず個人ネタか。
でも、お客にとっちゃOO分析だろうがER分析だろうが
知った事ではないだろうってのは、
くーすのよってたつ所なのではないかなあと思った。
だから本がどんなんなるか楽しみな訳で。
前に、見積もりの提示の仕方についても盛り込んでくれたらなーって
ここに書いたんだけど、それも上記が理由。
> 方法論がエンジニアにとって癒しにしかなってないじゃん、って思うんですよ。そりゃね、
> みんな賢いからさ、そういう人間が集まって膝突き合わしてそういうやり取りしてれば、
> 自分だけじゃない、って思えるしそりゃ楽しいでしょう。
> 別にS2でなければならない、ってこともないんですよ。EJBでも構わない。
> PHPでもRubyでもいいんですよ。
> 幾ら優れたことをやっても、根本的に「で？」としかならない。自分が一顧客として金を
> 出すとしたら、って考えると、欲しいのはそんな裏方の話じゃないっしょ。
これまた正論だが、日記でよく言うね。だが、あんたが自分でも気づかないフリしてる
心境は 「確かに S2 は良いかもしれない。ひがが目立つのはうれしいが、俺のほうが
できる人間なのにが影に隠れてるのはくやしい。」 だろ。
だいたい、客に伝わらんのはあんたの営業能力不足だろ w
古い言葉で言えば「バカの壁」だな。規模が違う話して悪いが、例えば IBM の研究所の
人間でもあんたは 「方法論ばかり言ってないで少しは経営のことを考えろ」 って言うか？
類稀な経営手腕を持ってんだったら、開発者に対してやる気なくすこと言わずに
気持ちよく駒として動かすことに専念すれば？ くーすﾏﾝｾｰとか言ってやれば
ドーパミン全開で土木作業してくれるよ w
多少、建設的なネタを。ひが君 「cglib 遅せーから Javassist 使う」 とか言ってないで
直接 ASM 使えよ。まー、バイトコードライブラリ作者は使う側のスキルはアテにしてないと
思うけどな。
性能： ASM ＞ Javassist（初心者向け） ＞ cglib(初心者向けASMラッパー)
＞ BCEL ＞ SERP
日記への反応は日記に書けば？あっちでも匿名で書けるんでしょ？
もしくーすがOOAなのかER分析なのかしったこっちゃないというなら俺は興味ないな。
システムの狭い世界での話であっても、OOAと構造化には明らかな壁があるのに
OOPLを導入してもその壁をうまく越えられてない人が結構いる。
くーすでクラス図もなしにバウンダリを基準に設計する(と読めたけど違う?)ものなら
壁を越えられない人たち向けには良い指針になるかもしれない。
前に使ったある外注は顧客クラスがあるにもかかわらず、
パスワード変更クラスとメールアドレス変更クラスをつくりやがった。
OOAでの1クラスが、複数のバウンダリに登場するのでバウンダリ基準はいくないと思う。
あと顧客が納得できるモノは画面イメージだけっていうのには諸手を挙げて賛同するけど、
顧客が仕様変更したがるのも画面なわけで、「やっぱり確認画面をいれたい」みたいな
変更要望に強くするためには、その後ろにあるクラス設計がいかに業務にマッチしているかが
重要になってくると思うんだけどお前らはどう思い松か？
別にさあ、日記に何かいてようがいいじゃん。
少なくとも、ここでどうこういう話じゃない。
プロダクトやプロモーションに関わることなら別として。
また呼び出しくらうよ？
>>573 「くーすが知ったこっちゃない」んじゃなくて、
くーすは「お客さんはそんなこと知ったこっちゃない」って
前提で考えられてるんじゃないかなーって
思ったの。
後半の、「顧客が納得できるモノは画面イメージだけって
いうのには諸手を挙げて賛同するけど」と同じでっす。
ちょっと言葉足らずでしたかすんません。
>「お客さんはそんなこと知ったこっちゃない」って前提で
なるほど。そうかも
その他の部分はひが氏の日記を拾い読みした記憶から勝手に脳内保管して
書いているので、見当違いだったらごめん、っていうか指摘してくだちい
しかしみんないろんな日記よく読んでるねえ。
みんななんだかんだいってもS2が気になってしょうがないんだね。
>>577 まさにそのとおり。からさわぎいくどー。
579 ：
デフォルトの名無しさん：04/10/13 21:03:02
S2ってさ、ひがさん一人で開発してるんだよね？
開発者として、複数の人が参加して、互いにCheck&確認していった方が、
もっと、いい方向になると思うんだけどなぁ...
一人で開発してると...どうも、一人よがりになりそうで...
>>579 あれってオープンソースでやってて、独りで作っているわけじゃないでしょ？
S2Xxxって感じで他の人もやってたような…。
うちなーんちゅ記念ｶｷｺ
>> 580
コアな部分は全部１人でやってるよ。
S2Dao使うにはMySQLは不向きだな。
>>579 オープンソースの大半は最初はそんなもんじゃないの？使う人が増えて
パイが大きくなったらコントリビューターも増えるでしょ。
つかそうならないと増えないような
コアな部分はだいたいどんなプロダクトでもひとりでやってるもんじゃない？
コアとはいえ、全体からすれば一部分なんだし。
586 ：
デフォルトの名無しさん：04/10/14 06:56:40
>>573 > パスワード変更クラスとメールアドレス変更クラスをつくりやがった
これの何が悪いのか。
これが適切な場合だって（むしろそのほうが）多いだろ。
587 ：
デフォルトの名無しさん：04/10/14 06:57:10
顧客クラスにパスワード変更メソッド付けるなんてアフォとしか漏れには思えん
ケース倍ケースじゃん。
573のシチュエーションだと変に見えただけじゃないの？
顧客クラスというからには
cust.load();
cust.setPassword(pass);
cust.update();
とするだけで更新できるので、わざわざ別クラスつくる意味がまったくわからん。
顧客クラスにパスワードのバリデーションメソッドを追加するだけでいいのに。
わざわざパスワード変更用のクラスをつくってバリデーションと更新メソッドを
つくる意味を教えてくれないか？さらにメールアドレス変更クラスは
これにそっくりで、バリデーションの内容がちょっと違う(".@"が使える)のと
更新メソッドのsqlがちょびっと違うだけ。クラスの見通しも機能拡張への対応も
顧客クラスにまとめた方がはるかにいいじゃん。
是非俺にも納得できるように説明して欲しい
誰でも自由にクラスを作れて、
どんなクラスでもDBに自由にアクセスできて、
DBが間違いなく更新される以上なにも問題が起きない、
という無法状態を放置しているのがそもそもの間違い。
>>589 データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないかという考えもあるんですよ。
エンティティは純粋にデータとしてとらえる。
意味がないわけではないと思いますよ。
ただそれもシステム全体の規模やルールとの兼ね合いも
あると思うので、杓子定規に当てはめるのもなあとも思う。
この場合は、印象のみだけど、ちょっと煩雑かなー。
>無法状態を放置しているのがそもそもの間違い。
まあそりゃそうなんだが。
>データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないか
ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
daoCustomer.setData(this);
dao.update(connection);
みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
使えば楽になるのかなあと思って興味を持ってるわけだけど。
で、パスワード変更やメールアドレス変更のために別クラスをつくって
似たような処理をいろんなクラスに書きまくった方が良いケースってのは
どんな場合よ？画面単位なので名前・住所・電話番号等の変更クラスは
一つにまとまってるんだろうけど。
「これらの画面を一つにまとめたい」とか「メールアドレスに対して
パスワードを送付する機能をつけたい」とかの仕様変更に対応するには
顧客クラスが汎用的に(といってもこのシステム内で、だけど)顧客情報を
管理できるクラスであることが重要じゃない？顧客検索みたいに顧客クラスの
インスタンスを複数扱う機能には、別に顧客検索クラスをつくるけどさ。
>>592 顧客情報と認証情報を別個に分けて管理したい時。
セキュリティのためにね。
>メールアドレスに対してパスワードを送付する機能をつけたい
顧客が希望しても、こういう仕様は止めろよ・・・
>顧客情報と認証情報を別個に分けて管理したい時
そのために内部の実装を分けないといけないようなケースがそんなにあるの？
>>メールアドレスに対してパスワードを送付する機能をつけたい
>顧客が希望しても、こういう仕様は止めろよ・・・
誰でもすぐ会員登録できる情報サイトなんかではこれでいいと思う。
つーか話題とずれてるけど
>>592 >ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
>daoCustomer.setData(this);
>dao.update(connection);
>みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
>渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
>使えば楽になるのかなあと思って興味を持ってるわけだけど。
S2Dao使うと、dao.update(customer);で済む。
複数のdaoでconnectionを共有するなんてのは、まさにDIの使いどころ。
>>591 データと振る舞いを分離するって、Customerクラスと
CustomerLogicクラスに完全に分かれるってこと？
>596
で、CustomerLogic を具体的な業務ロジッククラスから呼び出して使えばいいのか。
白黒あいまいな感じで作りやすいかもしれない。
OOしてると、後だしででてきた要件の扱いに悶々と悩むことあるから。
下手するとDRY原則やぶりなコードができそうだな。
さらにS2Dao使うと、SQLの中にロジック散らばりそうだし。
データとロジック分けるメリットって？
>>599 メリットは597が言ってる。
でもそのメリットも、システム規模、それとクラスを分けた事による利用性や
他の利便性（DIのアーキテクチャにのりやすいとか他いろいろ）と
応相談ってところじゃないかな。
なんでもかんでもOO的にエレガントだからって押し切ると
業務要件とか実装上の現実問題とかないがしろにしちゃう。
パターンはパターンで有用だけど皆頭使おうぜって所ですか。
S2やくーすが、その頭使おうぜって所を
何処まで軽減できるかってのが、楽しみなところじゃない？
ValueObjectに処理を持たせるという話をしてるの？
>599
OOだと、組み替えたり、整理したり、やっぱこの部分独立させよう、いやいやそこはそのままで、
としてるそばからお客さんに「やっぱりおしごとのやりかたかえますた」って言われてイヤ。
ロジックとデータは分けておいて、diconファイルとかで業務構造を動的に管理するために
計算資源を使ったほうが合理的かも。
業務構造って、えらくあいまいな言葉だな。
データストア層とドメインモデル層を分けて考えるなら、おのずとDAOが出てくるわけだが。
S2JSFまだぁ？
>> 603
ドメインモデル層をデータとロジックに分けてしまおうって言ってんじゃないの？
ファウラー氏の言う「ドメインモデル貧血症」に。
601ハ、ValueObjectノ意味ヲハキチガエテマス。
>603
設計方法論に詳しいわけじゃないんで、変なこと言ってたらすまん。
処理の方法がころころ変わるような場合の話で。
ビジネスルールをそのままソフトウェアにしちゃいたい。
静的な構造はうまい人が作らないと汚くなるし、
完成するとそれで世界が完結するから変更が大変。
だからソースコードで書く部分をビジネスルール層だけにしてしまう。
それをO/Rツールが自動化してくれるデータアクセス層に被せる。
データは「ビジネスルールが正しく実装された」ことをテストして保障。
うまくいけば楽にならないかなぁ。
>>607 ふつーうにS2の実装ってそんな感じじゃないの。
ビジネスルールがSQLに分散するんじゃね？
ビジネスルールって言葉が曖昧だよな
>>609 どーせ、SQLは山ほど書くんだから問題なし。
>>611 山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
SQLバリバリの人だったら、その辺問題ないのかなあ。
S2Ayaya を使えばあややのどこにinjectionできますか。
614 ：
デフォルトの名無しさん：04/10/16 04:55:10
もちろん大事なところでしょう。
メタについてはどうよ？
実物がないからなんとも言えんが、
実装者への負担増えない？
>614
RejectedRuntimeExceptionが発生します。
617 ：
デフォルトの名無しさん：04/10/16 21:29:13
>>591 >データと振る舞いをカプセル化するという方向は
>実は間違いなんじゃないかという考えもあるんですよ。
>エンティティは純粋にデータとしてとらえる。
>意味がないわけではないと思いますよ。
やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。
おまいら、以下を読んで目を覚ましてくれ。
----
ドメインモデル貧血症
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel このアンチパターンが根本的に怖いのは、オブジェクト指向設計の
基本概念（データと処理を一緒にする）の真逆だということです。
ドメインモデル貧血症とは、単なる手続き型設計のことなのです。
まさに、私（そしてEric）のようなオブジェクト信望者が、Smalltalkの
初期からずーーーーーっと戦ってきたもの、そのものなのです。
さらに困ったことに、貧血オブジェクト(Anemic Object) が本物の
オブジェクトだと思っているひとがたくさんいます。つまり、
オブジェクト指向設計が何たるかをまったく分かっていない
ということなんです。
----
そういう名前のアンチパターンがあるからといって、それが常に正しくないわけじゃないんだけどね。
>やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。
それは、一見ドメインモデルだけどそうではない、ってやつだろう。
591のは、もっと違う考えもあっていいんじゃないか、ってことで。
617は、世の中のソフトはすべて静的モデルで書くべきだ、という考えなのか。
構造化は一時期までかなーり成功を収めた手法だけれど、
OOってまだそこまで大成功は収めていない手法にも関わらず、
ここまで熱烈信者が増えてるのは何故だろう…？
591だけど、ドメインモデル貧血症の事は知ってます。
だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
別の流れも最近よく目にします、っていう意味ですよ。
世の中ファウラーの言う事だけが有用って訳ではないでしょう？
議論の余地があるみたいですね、って話です。
大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
ってだけなのは、ちょっとお寂しいですね。
まあそのページを読むとファウラーさんは結構面白い文章を書く
おちゃめさんぽいので、半分ネタといか煽りの気もしますけど。
で、俺の立場としては、所詮DOA育ちなんで
基本的に貧血症大好き、
ただしメンテナビリティなどの事情を鑑みて、
責務割り当てるのもまぁありかなって所です。
そもそもその貧血症だのなんだの、
純血種しか許さない態度が俺は好かん。
> OOってまだそこまで大成功は収めていない手法にも関わらず
ぽかーん。
まるで、親にメシ食わせてもらいながら「親なんて必要ない」とほざいてる中学生みたいだな。
623 ：
デフォルトの名無しさん：04/10/17 00:15:16
>>620 >OOってまだそこまで大成功は収めていない手法にも関わらず、
ΣΣ(ﾟдﾟlll)ｶﾞｶﾞｰﾝ!!
624 ：
617：04/10/17 00:30:58
>>621 > 591だけど、ドメインモデル貧血症の事は知ってます。
> だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
> 別の流れも最近よく目にします、っていう意味ですよ。
寡聞にして知らないのですけど、どのへんで見たのか教えていただけませんか?
> 大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
> ってだけなのは、ちょっとお寂しいですね。
いや、
ファ> ドメインモデル貧血症問題の本質は、ドメインモデルのベネフィットを何も得ず、
ファ> コストだけをすべて被ってしまうという点です。
とも仰ってます。
もちろん「ドメインモデルなんて使わないで TransactionScript一本」っていうプロジェクトであれば、
ドメインモデル貧血症に該当してもなんの問題もないとは思いますけど。
> そもそもその貧血症だのなんだの、
> 純血種しか許さない態度が俺は好かん。
これはそうですな。反省してます。
625 ：
617：04/10/17 00:39:55
>>612 >
>>611 > 山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
> SQLバリバリの人だったら、その辺問題ないのかなあ。
SQLバリバリだろうがなかろうが問題ありありだと思うよ。DRY原則に反してるわけだから。
# DRY原則は数あるソフトウェアの原則の中でも、最も尊ぶべき原則だと思うなぁ
DIともseasarとも関係ない話が続いてるけどなんか面白いな。
混ざってみよう。
これがすばり貧血症にあたるかわからないけど
tp://www.relaxer.org/process/sample/library/LibrarySystem1.1.1/LibrarySystem_s4.html
エンティティの管理クラスが軒並み外出しになってる。どう？
はぶ氏も日記で「エンティティはDBのテーブル」と位置づけてたと思った。
意図的な極論なのかも知れないが、態度は貧血に近いと思う。
あとファウラーさんも「これはずいぶん昔からあるアンチパターンのひとつですが、
今になって台頭してきているようです。」って書いてるくらいだから
やっぱり貧血派は増えてるんではないすかね。
でもそんな違いは誤差だとかってまた言われそうだ。
あ、そうか、エンティティがDBのテーブルって事なら
ファウラーの言う所の「コスト」はかかってないって事か。
それにDTOと所謂ドメインモデルを合わせた
バリュー・オブジェクトって事も言ってますね。
ああ恥ずかしい。
まあ、DI、Seasar、くーすの流れだから、関係なくはないかな。
業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
前提に、ICONIXやくーすってあると思う。
浅海氏のページ見たけど、要求分析から実装まで通して示してあって
いいね。とてもいい。
実装見ると、リファクタリングしたい（やっぱエンティティにもっとロジック
追加したい）って思うけど、上に書いた考えでいくと、酷い訳ではないし、
これっくらいが現実的なOOとのつきあい方かもしれん。
VB + OCXが割と正解だったってことかな。
626のサイト、とても勉強になりました。
ICONIXを基に、より包括的なプロセスになってる。
くーすは、ICONIXから無くしてもいいんじゃないかという部分を省いた、
軽いプロセスを目指してるんですね。ただ、常人には難しそう。
Relaxerプロセスを一通り実践して、カスタマイズしていくのが一番良さそうです。
Relaxer自体はどうだろう。自動生成のデータベースアクセスは重たそうだったけど。
完全にスレ違いになってしまいました。
最近は、ドメインモデリングより、振る舞いのモデリングに
シフトしつつあると思う。
ドメインモデルはER分析した結果を使う。
(Entityとテーブルはほとんど同じ)
画面は、欲しい形でDTOとして受け取る。
DTOなので振る舞いを持たない。
DTOとEntityの相互変換をおこなうのは、
コストがかかるので、業務ロジック層や
データアクセス層で直接DTOを処理する。
これがくーすの考え方なんだと思う。
それを支えているのがS2Daoで、ほとんどコストをかけずに
DTOを処理できるようになっている。
> DTOとEntityの相互変換をおこなうのは、
> コストがかかるので、業務ロジック層や
> データアクセス層で直接DTOを処理する。
これは大きな間違いだと考える。
そのコストはオプショナルなコストではなく、必須のコスト。
必須のコストを減らす目的で他のマッピングツールを作ったほうがいい。
(DTO <-> Entity(≒ドメインモデル) を相互変換するような)
>>632 必須であるわけは。
業務ロジックは、画面のためにあるんだから、
画面に適したDTOを扱うのは自然だと思うけど。
システムを層に分ける。
データストレージ―(1)―ビジネスロジック―(2)―プレゼンテーション
ここを流れるデータを分類する。
(1)は DTO<->ドメインモデル
(2)は ドメインモデル->View用モデル(左から右のみ)
ドメインモデルをDTOと同じ構造にすることができるのは、
データストレージ層を新規に設ける場合のみ。
DBスキーマを新規にゼロから構築するケースがどのくらいあるだろうか。
ほとんどないのが実情だ。
ドメインモデルとDTOを一緒にしたいという方向から考えると、上記モデルとは矛盾する。
俺は上記モデルから考えるからこそ、ドメインモデルとDTOは一致しないという立場にたつ。
実際、(1)と(2)で別クラス(実際には別インタフェース)を作ってから実装させたことがある。
DB操作、ビジネスロジック、プレゼンテーションを綺麗に作業分担させられたよ。
635 ：
デフォルトの名無しさん：04/10/17 11:44:16
>>628 > 業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
> 前提に、ICONIXやくーすってあると思う。
くーすはそうかもしらんが、ICONIXはそんなこと言ってないと思うんだが?
Use Case Driven Object Modeling with UML(ユースケース入門)で読んだ知識しかないんだけどさ。
>>634 ドメインモデルとDTOは、もともと一致するものじゃないと思うけど、
コストをかけても良いなら、
テーブル<->ドメインモデル<->View用のモデル(ViewHelper)
を相互変換しても良い。
きれいな設計というのはものすごくあいまいな言葉で、
自己満足にすぎない可能性もある。
内部スキーマ、概念スキーマ、外部スキーマの考え方は、
昔からあるけど、各スキーマの構造のミスマッチを解消するための
コストがかかるから、実際にはあまり使われていない。
まず前提。Domain ObjectとDTOの相互変換はめんどくさい。
FowlerのPofEAAのService Layerの説明のところに確か
「DTO変換のコストを過小評価するな。オブジェクトのツリーが
深くなるとすげー辛い」みたいなことが書いてあったはずだ
(いま本が手許にないので正確な表現はわからん)。
俺も「Presentation層のコントローラ(この時はStrutsのAction)は
Service Layerを介してDTOを受け取り、Domain Objectには絶対
直接触らない」ってポリシーで設計したけど結局実装とテストが
やたらしんどくなって方針転換したことがある。
んで、DTO変換をしないとなると、Domain Object側に巻き込むか、
DTO側に巻き込むかという二者択一となる。最近のひが氏は後者に
転んでいる模様。
#
ttp://d.hatena.ne.jp/higayasuo/20041010#1097399686 とか
ちなみに俺の上記のケースは細粒度のDomain Objectのトランザクション間
かつコントローラ間のロングキャッシュが非常に重要なドメインだったので
前者を選択したよ。
# ひが氏はロングキャッシュは知らんとか言ってるけど。
#
ttp://d.hatena.ne.jp/higayasuo/20040808#1091933710 >>633 業務ロジックは画面のためにある、というのは違うでしょ。
画面の目的は２つ。
・業務ロジックを起動するための情報を収集する(=入力画面)
・業務モデルに関する情報を提示する(=参照画面)
>>637 よくわかる説明だけど、わかるやつにしかわからんってなってるかも。
>>638 それ、なにが嬉しいの？業務ロジックのために人は画面に情報を入力するの？
業務ロジックが画面のためにあるというのは違うと思うけど。
あくまで、印刷とか、ファイル転送とか画面をIFとしない業務ロジックもあると思うから。
>>633 こっちの方が正しいんじゃない？
>>641 穴があいたら、次はどうすればいいですか？
入れるしかないよ。
入れるから穴があくんだろ。逆転してるぞ。
はぶ氏の長文は、リファクタリング前のコードと同じ臭いがする。
俺らは研究者じゃなく、売り物を売ってんだから、新しかろうと古かろうと
コストが低く品質のいいソフトが作れる技術を選べってことだろう。
構造化もOOも上記を実現するためのものの筈だ。
清く正しいOOに固執するあまり、逆に生産性を下げて
しまってるのはマズいな。
ER分析と構造化手法に上手くOOのおいしいとこだけ取り込んでっていう
くーす的なやりかたが「今の時点」の正解だと思う。カスタマイズは自分らの
貯蓄に合わせてすればいい。
で、正しいOOの負の部分が解消されるようになれば（OODBの性能があがって安くなるとか）
すれば、それを使えばいい。
DIやAOP、ORMに関しても、効果と新しいコストとのバランスが重要で、
その点がS2が優れてるんだな。
ということで、Seasar2マンセー！S2Daoマンセー！S2JSFも（多分）マンセー！
まったく同意。本当、からさわぎ楽しみ。
でも仕事の頭からちょっと離れると、
やっぱファウラーの文章とか読むとワクワクするんだよね。
そんな自分も居るのが判ってるんで、ちょっと悔しいというか
さみしいというか。
だから617の気持ちも判るんだよなー。
リファクタリングして説教して来いｗ
みんなが
>>646に期待してるぞ
>>648 >やっぱファウラーの文章とか読むとワクワクするんだよね。
その辺は先行投資だね。
関数型言語や形式仕様なんかも、そのままの形で仕事に使えないかもしれないが、
懐を広げておくのは開発者として重要だと思う。
ただ、いつの間にかその学習コストを客に押し付ける格好で、実案件に適用しようと
考えてしまう。
「この技術を使っています。だからこれだけ値段が上がります。」ってのは通用しない。
「この機能がこれだけ安く実現されます。」「この作業がこれだけ軽減されます。」
これを末端開発者も忘れないように気をつけたいね。
>650
ありがとう、なんか気が楽になりましたよ。
気が楽ってのは、けして安くない本を
会社の金でパカパカ買って乱読しちゃった
罪の意識が楽になった、って事だけど（w
まあ、スレ違いかもしれんが、こういった話無しにS2の良し悪しは語れんからな。
書籍代なんて誤差の範囲だよ。
プププ
654 ：
デフォルトの名無しさん：04/10/18 02:34:48
結局、はぶさんは TransactionScriptでいーじゃんか、ってことか。
くーすもTransactionScriptをベースとしてんの?
>. 654
TransactionScriptだろうとMDAだろうと、今使えて、生産性向上とコストダウンを
実現できるやりかたでやるということだろ。客の利益になる物を作って、お金を頂いて
生活してることを忘れるな。
って、所詮2chか。S2にもフォーラムが欲しいな。
>>655 みんな各自のblogで満足してるから、実現性は低いね。
>>637 ドメインオブジェクトにViewHelper的な要素を
持たせるということなら反対。
むきだしのドメインオブジェクトなら、画面では激しく使いづらい。
>655
コイツはなに当たり前のこと偉そうに言ってるんだ？
生産性とコストダウンに加えて拡張性とメンテナンス性も向上させるのに
OOの中でもどういう手法をとったら効率がいいのか話あってるんだろ？
はぶか？
「客だよ、客！」
「利益なんだよ、利益！」
「コストダウンっつたらコストダウン！」
文脈を無視してこれしか言わないのはハブだろ。
じゃなければハブのクローンか。
どちらにしろ匿名で言い合っている中で人物名だす必要はなかったな。
あやまっときます。すんません
じゃあこれからは人物名「はぶ」ではなく機器名「Hub」ってことで。
納期とか予算とかがまずあって、手法はそのあと、とかそういう考え方って、サービス残業しろ、間に合わなければやっつけで、っていう考えにたどりつきがちだけどね。
ソフトウェアの開発は気合でうまくいくものではないと思うんだけど。
「客優先」「利益」「コストダウン」って、サービス残業させるための「魔法の合言葉」だね。
「やればできる。」
長期的に品質(含納期・予算)を確保するためには手法が必要だと思うんだよね。
手法にもてあそばれるのは良くないけど。
> 客の利益になる物を作って、お金を頂いて生活してることを忘れるな。
という考え方も、古いね。
サービスの対価としてお金もらってるんだから。主従関係ではないよ。
金額にみあったサービスを提供できればそれでいい。
それができないのは問題だけどな。
>>663 それははぶについてでなくて一般論だよね？
はぶは手法としてはくーすカスタムなわけで
サービス残業うんぬんの負荷の軽減を
言ってるわけで。
ほっときゃ本人があっちに書くか。楽しみにしていよう。
今の流れって前向きなの？ム板ですべき話なのかな？
技術のギの字も出さずにただ現場の話がしたいだけなら
マ板いけば？
って、所詮2chかｗ
俺はそんなにスレ・板違いにも思えないんだな。
S2からくーすにつながる中で
やっぱり現場の話は、どうしても出るよ。
それだけ実践的なものって事なんでしょう。
ムだのマだのでがっつり分けたがる方が
所詮2ch。
マ板は、ネタスレ用隔離板ですよ。
現場の話が技術の話だと思わないあなたはピープルウェアでも読んでください。
ｽﾙｰしる
そんなことよりも S2JSF だよ。
まだでねーのかよ！
S2Flex とかどーでもいいからはやく S2JSF リリースして栗
OpenSymphony QuartzのJobにDIしたいと考えてるんだけど、タイミングが
つかめない。Jobインスタンスは実行ごとに生成されてそうだから、JobRunShell
でnewInstance()するごとにDIせねばならん。
Tapestryもそうだけど、元のライブラリがDIを考慮した設計になってないと
きついな。
はぶさんも、いちいち相手にしなけりゃいいのに。
「伝染るんです」のスズメみたいなもんなのにね。
おお、すずめかあ。懐かしいなあ。
でもピンポンダッシュっぽい感じもするので
「こらー！」ってゆってくれないとちょっと寂しい。
いやー、言いたいことをおもしろおかしく、語弊と誤解とあらぬ疑いをまじえながら、勝手に書き込んでるだけなんだよね。
2chってところは。
で、怒られたら逃げる。でもやっぱり離れたところでこそこそやる。
怒られなかったらそれはそれでちょっと寂しい。
>673
そうだね。一応outer定義してinjectDependencyという手段はあるけど、
メリットのあらかたを享受できないからね。
DIを考慮した設計でなくてもいいけど、生成部分の自由度が低いと辛い。
678 ：
デフォルトの名無しさん：04/10/19 20:57:03
業務アプリケーションをそんなに急いで作りたいなら、一番確実な方法としては
「あらかじめ作る」しか無い。
つまり、業務アプリでEclipseみたいにプラグインで拡張可能なソフトを作ることだと思うよ。
（この設計は極めて難しいものになるだろうけど。）
679 ：
デフォルトの名無しさん：04/10/19 20:59:44
業務アプリとはいえ、プラグインプログラミングをやらうとするなら、
ソース公開されていることは必須条件。別にGPLじゃなきゃだめというわけじゃないけど。
（ソース読まずにプラグインだけ作ることは無理だ）
>>678 StrutsやらHibernateやらいろいろ抽象化してくれるものと、DI+AOPのおかげで、極めて難しいというほどではないとおもう。
規模やら分野によるだろうけど。
この中の何人くらいがちょっとS2さわってみたとかではなく、
実案件でS2を適用し、かつ無事にリリースできているのでしょうか？
3.14人くらい？
S2というか、そもそもJavaで実装すること自体やめたほうがいい
なんで？
Jobの抽象クラスを作って、実行前にSingletonS2ContainerFactory.getContainer()
を呼ぶか。
S2コミュニティって、コアのおっさんたちは確信犯だろうから別にいいんだが、
周辺の若手マンセー君たちがイタイ。
何で「くーす=現場密着使える」「それ以外のOO方法論=机上空論使えねー」
って2分割の構図で思考停止できちゃうのかわからん。
# 逆説的に、2年前くらい前に「Togetherでラウンドトリップ」とか「永続化は
# EJB2.0CMPで決まり」とか「Struts最高」とか「Taglib凄い」とか言って
# 懐疑派を時代遅れの馬鹿扱いしてたやつらと同じ罠にはまってる気がする。
くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
(予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
カバー、的な。
スレの流れとは関係ないが、なぜか同じ穴のムジナという言葉を思い出しちゃったな。
S2Daoに要望
・挿入時にAuto Incrementフィールドを
オブジェクトのプロパティで更新しないようにしてほしい。
・数値とbooleanの変換をして欲しい。
・countXXX(), sumXXX()なんかの集計関数の自動生成が欲しい。
・テーブル名、エイリアス名は`なんかで囲って欲しい。
・getLastInsertId()欲しい。
所詮２chなんで、さらっと無視して下さい。
S2JSF期待してます。
どうぞご自愛ください。
>「それ以外のOO方法論=机上空論使えねー」
ってあったっけ？
誰が若手やらわからんので俺が見てないだけかもしれんが。
>>686 TransactionScriptが
ロジックの共有化をはかると構造が複雑になる
と述べている理由を述べよ。
なんか、大きい仕事を任せてもらいない人が
思い込みで語っているような。
あなたにまかされたプロジェクトが、いかに効率的
なのか説明してみよ。
686さん>
「若手マンセー君」はWithout EJBの勉強会に参加して見回した限りは
(本当はRUP推進派の)僕も含めて存在しないです。僕自身の立場としては
限られたりソース内での最大限の効果を望む社内のDOA(Data Oriented
Approach)な人にも使っていただけ，単体テストが効率化する「くーす」と
Seasar2(および周辺プロダクト)を応援しているというだけで，マンセー
ってわけではないです。理想は，でも現実的には，だったらどうしたらよい
という前向きな人たちの集まりだと思うのだけど。そうじゃなかったら休日の
半日つぶして勉強会に集まったりしませんよ。
>>686 >2分割の構図で思考停止できちゃうのかわからん。
思考停止しているのは、あ・な・た☆
比嘉氏・取り巻き・羽生氏ときて今度は若手か。
徹底的に人に絡んでくるな。
つうか、取り巻きって誰かが明示されてないし。
イタい取り巻きの例示きぼん
>>686 s/取り巻き/若手
んなこといいけど、S2JSFって進んでるのかな？
なんか、S2FlexとかS2.1とかくーす本とかで忙しいみたいだからねえ。
S2JSFのためにS2のバージョンアップが必要なのだろうか？
S2JSFのためのS2.1化だろ。
う～～待ちきれない
そこでJSF-Springですよ
>>695 やめれ。これ以上個人名を出す必要はないよ。
比嘉氏や羽生氏はともかく他の人は関係ない。
ひがさんやはぶさんの名前を出す必要もないけどな
S2の話題でﾏﾀｰﾘやろうや。からさわぎ楽しみ。
やっぱりからさわぎはくーすのトラックが人気なのかな？
俺もデザイントラックにしようかと思ったんだけど
くーすは本が出るからそっち読むとして
今回はビジネストラックにしようかなとも思って。
マジカ面白かったし。
S2JSF いつ頃だろうか。
前のプロジェクト、プレゼンテーション層までSpring使うんじゃなかった orz
今のうちにS2に乗り換えてしまくて。
WW2かTapestry試そうかと思ったが、本命はS2JSFなんだよな。
タイミング的に微妙.....
何かに依存した設計のデメリットを、ロッドジョンソンに身を以て教えられた。
そんな２７歳の秋。
この板以外、どこのブログ見りゃいいんじゃいの？押さえどころ
709 ：
デフォルトの名無しさん：04/10/21 02:45:56
710 ：
デフォルトの名無しさん：04/10/21 06:08:00
大田@会社さんへのレスというわけではないのだけど。
>>692 > 理想は，でも現実的には，だったらどうしたらよい
> という前向きな人たちの集まりだと思うのだけど。
傍から見てると
「理想=OOA/D」は幻想だった、これからは TransactionScriptマンセー
って言っているように見えちゃうのは俺だけ?
# TransactionScriptが最適解である状況が存在することは否定しないけどさ
711 ：
710：04/10/21 06:19:20
間違えた。
以下のとおりに修正。
>ひがさんとはぶさんを傍から見てると
>「理想=OOA/D」は幻想だった、これからは TransactionScriptマンセー
>って言っているように見えちゃうのは俺だけ?
はぶ氏がRDB大好きだというのはblog見てるとわかる。
ひが氏はもう少しニュートラルというか使いやすい
ORマッピングを考えてのことなんじゃないかな。
ふたりともTransactionScriptマンセーというのとはまた違う気がする。
ER分析マンセーなのかも知れないが。
RDBをRDBとして使う限りにおいては、ER分析マンセーみたいね。
俺も同意。つーか当たり前だと思う。
RDBをただのストレージとして使うやり方は俺には合わんかったんでｼﾗﾈ。
710さん>
幻想というより西方浄土でしょうか。ひがさんにダイレクトに聞いてみると分かりますが，
TransactionScriptマンセーじゃないですね。僕も今は教育側にいるときがありますけど，
理想のOOA/Dは現時点ではあまりに属人性がありすぎて，Martin Folwerのいる会社のような
よほどつわものがそろった組織でないと難しいです。つわものがそろっていれば，理想の
OOA/Dも不可能ではないと思います。
>
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL 既読です。読書会でも話題になりました。これをたたき台にして，トレードオフについても
かなり議論になりました。理想のOOAD対ER分析というよりはメンテナンス性対パフォーマンス
というところでしょうか。
単に選択の問題であるだけでしょう。
私が今携わっているプロジェクトでは業務ロジックがさほど多くなかったので、
Springを使ったTransactionScriptな設計にしてありますが、
明らかにサービス層の肥大化が予想される場所にはDomainModelを適用しています。
別にどちらが正解であるということもありませんが、OOエキスパートが少ない
環境ではTransactionScript寄りになってしまうことは避けられないでしょうね。
ちなみにくーすはTransactionScriptの発展的なアプローチだろうと思います。
ひがさんは否定しておられるようですが、サービス層と永続化層を分離した
パターンの中で、大別して上記２つ以外に思いつくものはありません。
というか何がどう違うのかもうちょっと説明して欲しいかも。
Entity層にビジネスロジックを含めないって時点で、少なくとも
DomainModelではないし。
今日は風邪で休んでるんで自宅からカキコ。
直に書きに行こうかともおもったけど私なんかの出る幕はではなさそうだし、
この場で失礼。
ビジネスロジックって表現がそもそも曖昧だよな
>>716 > ビジネスロジックって表現がそもそも曖昧だよな
そうかも。
私の中では一連の"業務仕様"ってところで理解してます。
売上げ本数の計上ルールとか？ いい例えが思い浮かばん。
永続化処理とか、メールやCSV取込とかはビジネスロジックとは
呼べないでしょうね。
本当に答えて貰ってたんで、ちょっと感激してしまった。
私自身、2chにもカキコすることなんて滅多にないから。
なるほど。
というところですが、時間があればひがさんにもPofEAAの一読をお勧めしたいです。
文章を読む限り、原書の方にはまだ目を通されていないような印象でしたので。
リッチなSQLはDomainModelにもTransactionScriptにも適用されます。
そこでの問題はロジックがSQL内に分散することですが、これがパフォーマンスとの。
トレードオフだと言っているわけで、それはDomainModelにしろTransactionScriptにしろ
同じことです。
ところで、このスレのちょっと上のあたりでDomainModelとDTOとの相互変換云々って
話で盛り上がってたようですね。
私はよく、DomainModelをDTO(テーブルと同じ構造)を内部に複数持ち、
各層に公開するインターフェースを実装したオブジェクトとして定義することがあります。
というか大体これです。
相互変換の必要がないインチキ手抜き設計なので、当然無駄なプロパティや処理が
増えることになりますが、要の部分はインターフェースを介して隠蔽されているため、
実際に問題になるような事は滅多にありません。
Springの各種DaoSupportやS2Daoもそのままの形で適用出来ます。まあ参考までに。
純粋なDomainModelはO/RMapperの発展に合わせて、今後少しずつでも浸透して行くでしょう。
と願ってみる(希望的観測)
結論：OO厨は邪魔なだけ。
ちゃんとした手法に基づいてやられたら、デスマーチのらくらく残業ができなくなるもんね。
ここんところの話が英単語ばっかりでよくわかんにゃい。
くーすの考え方の肝ってどっかに載ってる？
「業務処理手順をソフトウェア設計者が抽象化してはいけない」ってことかな、と思ってるんだけど。
OOは部品化以外の用途で仕事で使うには、頭がよい人を期待しすぎだよ。
自分で設計してるときはそりゃ楽しいけど、実働後の保守メンバーに馬鹿が１人いただけで設計が崩壊しかねない。
それが自分だったりして鬱になる。
例えると、天才が設計したゼロ戦で華麗に舞って死ぬよりも、
芸が無いグラマンでデスマから生還したほうがいい。
その例えだと、グラマンはいかにも燃費が悪い。
ぜいたくに出来た飛行機だと松本零二も言ってます
↑
ここ笑うところ
>>721 その、グラマンたるライブラリがSeasar2なんだよ！
POJO書いて、設定ファイルを書くだけ。
S2で欲しい機能があれば、はてなでｷﾎﾞﾝﾇするだけでOK。
ひが氏にお願いです。
商用サポートもドキュメント見直しもFlexも
くーす本もからさわぎも全部後回しでいい。
頼むからS2JSFを早く出してください。おながいします。
>>724 S2JSF ＞ くーす本 ＞＞＞＞＞＞ その他
開発するより宗教論争が好きな人って結構いるね。
2chに書いてるﾔｼなんざ大抵そうだな
つか、2ちゃんだから出来るんだよ。
現場でやる奴よりは全然いい。
大体宗教論争ってのは、スプーンに天使は
何人乗る事が出来るかとか
そういうアホで無意味な事を議論する事で、
ここでの話はわりと意義はあると思うよ。
>>726 開発なんかするより他人を論破することが楽しいですが何か？
ttp://d.hatena.ne.jp/higayasuo/ > 良く使われると思われるドキュメントを見直しました。
> すべて、概要、リファレンス、Exampleの3部構成になっています。
> どうでしょう。2chの人
おぉ、こぎれいに、丁寧になってる。
くるしゅうないぞよ。
あとは、www.seasar.orgにそういった改変情報が載るようにすることですね。
それから、ソースと実行結果はスタイルを変えたほうが。
実行結果は黒地白文字とか。
733のような奴の言うこと真に受けて、がんばってらっしゃる。
ひがさん、尊敬します。
733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動くプログラムを作ることすらできないですから。残念！
>>734 > 733のような奴の言うこと真に受けて、がんばってらっしゃる。
> ひがさん、尊敬します。
>>733って、文体は2ch的で一見失礼だけど、ひが氏のモチベーション向上+
前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。
> 733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、
> ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動く
> プログラムを作ることすらできないですから。残念！
こういう非生産的なラベリングはやめようよ。つーわけで
>>733気にするな。
って、
>>733の自演扱いされるのがオチか。
>> バウンダリで、直接ドメインオブジェクトを使うのも、かなり困難だと思います。
これって理由は何でだっけ？
>>735 >ひが氏のモチベーション向上+
>前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。
ドキュメント的には、「今の段階で」十分すぎるほど揃ってると思う。
日本語ということも含めると、他のオープンソースプロジェクトなんかより
断然素晴らしい。
失礼な文体、普通はモチベーション下がるって。成果物改善支援？大きく出たな。
物は言いようか。好レス？？笑けた。ネタ？
>>735 ありがとー。
あーだこーだ言うだけ言って、作業に手は貸さないわけだから、そこに対して改善が図られた場合には、ちゃんと気づいて反応するようにしてるです。
「今の段階で」というなら、「揃っている」じゃなくて「揃った」、の方があてはまるんじゃねぇの？
>>736 あとで仕様変更があってバウンダリとドメインオブジェクトの間にロジック（サービス）を
挟まなくちゃいけなくなった時に困るからじゃなかったっけ。
「今の段階としては」だな。
742 ：
デフォルトの名無しさん：04/10/22 06:11:18
>>732 問題と思うことをきちんと指摘したら。
人にいわれる本を全部読むような時間のあるひとはいないだろ。
>742
推している人たちって誰のこと？
DomainModelいいよ！って言ってる人全部ってわけじゃないでしょ？
SQL書きたくないから～って人は確実にいる（何人か知ってる）し、
そういう人を想定して言ってるんじゃないかな。
SQLばっちり分かっててかつDomainModelを推してる人よりは多いと
感覚的には思うが、どうだろね。
>>742 DomainModelを推している人は、
「SQLが分からないから使わない」
と思っているとは、書いてないと思うけど。
それは、被害妄想。
>>742 なあビジネスロジックって何？
ほんとにわかんねえんだよ。
SQLで平均とか一発で出せても
使うなってことか？平均何とかも
ビジネスロジックだと思うんだけど。
何でこのスレはageる人が多いんだ？
>>732 ひがたんはそんなの読まなくてもいいからS2JSFを先に作って欲しい。
正直漏れはくーすはどうでもいい。便利な道具としてのS2が気に入ってるんだ。
もしひが氏が真面目に原典とやらを読んだ結果S2JSFのリリースが遅れたりしたら
>>732ぬっころす
そこまで粘着すると、キモいね。
2chに書いてるだけでキモいけどね
とりあえずこのスレは粘着のスクツということでFA
>>747 そういうことみたいだな。
複雑な会計の帳票とか出すとき
どうするんだろうって思うよ。
UNIONとかFROM句にサブクエリとか
ガンガン書いてやっとまともなレスポンスで
出るようになる帳票とか山ほどある。
だからS2Daoは、最初見たとき霧が晴れた気分でした。
ドキュメントがいくつか更新されたみたいです。
・DIContainer
・AOP
・テスト技法
・S2DAO
の4項目かな？
どこの項目が更新されたかわかるように印をつけて（updateとかnewとか）
くれるとありがたいなあ･･･
ぐあっ・・・ほんとだ orz
駄ﾚｽでした。重複ｽﾏｿ
>>757 > リッチなSQLの例が、SQLの入門書レベルだからなー
同意
SQLの中身については、いやまあサンプルって事で。
それいったら、過去実績である注文データに対して
ディスカウントキャンペーンを適用するようなつくりになってて
蓄積された実績を何時でも恣意的に改変できる形になってるじゃん。
注文ってエンティティの構造は捉えられていても
その意味というか本質というか、全然考慮されてない。
その理由は、勿論サンプルだから、でしょう。
まじボケだったらファウラー、おちゃめさんです。
つっこみ始めたらきりがないから、ここは
「SQLに業務ロジックを入れる」って事のだけ
見ればいいよ。
>ただ、アプリケーション開発者はこれくらい複雑なだけでも避けちゃうんだよね。
これくらい↓
複雑↓
SELECT DISTINCT MONTH(o.date) AS month
FROM lineItems l
INNER JOIN orders o ON l.orderID = o.orderID
INNER JOIN customers c ON o.customerID = c.customerID
WHERE (c.name = ?) AND (l.product = 'Talisker')
GROUP BY o.orderID, o.date, c.NAME
HAVING (SUM(l.cost) > 5000)
確かにおちゃめだ。Fowler氏自身はSQLを使いこなしているようだが。
このレベルを避けちゃうようなﾔｼと仕事してるのかと思ったら不憫に
感じるというか親近感が湧いたYO
一人いたな、簡単なJOINのSQLでも
全部Accessで作ってからちょこちょこ直す人。
結構経験あって、Win32APIとかすごく詳しかったけど、
業務系はあまりやってこなかったみたい。
帳票のSQLとかほとんど俺が書いて、メールで渡してたなあ。
しかもその人がテーブル設計やったもんだからもう、
俺も不憫に思ってくれい。
そのSQL書ける人が書いてメールで渡すってのを
メール経由でコピペとかじゃなくて、
きちんと組み込めるのがS2Daoな訳ですな。
・・・普通の集計にしか見えんのですが。
その普通の集計をわざわざコードでやるがいいと
おっしゃっておるのでつよ。
これがリッチSQLなのでつ。リッチクライアントも決して
普通のVBの画面にしか見えんのですが。
などといってはいかんのでつ。
しょぼいSQLで済むことにあれだけコード書くようだと
複雑なクエリーが必要な場合にどれだけコードを書くんだ？
いくら将来性がどうとか言われてもバグが増えそうで俺は嫌だ
あるかないかわからない移植のことを考えるよりもさっさと作って
リリースするほうが重要なんじゃないか。いるものだけ作るという
原則に反している気がする
つまりあれだ。
S2Daoﾏﾝｾｰってことだな。
だな！
>>763 > リッチクライアントも決して
> 普通のVBの画面にしか見えんのですが。
> などといってはいかんのでつ。
比較対象がHTMLフォームだから。
あのドキュメントは社員さんが書いたのか。
サイトの運営も社員さんにやってもらったほうがいいね。
なんにしろ、組織的なサポートは心強い。
>ビジネスロジックとは
意味わかんね。
だれかかいつまんで説明して
770 ：
デフォルトの名無しさん：04/10/23 00:39:25
>>764 問題は移植性だけじゃない。Fowler氏はいろいろ挙げてるじゃないか。
とくに問題になる点は
・更新性「EAはこれからめちゃくちゃ変わる」
・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」
だろう。
まあ、俺はどっちかというとS2Daoマンセー派だが、物事はそう単純ではないと言うことだ。
結局規模が違えば考え方も違うってことだね。
もちろん、SQLではなくてアプリケーション側で処理してもパフォーマンスに何ら問題ないようになると違うんだろうけど。
>>770 EAはむちゃくちゃ変わるってのは
日本で業務系に携わってても
正直そこまで実感が湧いてこないんですが
それは私の経験不足と言う事でさておいて
大体リッチなSQLを使う所って、経営分析データだとか
会計帳票とかになりますよね。
そういう所はEAとかいう部分と関係なくて
逆に安定しまくっとる所なわけで、
そこにSQL一発ですむものを複雑なコーディングに
置き換えるのはやはり気がひけます。
やっぱりいいとこどりが一番って事でしょう。
議論としちゃつまらん結論ですけどのう。
全体を捉えた議論の結論としては
「やるべきことをやる、使うべきところで使うべきものを使う」
ということになると思うが、じゃあ、どれはどこで使うのか？という議論が大事なんじゃないの？
つまり、その手法のメリットデメリットはなにか、と。
マンセーするにしても、いっさいがっさいそれでいくわけじゃなくて、多少のデメリットは目をつぶるという程度だろ？
774 ：
デフォルトの名無しさん：04/10/23 02:33:35
S2JSF間近aga!!!
>>770 > ・更新性「EAはこれからめちゃくちゃ変わる」
だったら今考えている柔軟性が通用するかどうかわからんように思うのだがどうか？
> ・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」
データベース設計が変わったらそれを使っているビジネスロジックも変更する必要があると思うのだがどうか？
云わんとしていることはわかる気がするんだが冗長過ぎる気がしてならんのだよ。
ファウラーのblikiを翻訳してる方によると
やはり日本とアメリカの事情の違いってのがあるそうで、
日本にくらべてあっちはアプリ開発とDB開発の分業が
相当徹底されているらしいですね。
で、
> ・カプセル化「ビジネスロジックを担当するコードが
>データベース設計変更時に影響を与えられることはない」
ってのは、776の言う通り、設計変更っていや
ビジネスロジックの変更の事だろう、って気分に私もなりましたが
もしかしたらアメリカさんの事情ならではの発想なのかも知れないなあ
と思った訳です。向こうからしたらこっちの言ってる事がドンくさいと思われるかも。
あくまでも推測なんで、アメリカさんの事情に詳しい方いらっしゃいましたら
うそつけバーカとか書いちゃって下さい。
あと、私も含めてですが776の「DB設計変更=ビジネスロジックの変更」って考え方は、
やっぱり前提がDOAなんでしょうねぇ。でもしっくりくるよね、皮膚感覚で。
773の意見にまったく同意です。
でもまあ、総論みたいな所も、答えは「いいとこどり」に
落ち着く事は判っていても、喧々諤々やっといた方が
いいと思うんですよ。
その事で、双方の「いいとこ」の範囲が、
前より広く感じられて来たりしたら良いと思うし。
ここ、読んでて大変面白いですよあたしゃ。
2ちゃんのOO関連スレじゃ一番じゃないですか？
関係ないが、某blogでマジックナンバーはいいの悪いの、っていうのがあって、アクセッサ作れってあるけど、すべての定数についてアクセッサ作らされてたらたまらんな、と思った。
結局、マジックナンバーを使うなってことではなくて業務数値をその数値を保持するべきではないところに置くな、ってことじゃないのかな。
言語とRDBMSと、どちらが変更される可能性が高いか。
どちらとも言えんと思う。
言語が変わる場合：
C/S からWEB系への移行
Unixに乗り換えで、ASPからJavaへ移行
RDBMSが変わる場合：
パッケージもの。お客様によってRDBMSが異なる
辺縁系のシステムなら、Oracleなどからオープンソースに乗り換え。
他にどんな場合があるかな？
言語は変わる場合より併用の方が多いんじゃないかな。
たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか
# 実際はサーブレット呼び出すようにしてJavaで処理させたりするが。James？なにそれ。ｗ
部分的にPHPで組むことも考えられる。
RDBMSで言えば、最初はPostgreSQLで運営してたけどサービスが成長したからOracleに移行とか。
Windows上のSQLServerで運用していたけど、大人の事情でUNIX使うことになって、Oracleへ、とか。
PostgreSQL→Oracleのようなスケールアップはありがちなんじゃないかと。
逆に、移行しやすいように作っておくことを前提に当初はPostgreSQLで運用開始とか。
782 ：
デフォルトの名無しさん：04/10/23 09:23:30
>>781 > たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか
いろんな言語を組み合わせるのはどうにも気持ち悪い。メンテナンスしづらいでしょ。
開発環境そろえるのに時間かかりそう。環境によってあーだこーだ言うのは最悪。
バージョンがこうだとか、ディレクトリ構成がこうだとか。ウザい。
シンプルが一番。
アプリケーション毎に常駐プログラム作ってそこでデータベースなりメールの処理するとかするでしょ普通。
ポータビリティが重要だと思う。
CVSのモジュールを引っ張り出すだけで自前の環境でシステムの自動テストができるような単純さが開発では重要。
加えると、Javaって面倒だ。
全部スクリプトで作ってしまえばいいと思うのだが。
>>777 だからコミュニケーションの重要性が
日本以上に言われるのかな＞分業の徹底
>>783 うん、そうみたいですね。
blikiの翻訳者さん、こんなのも翻訳してまして
tp://capsctrl.que.jp/kdmsnr/wiki/agiledata/
ここみると、「なぜ一緒に働くことが現在困難なのか」とか
なんかアプリ屋とDB屋がまるでイスラエルとパレスチナの様で、
日米の文化の違いはかなりのもんの様です。
でもアメリカさんだから、ジョークというか
比喩かも知れないですけどね。
seasarの良いところがいまいち分からんなー。
インターフェース書いて、ダイコンファイル書いて
ってめんどくせーって思っちゃう。
サービスに新しい機能付けようと思ったら、インターフェース
とImplクラスの２つを変更しなきゃいけないし。
インターフェースはImpl挿げ替えるだけで、動きを変えられるって
メリット（多態性）で使うんであれば良いし、よく使うんだけど
seasarのためにインターフェースガンガン書くって気にはどうも慣れん。
ダイコンファイルでImpl差し替えるって事ってそんなにたくさんあるのかな。
漏れはstruts+Hibernateで全然作ってるけど、「それだとここめんどくさくない？
なので私はseasar使うようになったよ」って意見を聞きたいです。
あとEJBはseasarよりさらにダルイっておもっとる。
別に無理してまでインターフェース用意することも無いでしょう。
必要に迫られたときにインターフェースを抽出することは
IDEなんかのツール使えば一瞬で出来るんだし。
ただ、インターフェース使うとimplのすげかえ以外にもメリットが多いのは事実です。
不必要なメソッド呼び出しを隠蔽できたり、Mock使ったテストが容易になったり。
レスありがとう。
>別に無理してまでインターフェース用意することも無いでしょう。
seasarってインターフェース必須ではないんだー。誤解してました。
>不必要なメソッド呼び出しを隠蔽できたり、
これは、漏れのやる仕事のに依存してるのかもしれないけど
APIのようなクラスを作るときは、隠蔽って重要だと思います。
でも、そうではない業務ロジックの実装だと余り隠蔽したい場合に
出くわさないんですね。
>Mock使ったテストが容易になったり。
これはもう少し詳しく聞きたいです。seasarのドキュメントにも
テストが容易って書いてありますが、EJBに比べてって事ですか？
struts+Hibernateでテストしにくいって感じた事無いんですよね。
>>785 seasarというより、インターフェースと実装を分離するということは、
OOの重要な部分だと思うけど、分業するときに、
インターフェースを先に決めておけば、実装が追いつかなくても、
Mockとかを使って作業を並行して進められるというメリットがあるね。
実装クラス同士が直接依存しあうことが少なくなるから、
個々のクラスの個々のメソッドを単独で実装・テストしやすい。
直接依存してると、依存しあっている部分を全部コーディングしないと
テストできないから。
>>789 >Mockとかを使って作業を並行して進められるというメリットがあるね。
でもインターフェースじゃなくて、空のクラスだけMockとして用意するのも
同じだと思うんですが。あ、もちろんどちらが綺麗かって言われたら
インターフェースがある方ですが。。。
>依存しあっている部分を全部コーディングしないと
>テストできないから。
うーんseasarもダミーの実装をダイコンファイルに書いてるだけ
なんだよなと。Implクラスにダミーの戻り値を書いておく方が
楽と感じてます。
>>790 普段は下層のDAOから実装していくって感じなんで
（階層での作業分担はしない）、DAOの単体テスト=>サービスの単体テストって感じ。
サービスで他のコンポーネントに依存するようなら、まずそっちから実装かな。
相互に依存する場合は、必要になるメソッドだけOr上で書いたダミーの実装。
他の人のコンポーネントが必要なときは、クラスだけもらってダミーの実装だなー。
>>791 それなら、それでいいんじゃないですか。
うまくいってるなら、特に変える必要はないと思います。
でも、ダミーの実装を作って、取り替えてなんて、
やるのは、大変そうですけどね。
あとから、実装が何だかおかしいから、ダミーに戻して
確認するってのも大変。
ちゃんとバージョン管理しているなら、ダミーと実装の
管理がすごく複雑になる気がします。
まさか、自動テストの一括実行をやってないとか。
>>792 ダミーの実装はバージョン管理に追加しないですね。
中身の無いクラスだけコミットしてもらって、ダミーの
実装は各自勝手にといった感じ。中身が出来たら更新。
その点seasarはダイコンファイルで複数のダミーパタンを用意して
それを取っておけるのが良いですね。
>あとから、実装が何だかおかしいから、ダミーに戻して
>確認するってのも大変。
実装が出来上がっちゃったら、ダミーに戻すことは無いですね。
おかしいなって思ったら、大抵他人のコードでもデバック
しちゃいます（修正はしないで、原因だけ伝えるかな）。
上の方で言ってるくーすの話は面白いですね。seasar大して使ってないけど
設計論なんで、関係ないし。
ただ、貧血症とか、DAOにビジネスロジックとかって答えがあれば聞きたいけど
答えなんかないんだよね。漏れ的には、迷ったらメンバーで相談する。
SQLでやった方が楽で、早いならSQLでゴリゴリって書いて、ドキュメントなり
分かる形で残す。ViewとDAOのデータの受け渡しはBeanUtilsマンセー。
>自動テストの一括実行をやってないとか。
それってseasarと関係なくない？
seasar使ってないとJUnitで一括実行出来ないとでも？
デバックってゆうな～
>おかしいなって思ったら、大抵他人のコードでもデバック
切り分けにはモックを使う方が便利。モックの造りにもよるけど。
モックは単純実装になってるはずなんで、モックが仕様通りなら
他人のところがおかしい可能性大。
モックが間違っているならモックを直して再テスト。
ちなみにdebugなんでデバッ"グ"
OSSに対する直接的な貢献というのは、狭義にはソースコードの提供である。
通常は元となるソースに対しての差分をパッチという形で提供することになる。
そのパッチをメンテナと呼ばれるコアな開発者にメールなどで送りつける事が狭義の貢献である。
メンテナはそのパッチをみてよければ採用しよくなければ採用しない。
良い悪いというのはどうやって判断するのか？オープンソースの七不思議である。
ある人のパッチは受け入れられてある人のパッチは受け入れられない。
ある種の経験則はもちろんあるがその経験則を厳密に記述する事は難しい。
商用ソフトウェアの場合はコードの変更は担当者が行うので受け入れるも受け入れないもなくて
各社の社内規約に従って淡々とコードが追加されていく。
オープンソースの場合その明文化された「社内規約」に相当するものがないので、
ある種の秘密クラブの掟みたいな空気によって様々な意志決定がなされる。
新参者は空気を読め、空気をという話である。
デバッグですね。お恥ずかしい。。。
>切り分けにはモックを使う方が便利。
これは同意です。ただ、相応の手間が漏れには受け入れられないなと。
逆に他人のコードをデバッグして得られる事も多いです。
ただ、開発フェース外での他人のコードをデバッグするような事は
勘弁ですが（ｱﾊ
はぶ氏もひが氏もここの話題に反応してくれてますな
っと、話ふり逃げに思われると残念なので書いとこう
804 ：
デフォルトの名無しさん：04/10/23 23:03:29
どう作業分担するかで悩んでるらしいけど、
参考になるのはEclipseだと思うよ。Javaで作られた唯一役に立つソフトウェアだ。
これの開発方針を見れ。
805 ：
デフォルトの名無しさん：04/10/23 23:05:49
> Stateless BusinessLogicパターンのメリット
>
ttp://d.hatena.ne.jp/higayasuo/20040805#1091664617 上記サイトの内容で疑問点がありまして。
ひがさんは
「Statelessにするとメソッド間の依存関係を0にできる。
あるメソッドの呼び出しが、別のメソッドに影響を与えることはない。」
と仰っています。
ここでいう「メソッド間に依存関係がある」というのは、
あるメソッド(以下 Ma)と別のメソッド(以下 Mb)が共に、あるステート(以下 S)に
依存しているということに他ならない。
このステートSをクラスの外に出したところで、Maと Mbが Sに依存していることには変わりない、
つまり Maと Mbは間の依存関係を0にできていないと思うんだけど。
806 ：
デフォルトの名無しさん：04/10/23 23:27:38
>>805 だいたいゼロってことで、それでいいじゃん。
そんなん深く考えてもしょうがない。
>>805 ステートSがオブジェクト変数だとMaかMbからのみ変更される
って事だからだと思うよ。
ステートSをクラスの外に出すと、MaやMbはステートSに依存
はするけれど、MaとMbの依存関係は無くなるんだね。
よって、MaのテストはステートSの取りうるパターンのテストを
考えれば良いと。Mbがさらに何かに依存しているとテストパターン
が依存度倍になると。
でもステートSを隠蔽することがオブジェクト指向じゃんって思うけど
ここが、Blogに書いてあるように業務ロジックの変更頻度との兼ね合い
なんだろうね。
statelessって「実装に依存しない」って意味なんじゃないですか？
依存関係はインターフェイスで全て捉えるって意味だと。
違ったのかな。
stateless
【形-1】 国［国籍｛こくせき｝・市民権｛しみんけん｝・国家統治権｛こっか とうち けん｝］のない
【形-2】 《コ》処理状態｛しょり じょうたい｝を把握｛はあく｝しない～◆【対】stateful
って辞書にあるそのまんまの意味だとばっかり思ってました。
809 ：
デフォルトの名無しさん：04/10/23 23:48:50
>>808 HTTPはステートレスってことは、実装に依存しないって意味なのか？
> 処理状態｛しょり じょうたい｝を把握｛はあく｝しない
そのままじゃないか。
どこにも「実装に依存しない」とは書いてないぞ
>>808 かなり根本から間違ってるな。State が lessなんだぞ。
オブジェクトが状態をもたない。
814 ：
デフォルトの名無しさん：04/10/23 23:59:14
class Foo {
int s;
int method(int x);
}
があったとして、method(x)っていう呼び出しの結果がxの値だけじゃなく
sの値にも依存すればstatefulで、
xの値のみに依存すればstatelessなんじゃね？
だから
＞Statelessといっても、すべてスタティックメソッドにすれば良いという
っていうことになるんだと思ったけど
815 ：
デフォルトの名無しさん：04/10/24 00:01:29
>>814 statelessでもポリモフィズムは使いたい。
816 ：
デフォルトの名無しさん：04/10/24 00:03:16
>>814 >すべてスタティックメソッドにすれば良いという
ポリモーフィズムが使えるところが違うっていうところだな。
システムをプラグイン的に拡張していけるっていうのがありがたいんだろう。
これやるとプログラマのシステムの意図の理解に役に立つし。
817 ：
805：04/10/24 00:07:34
>>807 >
>>805 > ステートSがオブジェクト変数だとMaかMbからのみ変更される
> って事だからだと思うよ。
> ステートSをクラスの外に出すと、MaやMbはステートSに依存
> はするけれど、MaとMbの依存関係は無くなるんだね。
そうかな?
「MaとMbが依存関係とみなされている理由は、ステートSに依存するから」
なら
「クラスの外に出したステートSに依存するメソッドは全て依存関係にある」
と言えると思うんだよね。
>>817 じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
いないのに、MbはMaに依存しているっているって言える？
あくまでステートSに依存しているだけだよね。
あとは、ステートSの場所についてだけどこれは
>>813 って事だね。
820 ：
805：04/10/24 00:37:11
メソッドの処理がステートに依存するクラスの例として
以下のクラスがあったとする。
class File
void open();
void close();
int read();
}
これが以下のようにStatelessになったところで
open、close、readの依存関係がなくなったとは言えないと思うんだよね。
例が悪いのかな?
class File {
void open(FileState state);
void close(FileState state);
int read(FileState state);
}
だからステートって具体的なメンバ変数だの
それをクラスにして外に出すって事じゃないでしょ。
810の言う通りHTTPがステートレスというのと同じで
「状態を持たない」って事だと思って読んでたけど。
状態を持たないだと判りにくいか、
状態の変化を管理しない。
S2コンテナの考え方は、オブジェクト間の関連は
インターフェイス同士の関連だけ定義して
実装はdiconまかせでしょ、どんな実装をされるかが
オブジェクトにとって「状態の変化」でしょ、
だから、オブジェクトは「状態を持たない」
って思って読んでたよ。
結果的に「実装に依存しない」ってのは、
割と外れちゃいない気がする。
ひがさんのblogで例に挙がっている、手数料計算なんかだと
ドメインモデルではStrategy/Stateパターンになるよね。
そうすると、
aModel.手数料計算()メソッドは、aModel.set手数料計算方法()に依存する。
この計算方法は各業務に付随するものなので、業務ロジッククラスのメソッドで
あるべき。aLogic.手数料計算(anEntity)の方が、自然だとは思う。
ああでもよくわかんねぇ
824 ：
デフォルトの名無しさん：04/10/24 00:50:40
class File {
static int read(String filename, int position);
}
これは？
なんか俺も混乱してきたのでひがさんきぼんぬ
ここへ来て基本的な知識不足が露呈したなあ。
ああ自分が恥ずかしい。
あ、821=823です、
まぎらわしくなっちゃってすみません>822
>>820 オブジェクトをステートレスにしろって事じゃないの？
下の例だとＦｉｌｅＳｔａｔｅオブジェクトさえ作れば、
readメソッドのテストにopenメソッドは必要ない（場合がおおくなる）よね。
上の例だと、クラスにFileStateオブジェクトを持ってるって前提で、
readメソッドのテストにはopenメソッドが必要ってことになるよね。
>>820 何に対して、誰から見るとStatelessなのか、Statefullなのか
って事だよー。
上のFileクラスは、使う側から見るとopen、close、readのメソッドが
Statefullなんだけど、下のFileクラスは、引数のstateに対して
statefullであって、open、close、readの関係はStatelessだよ。
ようは、stateだけ考えてれば、良いって事。
ん？漏れはコアなseasar利用者じゃないんだが。。。
モンキーターン見てくる
829 ：
805：04/10/24 01:00:19
>>819 >
>>817 > じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
> Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
> いないのに、MbはMaに依存しているっているって言える？
> あくまでステートSに依存しているだけだよね。
今思ったんだけど、Maと Mbは依存関係にある、という認識が間違いなんじゃないかな。
Maと MbはステートSとのみ依存関係にあって、互いの依存関係なんてものは最初からない、と。
へんなこと言ってるかな?
> あとは、ステートSの場所についてだけどこれは
>>813 > って事だね。
そうです。
>>828 >
>>820 > 何に対して、誰から見るとStatelessなのか、Statefullなのか
> って事だよー。
> 上のFileクラスは、使う側から見るとopen、close、readのメソッドが
> Statefullなんだけど、下のFileクラスは、引数のstateに対して
> statefullであって、open、close、readの関係はStatelessだよ。
>
> ようは、stateだけ考えてれば、良いって事。
>
> ん？漏れはコアなseasar利用者じゃないんだが。。。
> モンキーターン見てくる
混乱させてごめんなさい。
レスは、今日はもう寝ちゃうので、また明日以降に。
ハイレベルな話題で盛り上がっているところ悪いんだけど、教えてほしい。
何回か話題に出ている「ドメインモデル」ってなに？
ぐぐってもNT Domainばっかひっかかるよ。。
ドメインモデル->実世界の構造のウツシミ
結局、こういう「だから何？」的な答え方になるんだよね。
これでわからなければ、一から説明しないといけない。
モデリングの本とかで問題領域とかいわれてる部分。
簡潔に一言でいうの、頭よくないと出来ないと思う。
だから本とか読んだ方が早い。
あ、そうか、だからぐぐるんなら
オブジェクト
設計
モデリング
問題領域
とか周辺の言葉を組み合わせでやってみれば
いいかも。
なんでも突き詰めると
「絵画の本質は絵を描くことだ」
みたいな、だから何？的な結論になるんだけど、その過程をたどってない人にはその意味や価値がわからないんだよね。
児玉センセの「UMLモデリングの本質」あたりを読むと
いいかもしんない。わりと薄いし。けど濃いめ。
釈然としない所もあるけどさー。
> 釈然としない所もあるけどさー。
どういうところ？
2chの議論系スレッドの鉄則。
よっぱらったら書き込まない。
でも、なんか、ヱビスについてるフィギュアでシーサーがついてきて、なんとなく嬉しくなったので書き込み。
こういうビジネスモデルの場合はこういうモデルにするべき、そうじゃなくてこうするべき、って議論はとっても役に立つんだけど、そもそも、「こういうビジネスモデルの場合」があてにならないのはいかがなものか。
特に、間にわけのわからない人が挟まってる場合は顕著。
「これはこうで、そこまでは必要ないから」っていわれて、実際の利用先に行くと、「いや、これはこうじゃなくてそこまで必要、とっても重要」とか言われること多数。
どうするべきよ？
どうよ？
>>838 大変面白く読めたし、勉強にもなりましたが
実装レベルに変換する、としておいて
OODBじゃなきゃだめよとなってるので
どうも現実感が湧かなかったのです。
その釈然としない所からO/Rマッピングを
色々調べだしまして、S2Daoに行き着いた時は
感激でしたわ。
マジカ？
>>840 OODBは、RDBの成熟度の高さに打ちのめされた感じだね。
結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。
Stateless, Statefulの違いって、DIコンテナとの相性があるのではないだろうか。
ttp://d.hatena.ne.jp/higayasuo/20041024#1098580377 > Statefulでやる場合、状態Sを持ったJavaBeansをnewして作成し使うことになるでしょう。
>そうすると、クライアントは、インターフェースではなく、実装クラスに依存することに
>なります。それを避けるために、すべての状態ごとにFactoryクラスを用意するのは、面倒
>でコストがかかります。
>Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。
S2DaoのBeanアノテーションをSeasar2.1のmetaタグにしてしまえば、
Factoryクラスはいらなくなるんじゃないでしょうか。
さらに、S2DaoがBeanを作成する際にinjectDependency()すれば、業務ロジックをもたせる
ことが簡単になると思います。
>こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、
>Statelessにすべきだと思います。
この「プレゼンテーション層から最初に呼び出されるクラス」というのが
ファウラー氏の言う「薄いサービス層」ですね。
>>845 その文脈でS2Daoを引き合いに出す理由が不明
ファウラー氏とひが氏のいうことを無理にあわせるのはよくないと思う。
>>843 OODBはOOがどうのという前にDBとしてこれからなんだろうね。
RDBだって数10年かかって今の地位を築いたんだからこれからだろう。
>>846 俺は
>>845じゃないけど
「UMLモデリングの本質」を読んだら
OODBじゃないとだめよっていってるので
（RDBじゃ駄目なのかと）釈然としなくて
O/Rマッピングを調べたらS2Daoに出会えて
感激した
っていってるんだろ？別にファウラー氏もひが氏も
出てきてないぞ。
>>846 薄いサービス層のことなら、何も無理にではないですよ。
まさに合致していると思います。
S2Daoをだしたのは、「実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。」に対応していて、StatefulなBeanを生成する際でも、DIContainerにある程度面倒みて
もらうことができると思ったんで。
>>849 うちの会社の競争相手は中国人 orz..
>>803 安心するヨロシ。
構造化や正規化すらできない、まともな仕様書すら書けない、要件定義だってできない。
そんな元請けがNやら何やらって名前だけで仕事とって丸投げする連中が、
くーすでオフショアなんて無理だって。
できる連中は今でもできるだろうし、そんな案件は元からうちにはこないアルよ。
先に誰かが書いていたアメリカの事情とか、
Fowler氏の前提としているEAとかあわせると
日本国内で一体どれだけの会社がEAを
必要としているのかという疑問が出てくるな。
漏れの会社は大手の下請ばかりやってるけど、
こんな案件はこないよ。そうじゃない案件は
大連と競合してるよorz
>794
>>漏れ的には、迷ったらメンバーで相談する。
これすごく大事。そして相談できるようなプロジェクトはいいプロジェクトだと思う。
ところが世の中には「1年生」とか「ひよこ」とか人材派遣会社から送り込まれてくるJava初心者どころか
プログラム初心者とか三国人とかがたくさんいるところも多い。
そういうところではカッチリひとつの方針を決めないとやってらんないんだよね。
段々と下請の悲哀を語るスレと化してきたな
結局、ソフトウェア開発の本質的で構造的な問題だからな。
857 ：
デフォルトの名無しさん：04/10/24 12:09:28
要するに悲哀感じるのは経営者がソフトウェア制作のことを分かってないから。
しっかり理解して投資していいチームを作るってことが重要なの。
>>857が投資していいチームを作って漏れをやとってくれYO
問題は
>>858が良いメンバーか、ということだが…
>>857 その投資の原資はどこからもってくれば良いのでしょうか？
資本金。
>>861 資本金を投資する以上、一定期間後にはキャッシュリターンの実現が必要。
本当にキャッシュがリターンされるの？
各担当者の技術レベル向上が収穫とかいう寝言はやめてくれよ（藁
データと処理は分離、という点でいくと、ORマッピングで継承使ったときに、ポリモーフィズムで処理を切り替えることについてはどう考えたらいいのかな。
>>859 漏れはいいメンバーになるYO
頑張るから入れてください
>>853 そもそもアメリカってそんなにEAだらけなのかな？
ひょっとしてレアな特殊事例を一般論として売り込まれるだけなんじゃ…
>>844 手続き指向に対してオブジェクト指向はいわば「データ指向」といえる。
オブジェクトのデータ構造はオブジェクト内に隠蔽されているが、手続き自身も
オブジェクト内に隠蔽されているので、この手続きの再利用性が低くなる。
オブジェクト内の手続きを再利用する方法として継承を使うことができるが、
継承はクラス間の関連としては大変密な結合であり、単に手続きを再利用する
ためだけに派生クラスを作成して実装を継承するのは結合度が強くなって
しまうためよくない。
これらに対して、ジェネリック・プログラミングは「アルゴリズム指向」である。
これは、手続きの再利用性を求めて単に手続き指向の世界に回帰したように
見えるかもしれないが、そうではない。
ジェネリック・プログラミングにおける手続き(アルゴリズム)は、手続き指向の
手続きと違い、データの構造は知る必要がない。そのアルゴリズムを実装する
ために必要な操作をオブジェクトから開示してもらうことにより処理を行う。
従って、あるアルゴリズム(手続き)に処理してもらうために必要な最小限の
インタフェースをデータ型から抽出することが、ジェネリックプログラミングを
実現する第一歩となる。
870 ：
デフォルトの名無しさん：04/10/24 13:41:33
>>844 >結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。
ウィンドウシステムを扱うライブラリが非ＯＯだったときのことを考えれ。
871 ：
デフォルトの名無しさん：04/10/24 13:48:36
>>890 >587
>顧客クラスにパスワード変更メソッド付けるなんてアフォ
つまり、データはハッシュマップなりで適当なもので表現して
（実際、形宣言無し言語ではこれが常識）、それを扱うプログラムをクラスとして
定義するのがいいってことで、パスワード変更クラス、ユーザ名変更クラスを作るのは
よい設計ってことやね。（経験積んだ人がシンプルに作ろうとしたら結局そうなる、いうまでもなく）
872 ：
デフォルトの名無しさん：04/10/24 13:52:04
>>871 データを一番シンプルに扱えるのがハッシュマップである以上、
無意味なキャストが頻繁に起こるJavaは業務アプリ作りには向いてない。
型宣言が無い言語のほうが業務アプリ作りには向いてる、Javaは向いてない
っていう仮説はどうかな。
>869
オブジェクト指向は学術的には"手続による抽象化"であって、
抽象データ型(ADT)より手続に近いっていう話しだが
漏れにはその区別がどうも良く解らない
結局メッセージパッシングしてメソッド(==手続)呼び出してるだけって事なのかな。
ADTとはどう違うんだ。
「こんなデータと処理の分離は嫌だ」シリーズを考えてみよう。
データと処理が分離されたCollection API
ｺﾜｰｲ…。
データと処理が分離されたデータベース
877 ：
デフォルトの名無しさん：04/10/24 13:58:43
>>873 結局メソッドを呼び出すのがＯＯ。
オブジェクト指向の肝はポリモーフィズムで、
それでシステムをシンプル（柔軟性と、メンテナンス性を保つ）に表現
するっていう、ただそれだけ。
878 ：
デフォルトの名無しさん：04/10/24 13:59:31
879 ：
デフォルトの名無しさん：04/10/24 14:02:18
>>878 漏れには解決しているようにはとても見えへんのよ
881 ：
デフォルトの名無しさん：04/10/24 14:15:50
ORマッピングで継承って一体なんなんだ？ 意味不明。
データはデータ。処理は処理だろ？
882 ：
デフォルトの名無しさん：04/10/24 14:20:09
処理の切り替えって、やりたきゃやればいいんじゃないの？
884 ：
デフォルトの名無しさん：04/10/24 14:44:58
処理の切り替えが沢山あるなら、
処理できる？
Handler#canHandling(data)
処理が重複したときの優先順位を返す
Handler#priority,
処理する
Handler#handle(data)
みたいのを作って
Manager#addHandler(handler)
てなことやると分離できるな。これが適切なときもあるにはあるだろう
Ruby最高ってことでFA
>>845 「薄いサービス層」の薄いって何のことだか分かって言ってる？
何でツッコミが入ってないのか分からんけど。
>>884 そこまでやって分離したがる理由が分からない。
素直にO/RMapper使って解決できる問題であれば、そうすべきだろう。
↑でも適材適所って言ってるだろ？
>>887 「分離可能」といってるだけじゃないの？
「適切な場合もあるにはあるだろう」だし。
>>888 だね。最後の方良く読んでなかった。ｽﾏｿ。
>>871 890ゲット！！
データはマップで持っておくのがいいかもっていうか、だめっていうか、いいね。
思ってもいないことを言ってみる。
ER図と照らし合わせながらでしか解読できんコードになるぞ。
なんか急激にしょぼいスレに戻りましたね。
＞＞８８７
blogでは、その後ろに「ドメインモデル」或いは「リッチな業務ロジック」が続くと
書いてあります。ドメイン層ですね。
プレゼンテーション層から最初に呼ばれ、適切なドメイン層の処理を呼び出す
ステートレスなクラスというのは、薄いサービス層に他ならないのでは？
ファウラーではなくEric Evansですが。
間違っていたらご教授願います。
以下
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel より引用
アプリケーション層（サービス層のこと）：ソフトウェアが何をしなければいけないかを
定義し、ドメインオブジェクトに対して、問題を解決するよう命令する。この層の役割は
ビジネス活動にとって重要であり、別のシステムのアプリケーション層とやり取りをする
のにも必要である。この層は薄く保たれている。ビジネスルールやナレッジを含むもの
ではないが、その下の層にあるドメインオブジェクトの協調関係に対して、タスクを調整
したり、仕事を委譲したりしている。これはビジネスの状況を反映するものではないが、
ユーザーやプログラムの進捗状況を反映することは出来る。
ドメイン層（モデル層）：ビジネス、ビジネスの状況に関わる情報、ビジネスルールに
ついての概念を表す。ビジネスの状況を反映する情報は、ここで管理・使用される。
技術的には、その情報はインフラ側でストアされている。この層はビジネスソフトウェアの
魂である。
ここでのキーポイントは、サービス層は薄い、という点です（キーとなるロジックは
ドメイン層に置かれています）。
>>892 なんだ、わかってたのね。
つまり、
[ドメインモデル]
UI層 ⇒ 薄いサービス層 ⇒ ドメインモデル ⇒ データアクセス層
[リッチな業務ロジックモデル]
UI層 ⇒ 薄いサービス層 ⇒ リッチな業務ロジックモデル ⇒ データアクセス層
こういうことなら、あのコンテキストで「薄いサービス層」って
言葉が出てくるのも納得できる。
ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
あまり見出せない。
分散環境でも無い限り、ドメインモデルでの薄いサービス層はリッチな業務ロジックモデルに
対応するって方が自然な気がするんだけど、どうでしょう。
>>892 > なんか急激にしょぼいスレに戻りましたね。
禿げ胴!!
S2とも、くーすとも関係なくなった。しかもレベル低い。
OO厨なんてこんなもん
と、OOがわからなかったCプログラマーが申しております。
フォーラムみたいなのがあればなぁって
誰かが言ってたけど、ホントにあったほうがいいような気がする。
2chだとまともに議論にならんことも多いから。
>>893 >ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
>あまり見出せない。
プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。
>>898 > プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
> ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。
素直に考えるとそうなんだけど、実際にファサードが必要になる状況ってそんなに無いよね？
だからそれをスタンダードにしまうのにはちょっと違和感を感じる。
ステートレスなサービス層が具体的に何を想定しているのか、
ひがさん本人に聞くのが一番早いんだろうけど。まだちょっとわかり辛いかな。
ファサードが必要になる状況というか、
普通にデザインしてたらそこはそうするだろ。
EJBを使ったことのある人間なら。
StatelessSessionBeanでサービスを作る必要性がわかる人間なら。。
StrutsのActionクラスに業務ロジックを書くことにためらいがある人間なら。
>>900 StrutsのActionから直接ステートレスな業務ロジック呼び出すのと、
間に無駄なファサード挟むことの違いを言ってるんだが。
ひがさんは「プレゼンテーションから呼び出す（業務ロジックの）メソッドは１つだけ」
と仰ってます。
分散環境でなくとも、各層間のインターフェースはシンプルにしておくのは有効だと思います。
プレゼンテーション層は、StrutsやTapestryなどのフレームワークに密接に依存するため、
テストがしにくいからです。また、各層での平行開発も行えるようになります。
説明が悪いのかな。
900氏の言うように「普通にデザインしてたら」、
StrutsのActionなどに提供される業務ロジックインターフェースの
メソッドは１つだけになる。で、複数必要になるような状況ではファサード挟む。
でも、複数呼び出しが必要になるような状況(つまりファサードが必要になる状況)ってそんなに多いか？
多くないならいきなりActionから業務ロジックのインターフェースで提供されてる
メソッド呼び出すほうが素直じゃないの？って思ったんですよ。
904 ：
デフォルトの名無しさん：04/10/24 18:13:33
>>869 それって、DB毎にアクセス用サブルーチン作って、手続き型してるだけでわ。
かつて、ほぼ並行して2つのやり方をしたプロジェクトがありました。
あるプロジェクトでは、人に業務機能を割りあてました。
データベース設計はある一人が担当し、
他の各人がデータベース―EJB―Web層(Struts)、HTMLをすべて担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、ある程度のレベルまで上昇しました。
メンバに感想を聞いてみると「設計としては汚い。楽なことはなかった」とのことでした。
あるプロジェクトでは、人にシステムの機能を割りあてました。
データベース設計、EJB、Web層(Struts)、HTMLを、それぞれが担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、担当場所についてのみかなりのレベルまで上昇しました。
メンバに感想を聞いてみると「綺麗な設計になってる。実装作業は楽だった」とのことでした。
誰が幸せなのでしょう。
綺麗な設計を手に入れたお客さん。
911 ：
デフォルトの名無しさん：04/10/24 20:32:39
そうこうしている間に.Netが主流に。
Ruby.netが最強だと。
913 ：
デフォルトの名無しさん：04/10/24 21:05:27
薄いサービス層 ⇒ ドメインモデル
とか
薄いサービス層 ⇒ リッチな業務ロジックモデル
これ、何いうてるんですかね。
どうしてもプラットフォーム／言語非依存にしたくてっていう気分でもならないかぎり、
この２つを分ける理由は謎。
Ruby最強・・・かな？
916 ：
デフォルトの名無しさん：04/10/24 21:21:50
正直、ドメインモデル リッチな業務ロジックモデル
の違いも分からん
藻前ら難しく考えすぎだ
>> 916
お前は、きっちり分割されたシステムの一部を仕様通りに
月１５万でコーディングすればいいだけだから、気にするな。
>>917 月１５万でコーディングしてくれるの？
だったらうちで働いてよ。
2人日の価格で1人月か。お徳だ。うちにぜひこないか
うほっ！
か か な い か ？
>>919 あんたのところ高すぎ。
コーダーで月１５０万かよ！
うちの倍とってるじゃん。。。
じゃあRubyのDIコンテナに期待しよう
あるのかな
そろそろ新スレ立ててもいいんでない?
今の流れだと、次スレは必要なさそう。
そうだな。
PoEAAのスレでも立てるほうがよっぽど盛り上がるんじゃないか？
S2ネタはS2JSFｷﾎﾞﾝﾇばっかりだしｗ
927 ：
デフォルトの名無しさん：04/10/24 22:52:43
>>917 >お前は、きっちり分割されたシステムの一部を仕様通り
そんなシステムあるわけないだろボーケー
>> 927
まず日本語から勉強しましょうね～。
929 ：
805：04/10/24 23:05:07
>Statelessな場合は、Ma、Mbに依存関係はありません、と以前書いたのですが、
>実は間違ってますね。m(_ _)m
>ここでいっている依存関係とは、呼び出し順序の依存関係です。
>
>状態Sが更新されない場合は、確かにMa、Mbには依存関係はありません。
>しかし、MaでSが更新され、MbがMaで更新されたことをあてにしている場合、
>MbはMaに依存しているということになります。
Mbが依存しているのは Maじゃなくて、ステートSなんだと思うんだよね。
Maの呼び出しによって、ステートS => ステートSa となるとして、
Mbが当てにしているのは「事前のMaの呼び出し」ではなくて
「Ma呼び出しによってセットされるステートSa」なんじゃないかな?
よって、ステートSを外に出したところで MbがステートSaを前提にしていることには
なんら変わりない、ステートSを中に置こうと外に出そうと何も変わりはない、と。
OOネタはS2というかくーすから転がっていって
ひがさんのブログでの反応とあいまって
こうなったんで、このままここでいいよ。
普通はスレ違いなんだがな。
このスレには優しい人が多いということか。
このスレは次から「国産DIコンテナSeasarの人たちv2」という名前にするべきだ。
そうすれば、今までのこともスレ違いではなくなる。
ダサッ！
>>929 おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
したりできて便利になるような気がするんだけど。
もちろんこれは（現実に広い応用はあっても）トイ・アプリケーションレベルの簡単な
ロジックの場合だけであって、複雑なステートを持つ UI セントリックなアプリケーションが
必要な場合などにはステートを外だしにすることによって情報隠蔽の逆を行ってしまう
可能性もあるわけだけれども (そういう部分をクライアント側に押し付けられるなら有効か・・・)。
比嘉氏はStateはPresentation層に持つって言ってるので
>>935は同じ事を言ってる気がするのだが
>>933-934 「S2のソナタ」にでもしておけばよかろう
正直漏れは次スレいらん気がしてるが
>933
人たちというか、そもそもS2ってそれ自体で何が出来るというものでもなくて
開発を支援する（＝楽にする）ってな発想だと思うので、その流れでくーすときて
じゃ、既存のOOPとか設計ってどうなのよ？って話になってもおかしくないと思われ。
>936
Flash（Flexもだが）やら.NetのSmart ClientみたいなRIA（リッチかどうかはさておき）のWebアプリなら
Presentation層で保持するのでやり易いだろう。
HTMLのブラウザベースのWebアプリだと小細工をせんといかんのだけど
>> 938
そこでS2JSFですよ。
>938
おれ今までsessionとかrequestってプレゼン側領域だと思って
状態の管理にも使ってたんだけど、世間じゃ違うのかな。
小細工ってどんなの？
OOPの話がしたければ、それなりのスレへ。
新しい別のスレをたてる必要はない。
そこではSeasarの話はスレ違いだがね。
Seasarの話、くーすの話、ひがさんはぶさんの話がしたければ、それなりのタイトルのスレ建てれ。
禿同
長文多いしage多いしスレ違い多いし
ハッキリ言ってウザイ
>>935 >
>>929 > おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
> ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
> したりできて便利になるような気がするんだけど。
ドメインロジックを含んだクラスをステートレスにすると、
SmalltalkBestPracticePatternsで挙げられているパターンや、リファクタリングの
テクニックの大半が使えなくなります。
# 数少ない経験に基づいてるので嘘かもしれませんが。
そんな強烈なデメリットを負ってまでステートレスにして得られるものが、
「サービスオブジェクトのプーリング」というのは、
*個人的には*、割に合わないと感じています。
# もちろん、必然性のあるステートレス化には賛成ですが。
「ダイコン時代のスレ」でいいんじゃない？
945 ：
デフォルトの名無しさん：04/10/25 00:34:31
もう分かりきってることだと思うけど、抽象的過ぎてかみ合わない。
アプリケーション毎に違うんだよ。どういうパターンがいいかなんて。
もう漏れは飽きた。寝る。
seasarの話、くーすの話、OOの話、業務の話、
全てはひが様のもとへ、じゃ。
よってこのまま続行。
つか、ここの住人が杓子定規なスレタイ重視によって
分散してしまうのは、しじょーにもったいなく思いまーす。
では違うところに集うが良かろう。
でなければまずはsage進行で頼む。
>943
Cookieゴソゴソしたり、HTTP越しにSessionオブジェクトを弄ぶのはなんか不健康な気がしたので。
勿論、仕方無しにPresentationの役割と思ってやってるんだけど
>941、942
見てるからには何らかの関心があると思うんだが、じゃ、どんな話題なら良いのよ？
大半の香具師はアンチうざいのでsage進行だと思うしさあ。
とにもかくにも嫌なら見ることねえじゃん。君の人生、時間は限られてるんだからさあ。
>944、946
禿同、けど’ダイコン時代’ってキーワードはまだ認知されてないのでスレタイにはどうかなあ。
J2EEに疲れてませんかってなのはどう？けど、アンチJavaの呼び水になるからなあ。
あ、ちなみに自分は.NetもJavaでも楽に儲かりゃどっちでもいいし、どっちも実務でやってるので
宗教論争ならくだらん。
しょっちゅうageてるじゃねえか。
上にくりゃ見えちまうだろうが。
sageくらい覚えろよ。
あと変なポインタ振るな。
長々書き込むな。
正直このスレの住人ウザイ。
2ちゃんにくんな。
J2EEに疲れてませんか、ではくーすの話はスレ違いだね。
>>949 N速にでも逝って２ちゃんらしさを存分に味わっとけ。
次スレはsage進行でマターリと語りたいね。
>>945みたいなアゲにげするやつがいるからねぇ。
じゃ、次はS2JSFでてからってことで解散。
分析から実装まで
開発を見つめるDICON
955 ：
デフォルトの名無しさん：04/10/25 02:17:15
もはや広告が撲滅された以上、sageと入れるのは馬鹿。
そもそも同人板のヲタ女達が始めた風習だし。
風習の起源とか目的とか、どうでもいいだろうが。
いまそういう風習なんだから。
Stateless化することで見込まれているメリットの肝は、実は分業の徹底では
ないかと思う。設計段階でDomain Modelを完璧に固めるのは困難だし、
かと言ってXPみたいにボトムアップでぐりぐり設計が変わるのを許容して
しまうと、チームに馬鹿が一人いるだけでリーダーは安心して眠れない。
そしてある程度の規模の仕事となるとだいたい馬鹿のほうが多数派になって
しまうのが悲しい現状だ。
そこで「馬鹿はinterfaceをいじっちゃいけない」という制約が登場。
次スレ立てるんなら
>>1はガイドラインよろ
sageでﾏﾀｰﾘとか個人名晒した誹謗中傷はなしとかそういうのな
せっかくいい感じになってきたのでﾀﾉﾑ
959 ：
デフォルトの名無しさん：04/10/25 11:28:42
>>957 ペアプログラミングと腐らずコミュニケーション続けることしか解決の道は無い
このままのスレでいいじゃん。
スレタイに「くーす」要追加。
AVAYAのロゴがAYAYAに見えるオレは、なにかに毒されていますか？
次スレはS2JSFが完成してからだね。
関係ないけど、サンプルのHTMLにmetaタグでcontent-type入れるのはかっこ悪いからやめたほうがいいと思われ。
S2JSFだとContentTypeヘッダーを送れないというのなら別だけど。
最も単純な例がXHTMLだとしたら、普通のHTMLは使えないのかと思ってしまう。
ContentTypeヘッダーを送るならmetaタグ入れないほうがいいことになってるから。
>>967 RFC&W3Cﾏﾝｾｰなんだね。
IEおよびNetscapeの特定のバージョン（忘れた）でヘッダだけでは
文字化けする場合があるバグありバージョンがある。
客に文字化けするんだがって言われたらブラウザのバグですって言うの？
まー、客から見たら文字化けしないサイトもあるんだから対応しろボケって
なると思うけど。
970 ：
デフォルトの名無しさん：04/10/27 23:13:06
技術屋がかっこつけようとすると
お客さんの価値観とは合わなくなる事が多く思いますが
よい例でしょうかね。
俺も出来る事なら存分にかっこつけてみたいわ。
969が正解でしたね。
ひがさんてば、こんな事にまで答えてくれるとは・・・・。
>>972 俺は
>>571 です。
ここはエセ技術屋が多いインターネッツですね。
うんこばかりだな。
はいはい
あなたみたいにみんなから尊敬される素晴らしい技
術屋さんには見るもの全てがうんこにしか見えない
んだろうからここに来なくてもいいよ
エセねらーがｲｿﾀｰﾈｯﾂとか書いてんじゃねえよ（藁
お，半角SPACEたんｷﾀｰ(AA略)
相変わらずの粘着ぶりでつね！
metaタグうんぬん言ってた人が
571ってこと？
まあmetaタグがどうのってこだわりがあって
そういうのが技術力だって価値観も確かにアリだと思うけど
そういう価値観の人ならseasarもくーすも要らないんじゃないかな。
571 たんはひがたんよりも自分のほうが優秀なのにひがたんのほうが目立っているので嫉妬してるのでつ
ASM も meta もせっかく教えてやってるのに聞いてくれないのでひがたんはうんこな香具師だと思ってるのでつ
要するに 571 たんはひがたんのうんこが食べたいのでつ
頑張ってイソターネッツとか書いてる 571 たんは本当はいい人なのでつ
ひがさんはいつ仕事してるんだろうか