国産DIコンテナSeasarとくーすその３

1 ：デフォルトの名無しさん：04/12/12 23:37:01

一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。

あと、開発プロセス「くーす」の話題もこちらでどうぞ。

本家 seasar.org
http://www.seasar.org/

Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/

ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/

前スレ
その１　http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その２　http://pc5.2ch.net/test/read.cgi/tech/1098885253/

関連スレ(なのか?)

Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/

2 ：デフォルトの名無しさん：04/12/12 23:43:16

>>1
スレ立て乙。

このへんも関連スレかな。

Dependncy Injectionを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1099827125/l50

Martin Fowlerのスレッド
http://pc5.2ch.net/test/read.cgi/prog/1099814095/l50

Java⇔RDBのMapping-Frameworkを語るThre Vol.3
http://pc5.2ch.net/test/read.cgi/tech/1090653286/l50

3 ：デフォルトの名無しさん：04/12/13 00:37:36

前スレより
>960 名前：デフォルトの名無しさん [sage] ：2004/12/12(日) 18:38:39
>>>957
>むしろ、くーすは上流工程に責務を集中させるから、XP 等に比べて
>その部分の取替え可能性に関するリスクが高い、という見方もあると思うが。

XPについては、俺に仕事くれてる人が採用したがってるんで検討してみたんだけど、
検討してみた結果、この手法は実装フェーズ以降にしか使えないと思った。

というのは、XPでストーリーをタスクに分割する前に、まずはシステム全体のアーキテクチャ、
つまりシステムを何層に分割するのかとか、例外の扱いはどうするのかとか、ログはどうとるのか
とか、全体に及ぶような設計を先にして「今回はこういうルールでやってください」って言っとかないと、
なんだか訳の分からない実装の集合体ができそうに思う。まったく統一感がなくてメンテナンスが
しにくい。
だから、XPでもやっぱり上流行程って必要なんじゃないかな。

で思ったのだが、くーすの流れで言うところの、ロバストネス解析あたりまでを設計チームでやり
こんで、シーケンス図を書くあたりからXPの手法を導入ってしたら案外うまくいくんじゃないだろう
か。業務フロー図一枚くらいをストーリーにして、あとはタスクに分割して実装していくって感じで。

4 ：デフォルトの名無しさん：04/12/13 01:26:27

ま、御託は資源の排他制御が出来るようになってから、な。

5 ：デフォルトの名無しさん：04/12/13 01:39:20

>>3
> だから、XPでもやっぱり上流行程って必要なんじゃないかな。

「アジャイルと規律」を読め。その問題が詳細に検討されてるから。

# 関係ないが、DIスレの213-214ゴールデンコンビを思い出す…。

6 ：デフォルトの名無しさん：04/12/13 09:29:53

>>3
FDDでいいじゃん。

7 ：デフォルトの名無しさん：04/12/13 20:21:31

フロッピーディスクドライブ

8 ：デフォルトの名無しさん：04/12/13 21:02:16

しょせんそのレベルか。

9 ：デフォルトの名無しさん：04/12/13 21:16:01

(・∀・)ﾊｲｰｷｮ

10 ：デフォルトの名無しさん：04/12/13 23:45:19

はおゆんらいらー！

11 ：デフォルトの名無しさん：04/12/14 00:32:16

ほっちゃーん！　ほ、ほーっ、ホアアーッ!!　ホアーッ!!

12 ：デフォルトの名無しさん：04/12/14 02:39:29

うぉーあいにーめん！

13 ：デフォルトの名無しさん：04/12/14 11:50:25

IKEMEN JAPAN !!!

14 ：デフォルトの名無しさん：04/12/14 19:11:25

前スレ>>933さんの提案は残念ながらひがさんの目にとまらなかったようですね。
僕も欲しいし、賛同者>>934さんもいるみたいなので、
ちょっとコード書いてMLに流してみます。

15 ：デフォルトの名無しさん：04/12/14 22:20:42

前スレ934
> update文で「このフィールドひとつだけ更新したい」ってときにもSQL文を書かなくてすむ。

これってむしろS2Dao側で属性ごとにダーティーチェックして対応してくれるのが
正しい気がするんだが。現状のS2Daoってそういうことやってないの?

教えて君でスマソ。

16 ：デフォルトの名無しさん：04/12/15 00:14:08

いやマジで、「このカラムにシステム時刻を入れたいだけなんだよ」とか「このカラムの
フラグをオンにしたいだけなんだよ」とかいうときに、いちいちSQLファイル作って、
ARGSアノテーション書いてってのが邪魔臭い。

別に対した手間じゃないんだろうけど、でも全カラム一斉UPDATEがわずか一行で
定義出来るのに、それより短いSQL文のためにSQLファイルをつくんのかよ....orz
という気分になってしまう。

17 ：デフォルトの名無しさん：04/12/15 08:09:54

>>16
もしかして１項目変更するのが全項目変更するより簡単な処理だと思ってるの？

18 ：デフォルトの名無しさん：04/12/15 08:20:15

今回のスレは「その３」の３が全角になったんだね。

>>17
確かにクエリを組み立てる側の制御は組み立てるクエリの長さで決まるわけじゃないからねえ。
だから、ARGSアノテーションとかが必要になるんだと思うんだけど。
16は仕組みをあまり分からず書いているのかもしれないけど、
そういうユーザーの要望の中から対応すべき要望を抽出して対応することによって
ツールとかは熟成されていくんだと思うよ。

くだらなくても要望出さなかったら作者の必要な機能ばかりのツールになってしまうからね。

19 ：デフォルトの名無しさん：04/12/15 10:11:14

S2Daoって、BLOB型とかの値は取り出せないの？

20 ：デフォルトの名無しさん：04/12/15 11:20:18

>>16の「大した手間じゃない」はS2側の内部処理ではなくて、
自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？

まぁ、いちいち噛み付かずに
>>17さんの言う通り、
ちょっとづつでも要望出してちょっとづつでも良いツールになっていってもらおうよ。
僕は一応、ソースのどの辺いじればよいのか調べています。

21 ：デフォルトの名無しさん：04/12/15 12:01:45

>>20
>>>16の「大した手間じゃない」はS2側の内部処理ではなくて、
>自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？

そうです。
短いSQLのためにSQLファイルを作るのが面倒だという話です。

S2Daoは「UPDATE テーブル SET PK以外のカラム全部 WHERE PK」ってなSQLを自動生成
してくれるけど、「PK以外のカラム全部」を特定のカラムだけにするのにSQLファイルを書く
のがね。

SQLを一行書いたファイルを作るだけなんだけど、「PK以外のカラム全部」のカラムが２０個
だったりしても長いSQLが自動生成できるのと比べてしまうと、たった一つのカラムのために
SQLファイルを書くのが面倒に感じまして。

22 ：デフォルトの名無しさん：04/12/15 12:43:05

update_PERSISTENT_COLUMNS = "hoge";

だって。よかったじゃん。
tp://d.hatena.ne.jp/higayasuo/20041215

23 ：15：04/12/15 14:32:48

間に合わなかった＿|￣|○ つか、対応してくれるんだ！

こういうところもS2が好きな理由です。

24 ：14：04/12/15 14:34:01

ごめん、間違えた。>>23は漏れ。
騙った訳じゃないのでゆるしてちょ。

25 ：15：04/12/15 16:40:25

いやゆるさん！

26 ：14：04/12/15 17:13:10

｡･ﾟ･(ﾉД`)･ﾟ･｡ｳﾜｰﾝ

27 ：21：04/12/15 17:32:06

>>22
感激だっ。ありがとうひがさん....

28 ：デフォルトの名無しさん：04/12/15 17:45:05

見てるとは思うけど、お礼コメントしてきたらよいかも。

29 ：デフォルトの名無しさん：04/12/15 19:48:28

お礼だけのコメントは情報量ないから止めた方がよくないか？
お礼がズラズラと並んでる図は信者臭くてダサいし

30 ：デフォルトの名無しさん：04/12/15 19:54:15

お礼と一緒に喧嘩も売るとか

31 ：デフォルトの名無しさん：04/12/15 20:57:55

趣味悪いなー

32 ：デフォルトの名無しさん：04/12/15 23:55:56

「ひがたん、乙」とだけ書いてくればいいのではないか？

33 ：デフォルトの名無しさん：04/12/16 08:04:25

とっておきのエロ画像とか貼るのがいいのではないか？

34 ：デフォルトの名無しさん：04/12/16 09:26:24

蛯○友里の愛顧らなどがよろしいかと。

35 ：デフォルトの名無しさん：04/12/16 09:30:25

AOPをフルに使用したコラが良いと思われ。

36 ：デフォルトの名無しさん：04/12/16 22:51:45

最近大きな変化は無いね。

早く、事例集を作らないかなあ。
実績がはっきりしてナイト採用しないところもあると思うんだけどねぇ。

37 ：デフォルトの名無しさん：04/12/16 22:53:29

>>36

ネタに騙されてるよ

38 ：デフォルトの名無しさん：04/12/16 23:48:52

>>37
ネタ？
MLでの導入事例集作成のやり取りのことですか？

39 ：デフォルトの名無しさん：04/12/16 23:50:02

ひがさん仕事はやー。ちょっと追いかけるの休んでると、どんどん機能がリリースされてく。
つーかおれ、未だにAOPの使い方がよくわかんね。コンテナ機能だけでも便利だからいいけどさ。 orz

40 ：デフォルトの名無しさん：04/12/17 00:31:59

AOPつかわねーと意味ねーじゃん。

41 ：デフォルトの名無しさん：04/12/17 00:42:59

AOP使わないとS2Dao使えないし、自動トランザクション制御使えないし、
モックオブジェクト使えないし、デリゲートも自動でできないんだぞ。だめじゃん。

42 ：デフォルトの名無しさん：04/12/17 01:02:00

>>39
とりあえず、ドキュメントどおりにdiconファイルに記述すればOK

43 ：デフォルトの名無しさん：04/12/17 15:24:17

マジレスすると自分で考えてAOPを使うのが難しいってことだろ。
考えながら付属のやつを使ってりゃそのうちinterceptorを自作するようになるさ。

44 ：デフォルトの名無しさん：04/12/17 21:38:25

http://d.hatena.ne.jp/higayasuo/20041217#1103278289

> SQLを自動生成したり、Beanからバインド変数を組み立てたりという仕事は、
> これまで、BeanMetaDataにさせてました。データのことを最も知ってるクラスに
> 振る舞いを持たせるのは、自然なことだと思っていたためです。
>
> しかし、S2Daoに仕様の追加があるたびに、BeanMetaDataに変更が入るのです。
> メタ情報は全く変更されていないのにもかかわらず。

SQLの自動生成ロジックの変更によって、メタ情報に変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?

バインド変数組み立てロジックの変更によって、メタ情報の変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?

どちらも何の問題もないように思いますが。

45 ：デフォルトの名無しさん：04/12/17 21:53:31

> これは、BeanMetaDataに多くの責任を持たせていたためです。
> SQLを自動生成したり、Beanからバインド変数を組み立てたり
> という役割は、メタデータを管理するというBeanMetaDataの
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。

それは単に責務の割り当て方が適当でなかったために

> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。

と感じるのだと思いますが。

例えば

BeanSchema.toXML

のようなメソッドはBeanMetaDataクラスに持たせるべき責務のように
思えます。

46 ：デフォルトの名無しさん：04/12/17 21:55:32

> 振る舞いを役割ごとに分割する、言い方を変えると振る舞いを
> モデリングするという考えは、重要ながらかなり見落とされている
> ことが多いのではないでしょうか。

よくわからないので、
具体的な例を挙げていただけませんか?

47 ：デフォルトの名無しさん：04/12/17 22:03:48

SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
べきだった、という話じゃないの？

で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。

その点についてはおれは反対する要素はないぞ。

48 ：デフォルトの名無しさん：04/12/17 22:13:39

>>47
> SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
> メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
> べきだった、という話じゃないの？
>
> で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
> するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。

うんにゃ、
ひがさんは BeanMetaDataには振る舞いを持たせるべきではない、と言っているよ。

49 ：デフォルトの名無しさん：04/12/17 22:31:17

>>46
ここではなくてblogのコメントに書いていただけませんか？

50 ：デフォルトの名無しさん：04/12/17 22:33:40

> 永続化されるデータに業務に応じた振る舞いを持たせるというのは、
> 1つのクラスに複数の役割を持たせることになります。

なりません。

データは何一つサービスを提供しません。
よって、データは責務を持ちません。

51 ：デフォルトの名無しさん：04/12/17 22:33:41

そりゃおかしいだろう。
S2Daoのソース読んだわけじゃないから詳しいことは分からんが、
少なくとも>>45には激しく同意。
Object指向としての理想的なモデリングは、SwingとかEclipseなんかが
参考になるとは思うんだが、その中にデータを表すってだけの
構造体みたいなクラスは見当たらんよね。ま、ドメインが違うじゃんって
いわれればそれまでだけど。
くーすはどうも退化としか思えないんだよね。
目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
柔軟性や多態性なんかが損なわれてる気がする。

52 ：５１：04/12/17 22:34:29

ごめん、51は>>48に対するレスね。

53 ：デフォルトの名無しさん：04/12/17 22:48:37

>>51
目先のお手軽さや便利さを求めちゃ何故まずいんだろう？

それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。

オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。

お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの？

54 ：46：04/12/17 22:49:04

>>49
そんな度胸ありません！

55 ：デフォルトの名無しさん：04/12/17 22:49:13

>>51
> くーすはどうも退化としか思えないんだよね。
> 目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
> 柔軟性や多態性なんかが損なわれてる気がする。

同感です。
結局は、前々スレの686の一言につきると思う。

>686
> くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
> (予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
> 決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
> Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
> カバー、的な。

56 ：デフォルトの名無しさん：04/12/17 22:52:30

ヒガ氏はああいう書き込みで燃料投下して
そのBlogに対する書き込みをニヤニヤして読んでると思われ。

必死で書き込んでる奴らは
ヒガ氏の掌で踊らされているだけだということを
自覚したほうがいいな（藁

57 ：デフォルトの名無しさん：04/12/17 22:55:14

44=46=48!=54ですが。

>>54
> >>49
> そんな度胸ありません！

そのとおりですw

58 ：デフォルトの名無しさん：04/12/17 22:58:15

>>55
みなさんはいい部下をお持ちのようですね。
うちは素人だらけなので後ろ向きな方法論で結果を出すしかありません。
しかも、各自で技術力を向上させようとする前向きさも、センスもない連中が山ほどいます。まじで皆さんがうらやましいです。

59 ：58：04/12/17 23:00:23

>>58
誤　後ろ向きな方法論で結果を出すしかありません
正　後ろ向きな方法論を利用してでも結果を出すしかありません

．．．ま、大してかわらねーか。

60 ：デフォルトの名無しさん：04/12/17 23:01:04

>>53
> >>51
> 目先のお手軽さや便利さを求めちゃ何故まずいんだろう？
>
> それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。
>
> オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。
>
> お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの？

それについては否定はしないけど、それはビジネスの話。

技術者ならくーすの技術面について話をしようぜ。

61 ：デフォルトの名無しさん：04/12/17 23:06:45

技術の世界でスキルのない人間使ってそれなりの成果物をあげることは、かなり
技術者よりの話題だと思うんだが。

まあみんな分かってるとは思うけど、くーすでいっていることは、すげえ新しいことでは
なくて、いままでビジネスの世界で生きてきた人が経験として得てきた知識と言うかノウハウ
（ともかくこの低スキルどもにコーディングをさせてこの仕事仕上げないといけないんだよ！、
とかいうやつ）だよな。それを手続きとしてまとめたもんだ。

で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
づけしたもんなんだし。

62 ：デフォルトの名無しさん：04/12/17 23:12:21

ひがさんの「BeanMetaDataには振る舞いを持たせるべきではない」という方針は
現場の事情で、その対価としてOOP的な「柔軟性や多態性なんかは損なわれて
いる」という結論でいいんですか？本当に？

アホでも素人でも妄想でも語れる現場話にしたい人は置いとくとして、エンジニア
の人達はこの結論でいいの？本当に？

63 ：44：04/12/17 23:13:21

>>61
>で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
>呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
>づけしたもんなんだし。

それ自体は否定しないし、これらをまとめあげようとするひがさんは偉大だと思う。

ただ、的外れな指摘で「レガシーなオブジェクト指向」とかいうのはやめて欲しい。すごく迷惑。

64 ：デフォルトの名無しさん：04/12/17 23:17:26

要するに、
ヒガ氏の提唱しているのはビジネス的な視点での方法論で、
ここで書き込んでる人たちはビジネス的は視点としては理解はできるものの
技術的な視点で話をしたいと。

それじゃ、話が合うわけねーじゃん。
つーか、なんでそんな人たちがヒガ氏やらくーすやらに興味持ってるのかさっぱりわからん。

65 ：デフォルトの名無しさん：04/12/17 23:19:53

>>60
くーすの技術面？

くーす語るんだったら技術面じゃなくて
ビジネスでの有効性だとかそういう話じゃないの？

66 ：デフォルトの名無しさん：04/12/17 23:29:51

とりあえずハッキリしてるのは、ヒガ氏の実装で得られる利点と、損なわれる難点を
技術的に語れる人間はこのスレには居ないって事だ。

それはそれで構わないと思う。そこは所詮２ちゃんだし？
重要なのは、このスレがヒガ氏へのＱとして機能し得るか否かって事だ。

何が言いたいかって言うと

ヒガ様、手隙の時で構いませんので、その辺をBLOGの方で技術的に解説よろ

って事だｗ

67 ：44：04/12/17 23:30:55

>>64
> 要するに、
> ヒガ氏の提唱しているのはビジネス的な視点での方法論で、

くーすの言う、DTOとかStatelessBusinessロジックはビジネスの話だと。
はあ、そうですか。

って、んなわけねーだろ。

68 ：デフォルトの名無しさん：04/12/17 23:31:44

>>62
いや、ひがさんの日記は、BeanMetaDataに振る舞いを「もたせるべきではない」という
話ではないだろ。BeanMetaDataはメタデータの管理（に直結した振る舞い）だけをすべき
だったのに、SQL自動生成とか関係ない振る舞いを持たせてしまった、という話だろ。

振る舞いとデータを分離するといってるんじゃなくて、「データにやまほど振る舞いをつけた
くなったとき、その振る舞いがデータと直結してるかどうかちょっと考えてみろ」っていって
るんだと思うけど。

まあ俺が思うのは、データに直結してないけど、そのデータを利用する機能を山ほど搭載
したFatなクラス設計（モデリング？）というは、「レガシー」なんではなくて、そんなものは
始めからオブジェクト指向の原則に反してるだろ、ということだな。

それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
かなり微妙だし、俺も正直言って間違うよ。

データと振る舞いをまとめるときに、「データと直結した振る舞いを持たせる」「データをつかった
ほげほげは別にする」というのはオブジェクト指向的には正しい判断じゃないか？

69 ：デフォルトの名無しさん：04/12/17 23:33:15

>>67
ああ、それ自体は技術の話題だ。
でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。

70 ：デフォルトの名無しさん：04/12/17 23:42:39

>>69
> >>67
> ああ、それ自体は技術の話題だ。
> でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
> 技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。

もしそうっだったとしたら、なぜひがさんは
従来のオブジェクト指向を「レガシー」と言って技術的に批判するの?

71 ：デフォルトの名無しさん：04/12/17 23:45:04

おれは言ってる事はともかくとして、「レガシー」という表現を使ったことについてはおかしいと思う。

ここでレガシーと言われているものって、レガシーなんじゃなくて、そんなのはもともとオブジェクト指向的に
間違ってるんだし。

72 ：５１：04/12/17 23:52:15

>>66
いや、別にくーすに従わなきゃS2使ってバリバリにOOPなシステム作ることは
可能なわけよ。だからひが氏の実装自体には問題ない。むしろ素晴らしいと思うよ。
問題なのはくーすだよ。ただ、心配してるだけなんだけどね。
マジョリティとしての技術の方向性っちゅーのかな。それがこの先どうなっちゃうのか、とか、
くーすによってさらに加速されるであろう量産型低スキルエンジニア達の増産とか、
そいつらと一緒に、これからも仕事していかなきゃならない自分の身の振り方とかを。
ビジネス的にはそれでいいだろうけどさ、長期的に見て、まず「人」は育たないよな。
だから前々スレ686の一言に尽きるって結論になっちゃうんだけど。

ま、「レガシー」って言っちゃったのは失言でしたってこった。
どれだけ多くの人たちがあなたのBlogをチェックしてんのか忘れないでね。>>ひが氏

73 ：デフォルトの名無しさん：04/12/17 23:58:38

しかしまあ、正直言って「importって何の意味があるんですか」「java.langはimportしなくちゃ
いけないんですか」とか聞く奴が毎年量産されていることを考えると、そいつらと一緒に仕事
していく手法を身につけとかないといけないってのは切実な問題かもしれん。

だって毎年量産されるんだし...

74 ：デフォルトの名無しさん：04/12/18 00:06:55

いやぁ、くーすはともかくとして、Seasarは明らかにシステム構築の敷居を高くしているよ。
いろいろ覚えることあって大変だ。何がどういう役割を持っていてどう扱うのが正しいのか、
原作者にしか分からない理論（しかも、漏れ的には相当あやしい）を理解するのに何年かかるんだ。
そして覚えてそれで一体何になるのか。謎は深まる。

75 ：デフォルトの名無しさん：04/12/18 00:07:53

何年って、おれは使い始めて１ヶ月後にはチームの連中に説明してたが....

76 ：デフォルトの名無しさん：04/12/18 00:08:23

くーす周辺の「お客様」とか「現場」は、目の前の客と現場に部分最適化して、
将来の客と現場に対する思考を停止するためのエクスキューズ用語。

77 ：デフォルトの名無しさん：04/12/18 00:09:26

さらにチームの連中は「Struts覚えるより仕組みが簡単ですね」とか言ってたが....

78 ：デフォルトの名無しさん：04/12/18 00:14:24

独自の複雑なフレームワークを駆使した開発方法を
示して難解フレームワーク固有の知識で壁を構築するっていうのは、
よく見かける手ではあるけどね。

シンプルな解決法は他にいくらでもあるのに。
本当にいいものは分かってもらおうという迫力が文章やコードで示されてる
のだけど、Seasarは・・・、まぁ、しょうがないな。

79 ：デフォルトの名無しさん：04/12/18 00:14:55

>>68
なんか凄い自信家ですねｗ

＞＞それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
＞＞かなり微妙だし、俺も正直言って間違うよ。
この辺に自惚れさが見え隠れしているように感じられるのは気のせいでしょうか？

80 ：デフォルトの名無しさん：04/12/18 00:16:07

>>77

そうだな。Strutsよりはマシかもしれん。
Strutsも大いなるネタの代表例でさ、あれよりいいってうのは、
果たして。大差は無いように思う。

81 ：デフォルトの名無しさん：04/12/18 00:17:35

なんかわからんが、Seasarはファクトリ＋AOPだし（というかDIコンテナは大体そうだわな）、
くーすはWeb開発ノウハウの集合体であって、別に独自のフレームワークや固有の知識だと
思った事ないんだが。むしろ「あーたしかにそんな感じでやってるよ」ってくらいで。

逆にその「まとめよう」というところに価値があると思ってる。

82 ：デフォルトの名無しさん：04/12/18 00:21:20

すごい勢いでレスがついてますね。
みんな比嘉さんにもてあそばれてるなあ。

しかし、「レガシー」って括られるとそりゃ頭にきますよね。
みんな最先端を走ってるつもりなんですからねえ。
そう書けばここで盛り上がるのわかって書いてるのに
予想通りの盛り上がりを見せてるのはちょっと笑えるね。

しかし、Blogで２ちゃんのスレに煽りを入れて、
こんなにたくさんの人が踊らされるなんて、さすが比嘉さん。

83 ：デフォルトの名無しさん：04/12/18 00:24:31

むしろひが氏のネタの半端さがレスを呼んでるんじゃないの。
DIスレの213=332と同様。厨がいたほうが一見盛り上がってるように見える罠。

84 ：デフォルトの名無しさん：04/12/18 00:28:13

>>82

そうか。やっぱり、ネタだったのか。
くそー、悔しい。
まぁ、そりゃそうか。
でも、本当にイカンのはマジなトーンで
DIコンテナORマッピングAOPとか言ってるやつらだぞ。
思わず反応してしまう・・・

85 ：デフォルトの名無しさん：04/12/18 00:29:47

まあ自分の主張を目立つように書こうとしてつっぱしり過ぎたってとこだろう。
もし本気でレガシーって思って書いてたら、S2自体の価値が疑われかねないので、
調子のって突っ走ってしまったと思いたいね。

まあ一方で、データと振る舞いの組み合わせ方は微妙な判断が必要な問題だ
と思う。その判断を卒業したてのＰＧに任せたくはないが、やらせないと低能の
ままの奴と付き合い続けなければいけないというジレンマに...

86 ：デフォルトの名無しさん：04/12/18 00:31:45

>>84
ほんとにもてあそんぶためのネタとしてレガシーなんて言ったんだとしたら、S2に対する指示を
失いかねないネタだと思うぞ。

おれは勢い余ったんだと思うけどね。

87 ：デフォルトの名無しさん：04/12/18 00:33:57

指示＝支持

88 ：デフォルトの名無しさん：04/12/18 00:39:08

とりあえず呼んどくか。

　　☆ ﾃｨﾝ

　　　　　 ☆　ﾃｨﾝ　　〃　 ∧＿∧ 　／￣￣￣￣￣￣￣
　　　　　　ヽ　＿＿_＼（＼・∀・）＜　ﾋｶﾞﾀｿ消火まだー？
　　　　　　　＼＿／⊂　⊂＿)＿＼＿＿＿＿＿＿＿
　　　　　　／￣￣￣￣￣￣￣／|
　　　　　　　　| ￣￣￣￣￣￣￣:|　:|
　　　　　　　　|　　　　　　　　　　　.|／

DIスレをリスペクトして「ﾃｨﾝ」だ。

89 ：デフォルトの名無しさん：04/12/18 03:15:01

結論：やっぱEJB。

90 ：デフォルトの名無しさん：04/12/18 12:01:40

>>89

EJBが実は最も壮大なネタで、
それよりマシなものなら「漏れにも作れる！」
と思う香具師、たくさんいるんじゃないかね。
しかし、EJBよりマシなものできたところで、
EJB自体がネタだから、どっちにしろネタなのだ。

91 ：デフォルトの名無しさん：04/12/18 13:32:36

似た方向を目指しててそれぞれ一長一短なモノなら、
メジャーな手法を使うのは当然だよな。

92 ：デフォルトの名無しさん：04/12/18 13:32:51

ふ～ん

93 ：デフォルトの名無しさん：04/12/18 16:16:25

まあ、Java自体がネタだからね。

94 ：デフォルトの名無しさん：04/12/18 16:29:36

>>82
レガシーっていってるのは、1つのクラスが役割を複数持ってる
ような設計のことでしょう。
これまでのオブジェクト指向がすべてレガシーっていってるわけじゃない。

ナイーブって言い方に変わってるね。

95 ：デフォルトの名無しさん：04/12/18 16:55:10

ダイコン書くのだるい。。。ってか、ファイルが分散するのって
正直どう思ってるんだろう。S2Struts使うとStrutsConfとダイコンも
書かなきゃいけないし。
特に全体を追おうとするときって、目茶目茶だるい。EclipseでCtrl+クラス
で実装開いてくれるけど、インターフェース使ってると
インターフェース開くから、ダイコン見て実態クラス見てって。。。
書いてる本人は分かるから良いんだろうけどさ。

あと、お客に技術トランスファーしなきゃいけないのに
Seaser使っちゃって（一緒にやってる人がね）、おいおい
お客さん（IT企業じゃないないシステム課の人）
に分かるように説明できるのーって感じ。

やっぱりね、Seaserに限った事じゃないけど楽になるだろうって思って
使うのは、全体的に見て楽になるかを見ないといかんね。

96 ：デフォルトの名無しさん：04/12/18 16:58:01

でも

＞＞この「ナイーブ」は当然 (？) without EJB のアレ (笑) です．幼稚・稚拙というニュアンス．

だそうですから。

97 ：デフォルトの名無しさん：04/12/18 17:03:26

DIっつっても、DIで作られたクラス使う分にはただのファクトリなんだし
対して技術的に難しい概念ってことはないと思うが。

98 ：95：04/12/18 17:14:31

>>97
>技術的に難しい概念ってことはないと思うが。
OOで一回でも作った事がある人は難しいとは思わんとだろうけど
お客はそうじゃないし。

DBAがプログラム中にSQLがあるのとO/Rマッパ使ってるときとで
インパクトが違うのとにてるんでないかなーと。

99 ：デフォルトの名無しさん：04/12/18 17:30:32

>>95
実装を意識する必要はないというやり方ですからね。
気にするのは、インターフェースであり実装ではない。
実装はブラックボックスで良いと思う。

100 ：95：04/12/18 17:41:08

>>99
じゃあ、あるデータ項目を追加したいって場合は
実装はいじらせないって事？

101 ：デフォルトの名無しさん：04/12/18 17:55:38

>>95
プロジェクトで役割を明確にしろよ。
みんながみんな実装のロジック見るわけじゃないだろ。
なんのためのインターフェースだと思ってる？
てか、Saesarをどうのこうの言う以前にOO開発できないでしょ。
そんな考え方じゃ。

102 ：デフォルトの名無しさん：04/12/18 18:00:55

ソフトウェア開発の基本が分かってない人↑

103 ：デフォルトの名無しさん：04/12/18 18:01:06

>>100
ちゃんと設計しろよｗ

104 ：デフォルトの名無しさん：04/12/18 18:02:56

設計は絶対に変えない。これがくーす。

105 ：デフォルトの名無しさん：04/12/18 18:08:35

>>102
基本を教えてください。

106 ：デフォルトの名無しさん：04/12/18 18:11:25

>>102
基本？
それってあんたのMY RULEのこと？

107 ：デフォルトの名無しさん：04/12/18 18:34:12

ここは貧血症君とレガシー君が互いに罵倒し合うスレですか。
そうですか。

108 ：デフォルトの名無しさん：04/12/18 18:35:58

>>107
そうですよ。
傍観者は書き込まないでください。

109 ：デフォルトの名無しさん：04/12/18 18:42:10

>>95
「interface開く～ interfaceのタイプ階層を見て実装クラスを開く」
って2段階になるのがうざいよね。

IDE側に、interface名にカーソルあわせて「実装クラスを開く」
みたいな機能が欲しくなる時がある。実装クラスが一つの場合は
そのまま実装クラスのソースを開き、複数ある場合はドロップダウンで
選択とか。

110 ：デフォルトの名無しさん：04/12/18 19:25:36

ここ読んでておもうのは、もしかして本当にモデルオブジェクト（ここで想定しているのは、
S2Daoが返す、テーブルに対応したBeanとか）にいっさい振る舞いを持たせなくて、
setterとgetter以外あってはいけないとか思ってる人が多いのか。

そりゃ貧血症どころか構造体にすぎんじゃないか。

おれはモデルにほとんど機能は実装しないが、それでもそのモデルに直接関わる機能
（モデル内のインスタンス・フィールドだけで処理が片付いてしまうようなもの）はモデルに
実装するぞ。複数のモデルが絡んでくるようなものはサービスにまわす。貧血症ぎみの
クラスは多いが、それでも構造体よりはましだと思う。

111 ：デフォルトの名無しさん：04/12/18 19:51:10

>>110
前スレの後半で俺も似たようなこと言ったんだけど、
構造体として使うのがくーすらしいよ。

つーかドメインオブジェクトが何かって事をそもそも理解されてないようだから、
このスレの"ナイーブOO指向好き"と論点が噛み合わないんだよな。
複数業務にまたがるロジックがあるからこそドメインオブジェクトが存在してるんだろうに。
あれだけ、でかでかともっともらしいことを書くんなら、せめてもうちょっと
OOについての理解を深めてからにしてもらいたい>>比嘉氏

112 ：デフォルトの名無しさん：04/12/18 20:28:05

ここはHDataSetのサポートをしてくれるスレじゃないんですか。
そうですか。

113 ：デフォルトの名無しさん：04/12/18 20:29:53

>>111
ttp://d.hatena.ne.jp/higayasuo/20040801#1091337811
> OOPの良さは分かったけど、OOA,OODってよくわからんと思ってました。
> プログラミングのスタイルも我流で、適当にクラスを作っていただけです。
> 心がけていたのは、メソッド全体を一度に画面で確認できるくらい
> 小さいものにすることだけ。

114 ：デフォルトの名無しさん：04/12/18 20:30:44

人が育たないって主張に対するレスポンスがないな

115 ：デフォルトの名無しさん：04/12/18 20:59:21

>>109
ほれ
http://eclipsewiki.net/eclipse/?Implementors%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3

116 ：デフォルトの名無しさん：04/12/18 21:34:57

>>114
自分で勝手に育っていく奴以外はほっとけ。
そんなことに金かけてる時代じゃねーんだよ。

ま、あんまりたくさん育っても任せる仕事がとってこれないから
くーすみたいなのでできない奴をうまく使いつつ、
勝手に育った奴に仕事任せていけばいいんじゃない？
育たない奴はいつまでもプログラマ。か、別の業種で頑張ればいいんじゃないか？

一般的な会社組織ってピラミッド型になってて、
成長していくとピラミッドがでかくなってしまうよね？
でもピラミッドの上方（高給取り）の比率を高くしないように
ピラミッドの形を維持していかなければならないから、
実はみんなに育たれちゃうと困るんだよね。
（全体の人件費を抑えざるを得なくなってしまうから）

日本の高齢化社会の年齢構成みたいに高給の人間の比率が多い組織になると
収益率を上げていくのは大変だからね。

117 ：デフォルトの名無しさん：04/12/18 23:01:46

ドメインオブジェクトと永続オブジェクトを分ける話じゃないんですね。

118 ：デフォルトの名無しさん：04/12/18 23:55:39

サービス層はドメインオブジェクトじゃないのか？
データアクセス層を純粋にデータアクセスだけに特化させることはＯＫな感じもする。
つまりDBからデータを取ってくる以外のロジックは存在しないただのBeanって感じで。

119 ：デフォルトの名無しさん：04/12/19 00:29:37

結局、エンティティBeanのショボイ奴か。

120 ：デフォルトの名無しさん：04/12/19 02:32:35

くーすは名前を返上すべし。
熟成とは縁のないファストフード作りのマニュアルじゃん。

121 ：デフォルトの名無しさん：04/12/19 05:13:06

http://d.hatena.ne.jp/higayasuo/20041218#1103335335
> 問題は、ドメインオブジェクトに業務ロジックを追加するのが、
> ナイーブかどうかということです。
>
> 私の経験からするとドメインオブジェクトが複数の業務で
> 使われるということは良くある話です。
> 複数の業務の業務ロジックを1つのドメインオブジェクトに
> 持たせるということは、単一責任の原則に違反しています。
> クラスを変更する理由が複数あるためです。

複数の業務の業務ロジックをドメインオブジェクトへ
持たせたとしても、単一責任の原則には違反しません。

「業務Aの機能と業務Bの機能をドメインオブジェクトDへ持たせている」

と考えると単一責任の原則に反しているように見えますが、

「ドメインオブジェクトDの機能を使って、業務Aの機能と業務Bの機能を実現している」

と考えれば、Dの変更理由は常にひとつです。

よって、

> 問題は、ドメインオブジェクトに業務ロジックを追加するのが、
> ナイーブかどうかということです。

は「ナイーブではありません」が結論。

# ちなみに「単一責任の原則」はアジャイルソフトウェア開発の奥義に
# 載ってます。いい本ですよ。

122 ：121=44：04/12/19 05:28:10

べつに、DomainDrivenDesignを否定しなくてもいいとおもうんだけどね＞ひがさん

くーすのネーミングの理由を聞かれたakonが
> 車輪の再発明ではなく、昔の道具でも使い方しだいで対応できるという心をこめてのネーミングです。
って言ってることですし、手続き型上等、TransactionScriptマンセーと開き直ればいーじゃない。

123 ：デフォルトの名無しさん：04/12/19 05:39:07

それにしても、オブジェクト指向じゃないくーすに(21世紀の手続き型なんでしょ)ナイーブなオブジェクト指向とか、レガシーなオブジェクト指向とか言われたくない。

124 ：デフォルトの名無しさん：04/12/19 05:44:32

>>114
>人が育たないって主張に対するレスポンスがないな

くーすは人を成長させるとことにフォーカスしてないからしょうがないよ。

人を成長させるってことなら、XPが一番だな。とくにペアプロが効果大。

125 ：デフォルトの名無しさん：04/12/19 07:49:55

>121
それは設計によるだろ。

126 ：デフォルトの名無しさん：04/12/19 08:36:39

くーすを好みそうな人たちのいる組織もたくさん思い当たる。
俺はそこがいやで転職したわけだが。

127 ：デフォルトの名無しさん：04/12/19 09:52:23

>>126
くーすやSeasarを使おうが使うまいが、
力のない会社にプロジェクトは失敗はついて回るでしょうし、
くーすやSeasarを使おうが使うまいが、
力ののある会社はそつなくプロジェクトを成功させるでしょうね。

128 ：95：04/12/19 10:58:20

>>101
あー、開発段階の話じゃないのよ。
納品して、お客さんがちょっとカスタマイズしたいって場合ね。
もちろんサポート外になるのは、こっちもお客も同意済み。

>>115
さんきゅー

129 ：44：04/12/19 11:32:42

http://d.hatena.ne.jp/higayasuo/20041218#1103335335
> 私がいっているのは、データと振る舞いをカプセル化するという
> 考えは、オブジェクト指向の重要なポイントですが、単純に
> データに振る舞いを追加するのではなく、そこに、クラスは
> 1つの役割だけを担うようにするという視点を必ず持つように
> しましょうということです。

これは分かるのですが、これを理由に

>役割ごとにクラスを分割するという観点で考えると、
>
> * 永続化されるデータを管理するクラス
> * データベースにアクセスするクラス
> * 業務ロジックを扱うクラス
> に別れるというのは、理にかなったことだということが
> 分かると思います。

という結論が導き出される理由が分かりません。

「データを管理」や「業務ロジックを扱う」などはクラスの役割とするには低レベルすぎますし、曖昧にすぎます。

以下はjunitのjavadocから抜き出したものですが、

-TestResult
A TestResult collects the results of executing a test case.
-TestSuite
A TestSuite is a Composite of Tests.

役割というのは上記のような粒度のものであって、データの管理や業務ロジックを扱う、などはその内に含まれるものです。それ単体で役割として考えるべきものではありません。

130 ：44：04/12/19 11:36:47

>>127
よく分析麻痺、設計麻痺に陥ってるプロジェクトがあるけど
そういうプロジェクトにはくーすの割り切りの良さはスゴク効果的だと思うな。

131 ：デフォルトの名無しさん：04/12/19 15:22:18

>>121
その論理が成り立つなら、どんなクラスでも単一責任の原則に
違反することはない罠。
あるクラスの機能を使ってるといえば良いんだから。

132 ：デフォルトの名無しさん：04/12/19 16:18:08

>>127は会議で話題をループさせるタイプだ。
間違いない。

133 ：デフォルトの名無しさん：04/12/19 17:55:31

>>95
S2ActionServletとかRegistActionClassPlugInを使えば
Actionに関しては全くダイコンを書かなくても大丈夫だよ？
ファイルの分散も気にならなくなり、
さらに金運も上がって女の子にもモテモテでウハウハです。

ActionにAOP適用してたりするとだめだけどね。
漏れの場合はその辺もRequestProcessorへのAOP適用で代用できたけど。

134 ：44：04/12/19 19:50:54

>>131

???
もっと詳細キボン。

135 ：デフォルトの名無しさん：04/12/19 20:05:47

>>134
あるオブジェクトZが、A, B, C, ..., Yの役割を持っていたとしても、
オブジェクトZの機能を使ってるんだといえば、
単一責任だというように読める。

業務Aのための機能と業務Bのための機能は、
やっぱり別々の役割で内科医。

136 ：デフォルトの名無しさん：04/12/20 01:38:58

おまいら話の粒度を揃えてから喋れ。
業務って、具体的に何をどうすることを想定しているのだ

137 ：デフォルトの名無しさん：04/12/20 02:14:07

トランザクションをコミットするまで。

138 ：デフォルトの名無しさん：04/12/20 02:45:50

就職してボーナスが出るまで

139 ：デフォルトの名無しさん：04/12/20 03:16:33

>>137
それじゃ大きすぎないかな。

支払を管理する支払テーブルがあったとして
支払に関連するものとして、
通常の買掛金に対する支払と
売掛金返金に伴う支払と2つあった時に、
トランザクション単位で考えれば業務は2つだけど
支払データ生成ロジックは共通で使いたいでしょ。

この場合、買掛金消込、売掛金返金、支払データ生成
の最低3つを業務と捉えるのが望ましいと思うんだけど。
トランザクションの数とは一致しない。

とはいえ、確かに殆どの場合は
トランザクションと一緒で問題ないかもね。

140 ：デフォルトの名無しさん：04/12/20 04:44:58

http://d.hatena.ne.jp/higayasuo/20041219#1103445985

単一責任がどーのこーの言う前に、まずオブジェクト指向の基礎から学び直していただきたい。

141 ：デフォルトの名無しさん：04/12/20 05:15:02

＞140
ナイーブの意味もついでに調べてみよう

142 ：デフォルトの名無しさん：04/12/20 06:38:50

>>140
データと振る舞いが一緒だとオブジェクト指向だと思っている
単純なやつはけーん。

143 ：デフォルトの名無しさん：04/12/20 09:57:33

140じゃないけど、どの辺りを読むとそういう結論になるのか分からん。
157には同意

144 ：デフォルトの名無しさん：04/12/20 09:57:53

>>141
ナイーブなオブジェクト指向、っていうことばなんだけどさ、

http://www.ogis-ri.co.jp/otc/hiroba/OoBook/Beginner/B3.html

OOSE以前のオブジェクト指向設計方法論の
「OOピュアたるべし、ユースケースはOOじゃない」
みたいな考え方を指していたと思うんだけど、
いつの間に凝集性の低いクラスを作ることを「ナイーブなオブジェクト指向」と呼ぶようになったの?

145 ：デフォルトの名無しさん：04/12/20 10:10:24

>>144
よーどんさんたちの言う
「ナイーブなオブジェクト指向」は知らないけど
普通に「ナイーブ」なオブジェクト指向って事なら
142の煽りのような意味で取りますわな。文脈からしてさ。
そういう意味でひがたんは使ってると読んだんだけど・・・

なにっ？もしかして、OOワールドでは
コードやヨードンが厳密に定義した言葉として
認識されてるのかっ？

146 ：デフォルトの名無しさん：04/12/20 10:13:30

>>143
そうだな。確かに>>157はいいことを言ってる。俺も禿胴だ。

147 ：44：04/12/20 10:15:48

>>135

[ 業務A ]
ログイン機能 ---> use isExpired()

[ 業務B ]
社員給料計算機能 ---> use calculatePay

[ オブジェクトZ ]
------------
社員クラス
------------
+isExpired
+calculatePay
------------

この場合のオブジェクトＺは単一責任の原則をやぶってると思う?
おれは思わないよ。

148 ：デフォルトの名無しさん：04/12/20 10:17:30

>>145

違う概念を同じ名前で表したら混乱を招くでしょ。

149 ：44：04/12/20 10:27:09

http://d.hatena.ne.jp/higayasuo/20041220#1103504150
>工数は、リッチな業務ロジック層とDTOパターンのほうが少なくなります。
>DTOとEntityを相互変換する手間がかからないためです。

リッチなドメインオブジェクトパターンではDTOは(めったに)使わないですよ。

150 ：デフォルトの名無しさん：04/12/20 10:32:13

>>145
厳密に定義されてなければ、同じ言葉を別の意味でつかっても混乱をまねかない、ってもんじゃないだろ。

151 ：デフォルトの名無しさん：04/12/20 11:04:47

>>147
>この場合のオブジェクトＺは単一責任の原則をやぶってると思う?

システム領域の機能とビジネス領域の機能を一緒に持たせて単一責任も何も。
ナイーブすぎませんか?

152 ：44：04/12/20 11:11:49

> オブジェクト指向について意見を書くことは、特にデータと
> 振る舞いを1つにすることが、常に正しいとは限らないなんて
> 書くことは、私にとってものすごくリスクの高い&なんのメリット
> のないことです。
>
> にもかかわらず、あえて書いているのは、正しくオブジェクト
> 指向を実践しているように見えても、それが保守性の低下を招く
> 場合もあるということを認識して欲しいということです。

これの例として

> EntityDを使う新たな業務機能が追加されるたびにEntityDに
> メソッドを追加していくと、EntityDは次第に複雑に
> なってきます。

を挙げられているようですが、
EntityDが複雑になる原因は、データと振る舞いを1つにしたことではなく、機能の追加によって次第にEntityDの責務が単一でなくなっていくからです。
このような場合、「データと振る舞いを分割する」のような極端な方法に走らなくとも、EntityDが持つ責務に応じてExtract Classしてやればよいと思います。

> 薄いサービス層とリッチなドメインオブジェクトパターンは、
> 業務機能Aに仕様変更が入っても業務機能Bに仕様変更が入っても
> EntityDを修正することになります。

業務Aから呼ばれようが、業務Bから呼ばれようが
EntityDの持つ責務に変更が入ったのだからEntityDに修正が入るのは
当然だと思いますが。

153 ：44：04/12/20 11:13:19

>>151
どちらがシステム領域で、どちらがビジネス領域?
両方ビジネス領域だと思いますが?

154 ：デフォルトの名無しさん：04/12/20 11:14:14

だから、「ナイーブなオブジェクト指向」じゃなくて
「ナイーブな」オブジェクト指向、って感じで普通に使ったんじゃないの？て話。

148も150も、ナイーブって言葉をはじめて聞いたんでしょうか？
俺、もっと普通に使う言葉だと思ってましたよ。
151がさりげなく使ってるように。

ばかばかしいからこの話やめな。
「ナイーブなオブジェクト指向」って言葉は
テクニカルタームとして、ヨードン、コードが定義した内容でフィックスされてて
ひが氏の使い方は間違い、で、俺の負け、それでいいよ、もう。

155 ：デフォルトの名無しさん：04/12/20 11:17:34

ナイーブだナイーブだ言ってる人たちは

http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?DomainModel

を知ってるのだろうか。

156 ：デフォルトの名無しさん：04/12/20 11:26:10

>>153
確かに、ログインした職責によって
権限を切り替えたりとか、ビジネス領域ですね。

ただ、認証クラスが処理した結果取得出来た属性（IDや職責）を
社員クラスにセットしてやるだけで後はいいじゃん、とか
給料計算を社員自身にさせるのはどうかなあ、とか
議論のある所だと思います。

正解がないだけに色々と人によってまちまちになっちゃうから
いっその事統一ルールで、データの振る舞いは
全部分けちゃえって話だと読みましたがどうでしょう。

157 ：デフォルトの名無しさん：04/12/20 11:28:34

>>155
前スレでその話は出たのです。
貧血症でも金欠症よりはましだという
はぶさんの言葉もありましたな。

158 ：デフォルトの名無しさん：04/12/20 11:29:14

別にS2使うからといってくーすを守らないといけないかというとそんなことはないし
くーすが気に入ったからと言ってS2でないと駄目ってことでもないし。
そもそもどっちもマイナーなんだし放置でいいんじゃないのと思うのは俺だけか？

159 ：デフォルトの名無しさん：04/12/20 12:23:58

>>153
>両方ビジネス領域だと思いますが?

J2EEが提供するような低水準サービスと間違われたか? ｽﾏｿ
情報システム以前に存在する概念(実体)とシステム化に伴う
概念とを一緒にするのがどうかってことなんだけど。
ところでシステムにログインできるのは社員だけ?
役員や派遣社員は? バイトを雇ったら?
漏れはログインに関わる機能が社員にあるのは、
例としても不適切すぎると思うが、
44氏はアダルト、で、俺の負け、それでいいよ、もう。

160 ：デフォルトの名無しさん：04/12/20 13:01:10

>>159
おっしゃることはわかりました。けど

you arent gonna need it.

今想定しているシステムでは
-社員のログイン
-社員の給料計算
しかやらないのでこれで十分ですw
必要になったらリファクタリングしましょう。

161 ：デフォルトの名無しさん：04/12/20 13:03:53

>>159
その話は面白いので、いいよもうで逃亡しないで
もっとやって下さい。

ログインが159の言う意味でのシステム領域か
ビジネス領域かは案件によって様々で
一概にはいえないと思いますけど、
後半は全く同意で御座居ます。

162 ：デフォルトの名無しさん：04/12/20 15:21:38

勝ち負けの争いだったのか。
ということは、傍観してる俺の勝ち。

163 ：デフォルトの名無しさん：04/12/20 16:50:57

http://d.hatena.ne.jp/higayasuo/20041219#1103445985
>
> http://d.hatena.ne.jp/makotan/20041219#p4
>
> で、うまくまとめられてると思いますが、できる限りスコープ(役割)を小さく抑えることで、
> 修正が入ったときの影響範囲が小さくなり、保守性が増します。

リンク先を読みましたが、データと振る舞いを分けるメリットが
よく分かりません。
データと振る舞いを分けるとなぜ修正の影響範囲が小さくなるのでしょうか?

また、私には逆にデメリットばかりが思いつきます。

-データ構造を公開することにより、疎結合性を妨害
-ポリモーフィックな振る舞いを持てない
-いくつかのデザインパターンの適用を妨げる(Compositeパターン等)

> それを考えるには色々な情報が必要になって一概に言えないので
> 簡略化する為に常にデータと処理を分離することにする。

簡略化するために常に分離しないことにしても良いのでは?

164 ：44：04/12/20 16:53:51

> 2chとのやりとりは、正直ブルーだったけど、44氏にありがとうといわれて、
> うれしかったです。これからも、よろしくお願いします。

そんなご丁寧にw
こちらこそよろしくお願いします。

165 ：デフォルトの名無しさん：04/12/20 21:16:58

ナイーブな人だな。

166 ：デフォルトの名無しさん：04/12/20 22:46:09

>>147
これ実際のプロジェクトでやられたら激しくやだ
calculatePayはどう考えても社員クラスにもたすべきじゃない。
44は実務でこんな設計してんの？それとも実務を知らない学生さんなのか？

167 ：デフォルトの名無しさん：04/12/20 23:32:04

給料が社員自身のパーソナリティに強く依存している会社なんだよ。
月給=体重/(身長*身長) 万円とか。

168 ：44：04/12/20 23:38:05

>>166
> >>147
> これ実際のプロジェクトでやられたら激しくやだ
> calculatePayはどう考えても社員クラスにもたすべきじゃない。
> 44は実務でこんな設計してんの？それとも実務を知らない学生さんなのか？

アジャイルソフトウェア開発の奥義の125Pから持ってきた例なので、
文句があるならロバート・C・マーティンへどうぞw

冗談はさておき、calculatePayを社員へ持たすべきじゃない理由を教えてほしいんだけど。

169 ：デフォルトの名無しさん：04/12/20 23:39:41

さむいねw＞167

170 ：デフォルトの名無しさん：04/12/20 23:58:42

S2Dao使ってるんだけど、ログのレベルどうにかならないかな。
SQL文のログと、「トランザクションを～」のログレベルが同じなのはどうかと思う。
SQL文って障害解析時に使うけど、「トランザクションを～」が同じレベルで存在してると、ウザイ。

171 ：デフォルトの名無しさん：04/12/21 00:27:25

実運用時にSQLをログに吐いたりするもんなのか？

172 ：デフォルトの名無しさん：04/12/21 00:44:04

>>168
>アジャイルソフトウェア開発の奥義の125Pから持ってきた例なので、
>文句があるならロバート・C・マーティンへどうぞw
書いたのが誰であれ、自分が引用したんだから、自分で責任もって答えたらどうなの？
やっぱり学生さんなのか？

>冗談はさておき、calculatePayを社員へ持たすべきじゃない理由を教えてほしいんだけど。
1.社員の情報だけじゃ給与計算なんて出来ん
勤怠情報とか、税金とか、手当てとか、あと成果主義の会社だったら
会社の業績とかが給与計算に必要なわけで、calculatePayを社員にもたすと
社員とその他もろもろのあいだに依存関係が出来る。
2.calculatePayを社員にもたすと給与計算の変更があるたびに社員クラスを変更しなければならない
そのときに社員クラスにバグを作りこまないという保証がない。
3.calculatePayは月給を計算するんだとして、ボーナスはどうするのか、出張旅費清算はどうするのか？
社員クラスにcalculateボーナスメソッドを持たすとして、会社の制度が変更になってボーナスがなくなったらどうすんの？

173 ：デフォルトの名無しさん：04/12/21 00:48:03

>>168
やっぱり給与計算となると、
皆自分の経験したり勉強した
実務の事考えちゃうんだと思う。

そうなるとはぶ氏のいってるような事を
考えちゃって、違和感を感じる、と。

＞160で、この例ではそこまで想定してないから
YAGNIだって書いてあるけども
簡略すぎて逆にイメージ湧かないんだと思います。

174 ：173：04/12/21 00:50:42

おっと、ちょうどそんなレスとかぶった。
＞172
そんな訳で、このお題に関しては、そこまではYAGNIらしいんだ。

175 ：デフォルトの名無しさん：04/12/21 00:57:22

44に逆に質問
図形クラスがあったとして、saveメソッドを図形クラスに持たせるべきかどうか？
複数の保存形式をサポートしたい場合、saveメソッドを図形クラスに持たせた場合と
別のクラスに持たせる場合で修正の影響範囲ばどちらが小さいか？

、saveメソッドを別のクラスに持たせる場合
-データ構造を公開することにより、疎結合性を妨害
-ポリモーフィックな振る舞いを持てない
-いくつかのデザインパターンの適用を妨げる(Compositeパターン等)
というデメリットが実際に起こるかどうか？

44はくーすがどうたらいう前に、オブジェクト指向を勉強しなおした方がいいと思う。

176 ：173：04/12/21 01:02:05

＞172
何度もすんません。せっかくだから自分でも考えてみた。

１はなるほど。

2は、社員クラスだろうと給与計算だろうと、変更のリスクは同じかなーと。
どちらかというと、そのリスクを回避するために、
テストがよりしやすいのはどっちかな？って話に持ってった方が吉だと思う。

3は、給与計算に出張旅費生産を組み込むのはちょっと仕事させすぎだと思う。
俺だったら経費の支払と給与計算は別にする。
仕訳も作ったりする場合、まったく別だしね。

最終的に銀行に振り込む情報を管理する機能（例えばFBデータを管理するクラスとか）や
給与明細を出力する機能はこれまた別じゃないか、と。

3はちょっと揚げ足気味かな、ごめん。でも気になったので。
ボーナスは、うーん、どうしよう。

177 ：デフォルトの名無しさん：04/12/21 01:05:15

170に賛成。
171は、障害出たとき、スタックトレースだけを頼りにしてるのか？
SQLExceptionだったら、どうするんだ？SQL文なくても分かるのと、分からないのあるだろ。

178 ：デフォルトの名無しさん：04/12/21 01:19:01

> それを考えるには色々な情報が必要になって一概に言えないので
> 簡略化する為に常にデータと処理を分離することにする。

MMRのキバヤシの口調に似てる。

179 ：デフォルトの名無しさん：04/12/21 01:43:10

ところではぶさんの日記みて、思ったんだが、直接S2とは関係ない、全般的な問題だとは
思うが、Strutsを使った時のDTO <--> ActionForm変換の手間をなんとかできんものか....

180 ：デフォルトの名無しさん：04/12/21 01:48:24

おれは逆に、「トランザクションを～」のメッセージも障害解析時に使う、と
思ったんだけどどうだろうか。「あーここでロールバックしてるわ」とかそういう
情報になるしさ。

181 ：デフォルトの名無しさん：04/12/21 02:18:12

>>170
org.seasar.extension.jtaだけINFOにするとかで止めれるんじゃない?

182 ：デフォルトの名無しさん：04/12/21 11:44:00

どこに責任があるとかないとか考えて、モノによって処理が書いてある場所が微妙に違うのが一番困る。

183 ：デフォルトの名無しさん：04/12/21 21:52:55

それは無責任ですな。

184 ：44：04/12/21 22:01:38

>>172
1と3のような要件の時にはcalculatePay持たすべきじゃないかもしれないけど、
「社員の給与は社員の役職によってのみ決まる」という場合には社員に持たせてもいいと思うんだけど、どう?

また、2の考えを押し進めると以下の(A)を(B)のようにするべきという話になると思うんだけど、こんなクラス、ちょっとありえないよね。
なので2の考え方は間違ってると考えます。

=== A ===
class Stack
　def push( o )
　　...
　def pop
　　...
end
=== B ===
class StackData
　...
end

class StackPush
　def push( stack_data, o )
　　...
end

class StackPop
　def pop( stack_data )
　...
end

185 ：44：04/12/21 22:04:55

>>175
ごめん、質問の意図がわからないよ。

186 ：デフォルトの名無しさん：04/12/21 22:07:12

stackのpushとpopは対(つい)の操作。
calculatePayとisExpiredは無関係。
そんな例示でいったい誰を説得しようというのか。

187 ：デフォルトの名無しさん：04/12/21 22:08:43

>>184
> 役職によってのみ決まる

役職によって決まるんなら、役職に持たせれ。

188 ：44：04/12/21 22:14:00

>>173
そっかー。
いろいろいい例を考えてはみたけど、漏れの貧弱な想像力ではいいサンプルが思い浮かばなかったんでつ orz

189 ：デフォルトの名無しさん：04/12/21 22:20:12

役職はクラスじゃないだろう。
給料の計算はPaymentCalculatorクラスにまとめるでどうよ。

190 ：44：04/12/21 22:20:30

>>186
> stackのpushとpopは対(つい)の操作。
> calculatePayとisExpiredは無関係。
> そんな例示でいったい誰を説得しようというのか。

対の操作 = ひとつのロール、だよね。

172は、例えひとつのロールとして表すべきクラスでも、
エンバグの危険を避けるためにデータと処理を分けるべき、と言っていると思ってるんだけど。

もしそうじゃなかったとしたら、172の2の反論自体無効だね。
だって、おれは複数のロールを持つクラスをロールごとに分割することには賛成なんだもん。

191 ：デフォルトの名無しさん：04/12/21 22:37:35

>>189
> 役職はクラスじゃないだろう。

なぜ？
役職によって違うなら、役職ごとに違う処理を役職ごとに実装するのはありだと思うが。

192 ：デフォルトの名無しさん：04/12/21 22:58:56

>もしそうじゃなかったとしたら、172の2の反論自体無効だね。
>だって、おれは複数のロールを持つクラスをロールごとに分割することには賛成なんだもん。

calculatePayとisExpiredはひとつのロール？
おれはどう考えても別々のロールだと思うんだけど。

193 ：44：04/12/21 23:03:36

>>192
> calculatePayとisExpiredはひとつのロール？
> おれはどう考えても別々のロールだと思うんだけど。

コンテキストによる。

194 ：デフォルトの名無しさん：04/12/21 23:26:31

おれはインスタンス変数だけで処理が完結するなら、その動作は該当クラスに乗せても
いいと思う。

あくまでモデルの話だけどさ。

195 ：デフォルトの名無しさん：04/12/21 23:49:10

>>193
じゃそんな例出すなよ。コンテキストによるなんていわれたら議論のしようがない。
おれはcalculatePayとisExpiredがひとつのロールになるコンテキストなんて現実にはほとんどありえないと思うが。

196 ：デフォルトの名無しさん：04/12/21 23:55:42

それに
>>147で
>この場合のオブジェクトＺは単一責任の原則をやぶってると思う?
>おれは思わないよ。
ていってるのはなんなんだ？これを見たら普通44はcalculatePayとisExpiredがひとつのロール
だと考えてると思うんじゃない？

197 ：デフォルトの名無しさん：04/12/22 00:31:50

役職はStateパターンにして、社員にくっつければ？

198 ：デフォルトの名無しさん：04/12/22 01:15:56

> 役職はStateパターンにして、社員にくっつければ？
なんでも適当に言えばいいってもんじゃないぞ

199 ：デフォルトの名無しさん：04/12/22 06:30:10

>>198
いや、そんなに悪くないんじゃない?
俺の場合、役職に関する処理が増えた場合はそれを採用するかも。

200 ：197：04/12/22 09:34:04

昇進したら役職Stateを取り替えるだけ。
ある役職の処理が変わっても、社員や他の役職のソース修正しなくて済む。
けっこう良かったですよ。

201 ：デフォルトの名無しさん：04/12/22 10:03:05

>>200
役職や職責でstateパターンってまだ試した事無いんだけど
どうも永続化が、って逆か、DBから読み込んで
Entityを生成する時が面倒な気が、ぼんやりとするんです。
どうでした？俺が判ってないだけかなー。

202 ：デフォルトの名無しさん：04/12/22 10:57:48

役職は状態遷移じゃないだろう。このスレ大丈夫か？

203 ：デフォルトの名無しさん：04/12/22 11:23:43

現実世界では役職と状態遷移は違うものでしょうけども
197の提案は、同じ設計パターンが使えませんかねって話なので
202は反論になってないです。

ファウラーに、在庫推移は複式簿記で管理しないだろ、大丈夫かお前？
といってるようなもんじゃないでしょうか。

もうちょっとダメな理由を詳しくよろしく。

204 ：デフォルトの名無しさん：04/12/22 12:48:01

>>202
デザインパターンはマニュアル思考しかできない人間を生産してしまう
などというトンチキな批判がうまれる原因ｗ

205 ：デフォルトの名無しさん：04/12/22 13:40:53

>>203
処理中心になってしまうかもしれないけど、考え方としてはStrategyパターンで行ったほうが素直なのではないでしょうか？
やっぱり、役職は状態ではないと思う。
話が戻ってしまうかもしれないが・・

206 ：デフォルトの名無しさん：04/12/22 14:01:45

>>201
Hibernateにおまかせ。

207 ：デフォルトの名無しさん：04/12/22 14:15:34

状態は列挙のうち一つしかもてない。役職は複数もてる（もしくは持たない）ことが一般的。

役職はロール（というオブジェクト）の一種。
組織の規程は、ロールに対して責務を割り当てる。けして個人や部署じゃない。これはビジネスルール。
個人や部署はパーティとしてまとめられる。
パーティはN個のロールを持てる。
組織の規程は、パーティへのロールの割り当て方について制約を課す。これもビジネスルール。

208 ：デフォルトの名無しさん：04/12/22 15:53:55

ＧＯＦとかちゃんと読んでるのか、おまえら

209 ：デフォルトの名無しさん：04/12/22 15:56:50

ＤＩとかくーすに話を戻しましょう。

210 ：デフォルトの名無しさん：04/12/22 17:39:41

なんで？　もう語ることないじゃん。
手続き型マンセー、Transaction Script上等って結論じゃなかったか？

211 ：デフォルトの名無しさん：04/12/22 19:06:21

でもSQLだけは勘弁な

212 ：デフォルトの名無しさん：04/12/22 19:21:10

エンティティの責任は、データを保持することなので、それ以上の責任を押し付けてはいけません。

213 ：デフォルトの名無しさん：04/12/22 19:23:07

給料が社員によって決まるとしても、社員には給料を決める権限などないのです。
給料計算は、給料計算担当者が。

214 ：デフォルトの名無しさん：04/12/22 19:25:37

>>211
Aチーム、なつかしーなおい。

215 ：デフォルトの名無しさん：04/12/22 23:52:39

>211はコング

216 ：デフォルトの名無しさん：04/12/23 01:39:27

>>213
社員は
-自分の役職
-役職からの給与算出方法
のみを知っていれば「権限」などなくても給与計算できます。
よって給与計算担当者は必要ありません。

もちろん、コンテキストによっては給与計算担当者が必要になることがあるかもしれないことは否定しませんが。

217 ：デフォルトの名無しさん：04/12/23 01:49:58

>>216
で、社員ひとりひとりに自分で給与計算させる会社があるの？
モデリングとは話が違うかもしれんけど、社員を渡せば給料が返ってくる、給与計算者がいるほうがいいと思うなぁ。

218 ：デフォルトの名無しさん：04/12/23 02:38:08

＞「社員の給与は社員の役職によってのみ決まる」

この前提がそもそも非現実的で意味無し。

219 ：デフォルトの名無しさん：04/12/23 02:54:18

>>218
サンプルコードに何を求めてるんだろう?

220 ：デフォルトの名無しさん：04/12/23 03:16:33

現実的なコードじゃない？
あした使えるコード。
あさって納品できるコード。

221 ：デフォルトの名無しさん：04/12/23 03:23:17

サンプルコードに関して、>>216-217のような話は無意味では。
「社員が持つべきケースのサンプル」
と、「計算担当者が持つべきケースのサンプル」があるだけ。

222 ：デフォルトの名無しさん：04/12/23 05:34:21

で、社員が持つべきケースなんてほとんどないから、意味がないというかサンプルとして有害じゃないの？

223 ：デフォルトの名無しさん：04/12/23 06:19:12

だれが、社員と給与で例を示したんだ？
そいつのせいでスレ違いな書き込みばかりになってるじゃないか！

224 ：デフォルトの名無しさん：04/12/23 07:15:49

Seasarもくーすも、話題にするような目立った動きないから、いいんじゃない？
ログ見ても、ナイーブがどうこうとか、某blogのアイドル写真がそろそろ邪魔くさいとか、あまりスレタイとは関係ないし。

225 ：デフォルトの名無しさん：04/12/23 11:44:27

>>223
どうやらファウラーらしい

226 ：デフォルトの名無しさん：04/12/24 01:15:05

>>156の
> 正解がないだけに色々と人によってまちまちになっちゃうから
> いっその事統一ルールで、データの振る舞いは
> 全部分けちゃえって話だと読みましたがどうでしょう。

に賛成。
債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。

227 ：デフォルトの名無しさん：04/12/24 01:22:01

View やトリガーがあると追えない？
維持すべき設計文書を書いてないだけじゃないかな。

228 ：デフォルトの名無しさん：04/12/24 01:32:03

そうすると、一ヶ所に処理を記述したときには、そのソースだけを見ればよかったのが、設計文書とViewなりトリガーなりとJavaのソースと、いろいろなところを見ないといけなくなるわけですね。
しかも、設計文書とJavaソースとViewやトリガは、見るためのツールが違うので、煩雑に。
それだけ追うための手間が増えるわけですよ。

修正の場合も、設計文書を必ず修正する必要があって、この作業は徹底するのにかなりの労力を伴う。
単純に比較すれば、一ヶ所で記述した場合にくらべて、労力自体は増えると思うのですよ。
とくに、設計文書管理の労力。

229 ：デフォルトの名無しさん：04/12/24 01:36:25

で、問題はくーすでたびたび話題になってる、作業に関わる人のレベルが一定ではないということですね。
実際には、問題になるのは、レベルではなくて、考え方で。
むしろレベルが高い、考え方の違う人が書いたシステムが非常に追いにくくなるわけで。
システムを追う前に、どのような考え方で書かれたのかをプロファイリングしないといけない。

230 ：デフォルトの名無しさん：04/12/24 01:51:24

ドキュメントは非常に儚いので、アプリケーションの枝葉がドキュメントに依存するのは、問題があるんじゃないかと。
アプリケーション独自のロジックに関しては、ドキュメントがなくてもわかるようなものが理想で。

ただし、アプリケーションの骨格がドキュメントに依存するのは仕方がないと思う。
でも、アプリケーションの骨格は、揺るぎにくく共通化しやすいから、その部分をみんなで使えるようにしましょう、と。
で、そのアプリケーションの骨格のドキュメントが、くーすなのかなぁと思う。

231 ：デフォルトの名無しさん：04/12/24 07:11:05

シンプルなオブジェクトを複雑に組み合わせるのと、複雑なオブジェクトをシンプルに組み合わせるのと、どっちがいいんだろう？

232 ：デフォルトの名無しさん：04/12/24 10:23:03

>>226
> に賛成。
> 債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
> DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。

債務(さいむ)じゃなくて責務(せきむ)な。

233 ：デフォルトの名無しさん：04/12/24 10:59:07

ドキュメントが儚い？
恥ずかしげも無くよく言えるな、おい。
ＸＰｅｒもどきの増殖にも困ったもんだ。

234 ：デフォルトの名無しさん：04/12/24 11:54:34

>>233
数度の変更を経たにもかかわらず、ちゃんと同期しているドキュメントをみたことがない。

235 ：デフォルトの名無しさん：04/12/24 12:00:19

俺も無い

236 ：デフォルトの名無しさん：04/12/24 12:13:41

233は、よほど躾の行き届いた組織にいるらしい。
うらやましいな。

237 ：デフォルトの名無しさん：04/12/24 12:16:24

ActionFormにインジェクションできますか？

238 ：デフォルトの名無しさん：04/12/24 12:56:08

見た事がないというか、出来た事がない＿|￣|○|||
先ず書く、そして打つという手順を守りさえすればそんなはずはない
と上司は言うけれど・・・・・・・・
短期で動くモノを差し出せとせっつかれて、それどころじゃないのです。

アジャイルって本当に素晴らしいモノなのかな？なんか週間連載を
抱えた漫画家みたいって言うか、納期が短い間隔で何回もやってく
る感じで、昔よりも寧ろ過酷になってる様な気がするんですが・・・・・

239 ：デフォルトの名無しさん：04/12/24 13:20:43

ここはサンデープログラマのスレですか？

240 ：デフォルトの名無しさん：04/12/24 13:27:04

234はSCMをしないPRJにしかいたことがないようだな。
変更管理をきっちりすれば同期問題はおきないぞ。

241 ：デフォルトの名無しさん：04/12/24 13:37:09

>>240
だから、変更管理をきっちりしてる
プロジェクトで仕事した事がない、って話なんです。
ちっこい案件は別だけど。

242 ：デフォルトの名無しさん：04/12/24 14:06:25

>>241
ＰＭがマヌケということか。同情するよ。
まぁ、悲観するな。そのうちまともなＰＲＪに出会えるから。

243 ：デフォルトの名無しさん：04/12/24 18:46:41

>>240
構成管理をきっちりしないと、同期問題がおきるってことでしょ。
で、構成管理をきっちりすることは、組織的な成熟度が高くないといけない。
適用しやすい開発方法論を考えるのなら、
「こうやればうまく開発できます。でもドキュメントが大切なので、構成管理はきっちりやってください」
というものはどうかと思う。

構成管理がきっちりできるなら、他の能力も高いことが多いから、どうとでもやってくれという感じ。

244 ：デフォルトの名無しさん：04/12/24 19:21:28

　　　　　　　＿＿＿
. 　　　　　　　 |（･∀･）|
. 　　　　　　　 |￣￣￣　　　ｼﾞｻｸｼﾞｴﾝ王国
　　　　　　　　　△
　　　　　　　 △ｌ　|
　　　＿＿△|_.田 |△＿＿＿＿＿
　　　　　　|__|__門_|__|＿＿＿＿＿|＿＿＿＿＿

245 ：デフォルトの名無しさん：04/12/24 20:25:35

データと振る舞いは別クラスにすべき、と言っている人たちは
TheBlobを避けるためにPoltergeistに向かっているように思うなー。

The Blob
http://www.antipatterns.com/briefing/sld024.htm

Poltergeist
http://www.antipatterns.com/briefing/sld030.htm

246 ：デフォルトの名無しさん：04/12/24 21:56:59

結局、適材適所
だからフレームワークは無用
プログラミングしよう

247 ：デフォルトの名無しさん：04/12/24 23:21:51

243は、ある程度の規模のPRJで構成管理をやらなければ開発は頓挫するという事実が理解できていないようだ。
まぁ、わからないでもないよ。最近は知ったかぶりのアジャイル莫迦が多すぎるからな。
JAVAWORLDも酷い記事を書くやつが増えたが、編集は何をやっているんだか。

248 ：デフォルトの名無しさん：04/12/24 23:55:56

>>247夜釣りご苦労。

249 ：デフォルトの名無しさん：04/12/25 00:24:40

ちなみにくーすの元ネタICONIXは、シーケンス図とかの中間成果物は
使い捨てで、ソースコードとの同期はやらないんだよね。

250 ：デフォルトの名無しさん：04/12/25 00:44:07

あれ？
捨てはロバストネス図じゃなかったっけ？

251 ：デフォルトの名無しさん：04/12/25 00:44:27

あれ？
捨てはロバストネス図じゃなかったっけ？

252 ：デフォルトの名無しさん：04/12/25 00:46:05

あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？

253 ：243：04/12/25 04:43:59

元の話にもどすと、サーブレットフィルターやAOPやDBのトリガーなど、コードに現れない形で処理が分散するときには、ドキュメントを同期したにしても、ドキュメント自体が分散しがちで、結局わけがわからなくなりそう。
もちろん適切に使えばよいけど、一度乱用する時期を経ないと適切に使えないと思う。
プロジェクトの発言権を持った人の中に乱用する時期の人がいる可能性も高い。

254 ：243：04/12/25 09:15:37

まとめれば

「ドメインモデルは、複雑なコードを整理しやすいのがメリットだ。
ただ、開発者にとって理解しにくく、またRDBMSとのマッピングが複雑になる。
そこで、ORマッピングレイヤを設けなくてはならない。
そのため、ドメインロジックがシンプルな場合は、トランザクションスクリプトを採用した方がいい。」

ということだ。やっぱファウラータンは俺のために言葉を用意してくれてて偉いな。
ttp://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html

255 ：デフォルトの名無しさん：04/12/25 11:49:58

>>254
そんな考えはレガシーで、ドメインモデルは複雑な
ロジックを記述するには向かない
という考えってどうよというのが先週からの話。
少しは流れを嫁。

256 ：デフォルトの名無しさん：04/12/25 11:59:49

>>255
つまり、すごく複雑ならドメインモデルでちょっと複雑ならトランザクションスクリプトっていってるのを、すごく複雑でもトランザクションスクリプトでってこと？

257 ：デフォルトの名無しさん：04/12/25 12:10:33

お父さんは貧血症

258 ：デフォルトの名無しさん：04/12/25 12:17:38

>>256
この辺かな。
http://d.hatena.ne.jp/higayasuo/20041223#1103771319
1週間くらい前からいろいろもとねたがある。

259 ：デフォルトの名無しさん：04/12/25 12:23:36

ドメインモデルを作っても貧血になっちゃうからよくない、と。

260 ：デフォルトの名無しさん：04/12/25 12:25:56

> １．あるコンポーネントは自分で処理するか、自分よりも詳細なことを知っている別のコンポーネントに処理を任せる。
> ２．1を再帰的に繰り返す。

構造化じゃん。

261 ：デフォルトの名無しさん：04/12/25 12:34:10

>>260
メソッド分割なのかコンポーネント分割なのかという話だと思うよ。
ちなみにそれが構造化ならあらゆる処理がが構造化。
自分で処理するか他人に任せるしかないんだから。

262 ：デフォルトの名無しさん：04/12/25 12:38:20

ドメインモデルを適切に構築するのは難しいから、いっそのことトランザクションスクリプトでってこと？
でも、トランザクションスクリプトじゃない、って書いてある。

ここに書いてあるのは、トランザクションスクリプトを構造化したらいいって話だよね？
そしたら、コマンドパターンっぽく切り替えやすくなると。
構造化って、おおざっぱなものが細かいものを再帰的に内包するモデルのことだよね？
違うの？

263 ：デフォルトの名無しさん：04/12/25 12:45:11

デマルコの「構造化分析とシステム仕様」に、なんだかそのものズバリの図が書いてあるんだけど・・・。
で、Javaだと、ひとつの処理をひとつのオブジェクトに割り当てるといろいろ切り替えれて便利、っていう話だと思ったんだけど。

264 ：デフォルトの名無しさん：04/12/25 12:53:17

Javaの場合は関数ポインタもないし、言語仕様としてはメソッドはオブジェクトではないからクラスに追加したり切り替えたりできない。
ってことで、オブジェクトに持って切り替えれるようにしましょうってことでしょ？
切り替える用途やら規模によって、ストラテジーだとかコマンドとかステートとか、いろいろパターン名が変わるだけで。

265 ：デフォルトの名無しさん：04/12/25 12:59:51

>>262
たぶん、構造化というよりは、自分の役割だけをこなしてあとは、
人に任せるということなんだと思う。
ドメインモデルは、1つのクラスに役割が集中しすぎる危険性があるという話。

266 ：デフォルトの名無しさん：04/12/25 13:32:42

>>265
言い方が違うだけで、構造化とやってることは同じだと思うけど。
人=オブジェクトって考えが出てるけど、これはJavaの言語仕様上オブジェクトが便利なだけで。
関数ポインタが使えるか、メソッドを代入できる言語では、オブジェクトである必要はなさそうだし。
そのオブジェクトはステートレスなんだよね？

つまりは、ドメインモデルを適切に構築するのは難しいから、構造化されたトランザクションスクリプトで、ってことでしょ？

267 ：デフォルトの名無しさん：04/12/25 13:43:17

で、手続き呼び出しの構造化ツリーの構築にDIが便利と、そういうことでしょ？

ただ、ここでインターフェイスを持ち出してくる必要があるのかないのか。
インターフェイスはテストの都合で必要なわけで。
処理を動的に切り替える予定がない部分をインターフェイスにする理由は、それしかないよね？

268 ：デフォルトの名無しさん：04/12/25 13:43:59

あ、AOPもか。

269 ：デフォルトの名無しさん：04/12/25 14:00:59

なんかトランザクションスクリプトってことになんとか持っていきたいように思えるが、
「モデル」部分を「単純なデータ保持／DBアクセスオブジェクト」として完全委譲した
だけで、これはドメインオブジェクトだって理解した方がいいんじゃないの？

トランザクションスクリプトってのは、サービス層でDBアクセスも全部世話して、呼び出した
メソッド一つで全部やってしまうようなもんだろ。

プレゼンテーション層 -> サービス層（薄い） -> ドメインモデル（モデルを基準に分割／ORマッピングもする） ->DB
が
プレゼンテーション層 -> サービス層（薄い） -> ドメインオブジェクト（サービスを基準に分割） -> 薄いモデル（ほぼORマッピングだけする） -> DB

になっただけなんじゃないの？どっちみちサービスの連鎖の開始ポイントとして、Facade的な
薄いサービス層は現れてしまうし。
で、薄いモデル部分がドメインモデルと比べて明らかな貧血症だから騒いでるだけだろ。
俺にはデータアクセスをドメインモデルから外に出して、分割の基準を変えたように見える。

270 ：デフォルトの名無しさん：04/12/25 14:18:51

トランザクションスクリプトじゃなんで嫌なのかがよくわからんけど、先のblogだけ見ると構造化されたトランザクションスクリプトにしか見えないんだよね。
結局サービス層のことをドメインと呼んで、その前に置いたコントローラー的な層をサービス層と呼んでるんじゃない？
で、実際にドメインになる部分が薄くなって、「ドメインモデル貧血症」になってるからどうこう言ってるんじゃないの？

いや、よくわからんのだけど。

271 ：デフォルトの名無しさん：04/12/25 14:19:40

分割の基準を変えたように見えるという点では同じかな？

272 ：デフォルトの名無しさん：04/12/25 14:24:06

>>267,268
学生ですか？
機能拡張とか仕様変更とか、手作業でトランザクション制御する手間とか
納期とか考えたことある？

273 ：デフォルトの名無しさん：04/12/25 14:26:26

> トランザクションスクリプトってのは、サービス層でDBアクセスも全部世話して、呼び出した
> メソッド一つで全部やってしまうようなもんだろ。

いや、ドメインモデルを構築する代わりに全部１つの流れでやりましょうっていう形。
だから、ドメインモデルと置き換わるはず。
で、もちろん１つのメソッド・ひとつのオブジェクトで完結する必要はないと思う。
サービス層は、適切なトランザクションスクリプトを呼び出す層ということになるんじゃない？

274 ：デフォルトの名無しさん：04/12/25 14:30:12

>>272
> 手作業でトランザクション制御する手間

トランザクションが必要で、それがAOPで実現されてるならインターフェイスを使うしかないね。
で、機能拡張とか仕様変更とかの話だと、ソース追う手間が増えることを考えると、一概に言えるのかなぁ。
ソース追う手間は、無視してしまえる程度にしか増えないものなの？

275 ：デフォルトの名無しさん：04/12/25 14:33:31

機能拡張とか仕様変更とかで、インターフェイスが便利なときは、そのときインターフェイス作るっていうのは？
いままでのクラスと同じ名前でインターフェイス作れば、ソースは変更しなくていいし、オブジェクトの生成はDIでやってるわけだからそこ書き換えるだけじゃないかなぁと。

276 ：デフォルトの名無しさん：04/12/25 14:38:52

ttp://www.nri-aitd.com/tips/g-patern.html
これなんか読んでると、別にトランザクション・スクリプトでもいいじゃん、という気になる。

おれ、ドメインモデルってモデル間が密結合しすぎのような気がするんだけど。

277 ：デフォルトの名無しさん：04/12/25 14:47:03

その記事に書いてある通り、どっちがいいかはビジネスロジックの複雑さに依るのだろう。

278 ：254：04/12/25 14:53:06

>>255
結論は同じところに落ち着きますた。

279 ：デフォルトの名無しさん：04/12/25 15:04:29

>>278
複雑な業務ロジックだと、トランザクションスクリプトには
向かないというのはなぜ?
別にトランザクションスクリプトはどうでもいいんだけど、
コンポーネント分割でDIで組み立てるやり方なら、
逆に複雑な業務ロジックに向いてると思うけど、
理由は、それぞれのコンポーネントは小さいから。
ドメインモデルは、複雑なロジックになればなるほど、
クラスは大きくなる。

280 ：デフォルトの名無しさん：04/12/25 15:28:04

>>279
複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ？
なにか説明するにしても、ファウラーの言葉の引用になりそう。

とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。
で、複雑な業務ロジックの場合は、オブジェクトが状態を持ったほうが好都合なんじゃないのかなぁ。

281 ：デフォルトの名無しさん：04/12/25 15:29:35

ドメインモデルで複雑なロジックになればクラスが大きくなるというのなら、そのときトランザクションスクリプトならそれぞれのコンポーネントを小さく保てるのはなぜ？

282 ：デフォルトの名無しさん：04/12/25 15:41:59

>>281
複雑なロジックを単純な役割に分割してそれぞれの役割にコンポーネントを
割り振るからだろう。
それぞれの役割は単機能だから小さい。
ドメインモデルだとデータに対して振る舞いを割り当てるから、
複雑になればなるほど、やらなければならない役割が増える。

283 ：デフォルトの名無しさん：04/12/25 15:47:38

>>280
> >>279
> 複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ？
> なにか説明するにしても、ファウラーの言葉の引用になりそう。

引用は別に良いと思うけど、理由を説明できなければ意味はない。
ファウラーたんも盲目的に信じて欲しいとは思ってないと思うけど。

> とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。

そんなことどっかに書いてある?

284 ：デフォルトの名無しさん：04/12/25 15:48:11

トランザクションスクリプトだと単純な役割に分割できるときに、ドメインモデルだと単純な役割に分割できないことになるのはなぜ？

285 ：デフォルトの名無しさん：04/12/25 15:49:57

>>283
> そんなことどっかに書いてある?

そうじゃないの？

286 ：デフォルトの名無しさん：04/12/25 15:58:55

>>284
>>282に書いてあるじゃん。分割単位が役割じゃなくてモデルだからだろ。

287 ：デフォルトの名無しさん：04/12/25 16:14:55

そのモデルが適切に分割できないということになるのはなぜ？

288 ：デフォルトの名無しさん：04/12/25 16:39:26

さあ？ＤＢのテーブル構造に依存しちゃったんじゃないか？モデルって永続化のやるしねえ。

289 ：デフォルトの名無しさん：04/12/25 16:43:00

逆に、モデルを適切に分割することができないとして、そのときトランザクションスクリプトを細切れに分割したところで、おおきなドメインのモデルよりも有効だと言えるの？
トランザクションスクリプトはいくらでも分割できるだろうけど、そのとき大きなドメインのモデルよりいいかどうかは疑問に思える。
杞憂なのかな？

290 ：デフォルトの名無しさん：04/12/25 16:44:21

>>288
ORマッピングで、１つのテーブルをいくつかのオブジェクトにマッピングできるものもあるわけだし。

291 ：デフォルトの名無しさん：04/12/25 16:59:38

>>289のいいたいことがよくわからんのだが、ドメインモデルに比べればそんな利点は霞むと
いいたいのか、大して変わんないんだからドメインモデルでいいじゃんといいたいのか、
言ってることに利点など何もない、問題は存在しないといいたいのか。

292 ：デフォルトの名無しさん：04/12/25 17:00:37

スレ違いだけど、ちょっと気になったんで、確認させてください。
デマルコの「構造化分析とシステム仕様」は、「構造化」の原典のひとつだと思って引っ張ってきたんだけど、違ってる？

293 ：デフォルトの名無しさん：04/12/25 17:01:10

>>289
分割統治せよは、昔から言われている真実。
大きいより小さいほうが中身がわかりやすいのは当たり前。
複雑なドメインロジックの場合、データと役割は単位(大きさ)が
かみ合わないことのほうが多いので適切に分割できない。
たいていの場合、1つのデータに多くの役割が集中する。
なぜかっていうとそのデータに関する役割を集めるからね。
必然的にそうなる。

294 ：デフォルトの名無しさん：04/12/25 17:02:35

>>291
ドメインモデルが分割できないときに、細切れのトランザクションスクリプトをばらまいても、問題を複雑にするだけということはないだろうか？と。

295 ：デフォルトの名無しさん：04/12/25 17:03:02

ちょっと前にも出てたけど、ドメインモデルってモデルを基準に機能をどこにおくか
考えるからさ、「この機能、どこにおいてもぴったりしない」とかいうことがあるよねえ。
で「社員Util」とか変なのがいつのまにか作られてたり。

俺はサービスを分割基準に置くのは悪い考えではないと思うし、それによってオブジェクト指向的な
利点を無効にしてしまうこともないと思うよ。
モデルの役割をモデル内データの管理とその永続化だけにしようって考え方も、とてもオブジェクト
指向的だとおもうけど。

296 ：デフォルトの名無しさん：04/12/25 17:06:51

>>294
んん？単にモデルにはモデルの役割だけさせて、ビジネスロジックはモデルの役割じゃないから
サービスとして分割しようって言ってるだけだと思うんだけど。

サービスとして分割してしまえば、分割の自由度は上がる。でも意味もなく細切れにしたら混乱する
のはあたりまえ。「ここは分割しなきゃ」と思ったときに、ドメインモデルだと分割しにくいけども、
サービスだけならきれいに分割できることがあるってだけ。

297 ：デフォルトの名無しさん：04/12/25 17:07:09

>>292
間違ってないよ。
なんか構造化は悪いものだとか、オブジェクト指向とはかみ合わないとか
勘違いしているやつが多いのか。

298 ：デフォルトの名無しさん：04/12/25 17:19:33

ようするに、ttp://www.nri-aitd.com/tips/g-patern.htmlのグラフだと、トランザクションスクリプトは問題が複雑になったときに加速度的に設計コストがあがってるけど、そうではない、っていうことなんだよね？
実際、ここにはドメインモデルがいいとは書いてあるけど、トランザクションスクリプトがダメな理由は書いてないね。

だから、どっちも疑問といえば疑問なんだけど。
ただ、モデル化は視点の問題だと思ってるので、片方のモデルで適切に分割できないのに片方のモデルでは適切に分割できる、というのが、にわかに信じれない。
複雑なものを細切れにすると、単純なものが複雑に散らばるだけなんじゃないかと。
それよりは、大きな複雑なものがあったほうが、見通しも良くていいんじゃないかと思うわけです。
そのとき、それぞれの部品の単純さを主張しても、意味のある主張になるのかなぁと。

実際に上記のサイトのグラフで線が入れ替わるところのような複雑なものは、単純に例示できないだろうから、難しい話だとは思うんだけど。

299 ：デフォルトの名無しさん：04/12/25 17:26:23

>>297
そう。
だから、なんでヒガさんが構造化だと言われたことを誤解だと斬って捨ててるのか、疑問。

300 ：デフォルトの名無しさん：04/12/25 17:27:20

>298
適切って言葉をどう捉えるか。くーす的なのは「いかに維持しやすいか」が視点だろう。
そのかわりドメインモデルの明快な美しさは失われるが、それはビジネスだから諦める。

理屈ではドメインモデルってみんな好きなんだよ。でも仕事で使ってみると
世の中明快に割り切れるものなんてないし、たとえうまく設計できたとしても
システムは完成した瞬間から陳腐化するから維持運営に結構苦労する。

サービス分割って考えは希望が持てる。業務とコードが対応してるから直すときに躊躇がいらない。
将来一部業務に大変更が発生しても、ほかへの影響なしにそこだけ手を入れられるってのはステキだ。

301 ：デフォルトの名無しさん：04/12/25 17:40:47

おれは、そのモデルの機能が＿本当に＿多くて複雑なモデルになるなら、
それはそれでかまわないと思ってる。でも実際には、そのモデルＡの役割というよりは、モデルＡ
とBとCをつかってほにゃららする、という機能が結構あるんだよ。
結果としてＡがB、Cを保持したりして実現するわけだ。

それがＡというモデルの機能なのか？という疑問というのが１点ある。B、Cでないとどうして
いえるのか？またＡでもBでもCでもなく、ＡＢＣと取りまとめる別のモデルの機能ではないか？

さらに、その機能のためにＡはB、Cを保持してるわけで、結局は「複雑に散らばってる」わけだ。

大きな複雑なモデルってのは、「大きなものがひとつあって、そこだけ見ればなんとかなる」んじゃ
なくて、細切れのモデルが一つのモデルの中で絡み合ってごちゃごちゃになってて、結局全部の
モデルを理解していないと「大きな複雑なモデル」を理解できない。だから「ドメインモデルは全体を
理解してないと使えない」と言われるわけ。さらにモデルが永続化も担うので、役割過剰と言われ
ても仕方がないと思う。

サービス分割も同じ問題ははらんでるよ（あるサービスが別のサービスと絡み合うとかね）。
ただサービスが一つのビジネスロジック上の役割で分割されているので、触るときに影響範囲が
見えやすいし、「あ、これは別の業務だな」と思ったら躊躇なく分割できる。結果として細切れの
サービスができかねないのは事実なんだけど、細切れのものが業務単位でまとまってるので、
多少はまし、といったところか。

302 ：デフォルトの名無しさん：04/12/25 17:40:52

誰にツケ回したところで、結局は自分で払うんだべ。

303 ：デフォルトの名無しさん：04/12/25 17:44:56

>>300
とりあえず前提条件おさらい。
どうやって計ったかはしらないけど、トランザクションスクリプトだと天井つきぬけるくらいコストがかかるとファウラーが主張するくらいビジネスロジックが複雑なときの話。
で大きいまま分割できないドメインのモデルがある。

そのとき、そのドメインのモデルは、その大きさのままが維持しやすいことになるんじゃないのかなぁ。
将来そのモデルのかかわる一部業務に大変更が発生しても、いろいろなところを追わずに、そのモデルだけ修正すれば済むわけで。
もちろん、分割できないモデルだから、そのモデル全般に影響が及んでるだろうけど。

縁がありそうな程度の複雑さのビジネスロジックでは、>>300に賛成。

304 ：デフォルトの名無しさん：04/12/25 17:49:36

>>303
うーん、なんか逆な気がするな。
大きく複雑なモデルは仕事をいろんなモデルに移譲しまくってるので、「業務」単位でみると、
一つの業務追加・変更で複数のモデルに影響がでるよ。
モデルの分割単位はあくまで「なんらかのビジネス上の概念」であって、業務ではないからね。

で、たいていの業務では、「なんらかのビジネス上の概念」が複数絡まってるもんだ。この複数
絡まってる機能をどこにおく？という話じゃないか。

305 ：デフォルトの名無しさん：04/12/25 17:50:53

>>301
いや、そのとき、ドメインモデルだと細切れのモデルが絡み合っててごちゃごちゃになってて結局全部のモデルを理解してないくらい複雑なのに、サービス分割だと影響範囲が見えやすく業務単位でまとまってるってことはないんじゃないのかな、と。
サービスを、躊躇なく分割したり業務単位でまとめれるなら、ドメインモデルも同じように分割して業務単位でまとめれる可能性が高いんじゃなかろうか。

306 ：デフォルトの名無しさん：04/12/25 17:54:52

ドメインモデルのときは複雑な業務ロジックの話をしてるのに、サービス分割のときはそこまで複雑じゃない業務ロジックの話をしてるように見える。

もちろん、複雑じゃない業務ロジックの話で、ドメインモデルよりサービスでの分割がいいというのは、同意できる。

307 ：デフォルトの名無しさん：04/12/25 17:59:13

>>305
そうだね。でもそのようにドメインモデルを分割したら、それはドメインモデルじゃないんじゃない？

ドメインモデルはそのモノが担うべきものだけを提供すべきで、業務的な必要性から関係ない機能を
追加するもんじゃないからさ。理想としては、もし業務要件が複数のモデルが絡み合うものなら、
複数のモデルを直すべきなんだよね。

業務要件で勝手にまとめてどっかのモデルに押し込んじゃったりしたら、ドメインモデル特有のオブジェ
クト指向的美しさは台無しじゃないか？でもビジネスはそんな美しさは関係ない訳で、そこに軋轢があ
るんじゃないか。
サービスだと、そもそも業務単位でまとめるもんなんだし、分割しやすいしまとめやすいってことじゃ
ないかと。まあ業務要件があって仕事があるという現実に即した分割方法じゃないかな？

308 ：デフォルトの名無しさん：04/12/25 18:03:57

http://www.nri-aitd.com/tips/image/g-patern_4.gifなんだがな、
まずどういうシステムを対象にどのように測定したのか知りたい。
同じシステムをそれぞれのパタンで作って比較したのか、
それとも色んなシステムを比較したのか。どこかにどのように
調査したのか書いてるのある？

309 ：デフォルトの名無しさん：04/12/25 18:21:01

>>307
その意見が、非常に複雑な業務ロジックで成り立つのかが疑問なんです。

まあ、その解を得ることに、「>>308の図が読み解ける」という以上の意味はないんだけど。
というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
もちろん長い年月ソフトウェアに関わって、いろいろな開発をみてきて、実際の測定もしてきたわけだから、それなりの根拠があることは間違いないんだけど。

310 ：デフォルトの名無しさん：04/12/25 18:33:04

非常に複雑な業務ロジックってなんなんだろね。
ありがちなのは飛行機工場の生産管理とかかな？

311 ：デフォルトの名無しさん：04/12/25 18:35:43

いきあたりばったりのうちの営業

312 ：デフォルトの名無しさん：04/12/25 18:43:34

業務になってる部分が少ないから却下、とか。

313 ：デフォルトの名無しさん：04/12/25 18:46:17

>>305
トランザクションスクリプトは、任意の単位に分けられるから
機能単位に分ければ良いが、
ドメインモデルは、意味のあるデータ単位に振る舞いを持たせるから
機能単位に分割できないという話でしょ。

314 ：デフォルトの名無しさん：04/12/25 18:56:32

>>309
> というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
禿胴

315 ：デフォルトの名無しさん：04/12/25 18:58:44

>>309
ファウラーのいっているトランザクションスクリプトは、
1つのクラスでメソッド分割するイメージなんだと思うな。
それだったら、複雑になればなるほどクラスが大きくなるから
その維持は大変になる。
ドメインモデルは、複雑とはいっても複数のクラスに処理が
分散されているからましということなんじゃないだろうか。

そういう前提なら、http://www.nri-aitd.com/tips/image/g-patern_4.gifも
まぁ、そうかなという気もする。

くーすでいっている役割分担によるコンポーネント分割方式なら、
複雑になっても、それぞれのコンポーネントの役割は明確で、
小さいから維持は、ドメインモデルよりしやすいだろう。

316 ：デフォルトの名無しさん：04/12/25 19:07:03

>>313
いや、それで、トランザクションを分けたときに、業務単位にまとめれたり、影響範囲がみえやすかったりするのだろうか、と。
ドメインモデルでは、複雑でごちゃごちゃに絡み合ってそれ以上分割できず、全体をみないといけないのにだよ？

317 ：デフォルトの名無しさん：04/12/25 19:16:00

ドメインモデルは比較的単純な業務でも複数のモデルが絡み合う（というかそういう風につくるもん）
なんで、単純比較してしまうとなあ。

318 ：デフォルトの名無しさん：04/12/25 19:18:34

>>316
業務単位に最初からクラスを作れば良いんだから分けられるに決まってる。
影響範囲が見やすいといっているのは、本来独立した複数の業務が
交差することはないためでしょう。

319 ：デフォルトの名無しさん：04/12/25 19:29:13

>>317
うん、だから、単純な業務ではドメインモデルじゃないほうがいいというのは共通認識になってると思う。

>>318
いちおう、>>303あたりの前提条件みてください。

320 ：デフォルトの名無しさん：04/12/25 20:04:06

>>319
だから、複雑で分割できないと思っているのは、
データを中心に見ているからでしょう。
データに関連する振る舞いを全部持たせようとするとそうなる。
複数のモデルに関連する振る舞いをどれかのモデルに持たせればそうなる。
機能を中心に見ればそんなことはない。
どんな複雑な機能だって、シンプルな機能に分解できる。

321 ：デフォルトの名無しさん：04/12/25 20:07:13

>>319と>>320はなんか話がかみ合ってないんじゃないか？

322 ：デフォルトの名無しさん：04/12/25 20:10:51

重複したコードが散らばって、機能追加・変更が大変になりそうだけど。

323 ：デフォルトの名無しさん：04/12/25 20:14:45

だからさ、サービスで分割ってのは、まさに「データに振る舞いをのせるのでは
なくて、データの管理と永続化は外に出しちゃって、ビジネスロジックは機能で
分割しましょう」って話じゃないのか？

324 ：デフォルトの名無しさん：04/12/25 20:17:06

>>309
>というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。

PofEAAによるとそれは「nonscientific graphs」らしいよ。
ファウラーたんの感覚的なものに過ぎないんじゃないかな。

325 ：デフォルトの名無しさん：04/12/25 20:17:35

>>320
だから、機能がシンプルなものに分割できることはわかってるんだけど、そのつながりが複雑になるんじゃないの？と。
で、そういう話をしているときに、単体のシンプルさを主張しても、あまり意味がないんじゃない？
って、だいぶ前に書いた気がする。

326 ：デフォルトの名無しさん：04/12/25 20:21:03

>>324
萎えた

327 ：デフォルトの名無しさん：04/12/25 20:21:24

>>324
ま、そんなもんなんだろう。
とりあえず、ファウラーたんを信用ことにするよ。
感覚的なものを極端に書いてると思っておく。

ただ、いつもどおり目の青い人の国でのお話だから、日本で鵜呑みにはできんけど。

328 ：デフォルトの名無しさん：04/12/25 20:32:50

>>325
そういうことか。
どんなに複雑な組み合わせでできたコンポーネント群でも
特定のコンポーネントを見れば、自分と直接関連のある
コンポーネントだけとしか関係を持たないから
つながりも複雑になることはない。

329 ：デフォルトの名無しさん：04/12/25 20:33:26

ファウラーﾀｿの感覚に振り回されてクリスマスの休日にドメインモデル談義か。おめでてえな。

330 ：デフォルトの名無しさん：04/12/25 20:40:58

そろそろこっち逝け

Martin Fowlerのスレッド
http://pc5.2ch.net/test/read.cgi/prog/1099814095/l50

331 ：デフォルトの名無しさん：04/12/25 20:41:19

結論：構造化に始まり構造化に終わる。

332 ：デフォルトの名無しさん：04/12/25 20:56:43

いいじゃんここで。おもしろいよ。
業務機能とソースコードのバランスをどうとるか、って噺はあんまり聞かないから。

333 ：デフォルトの名無しさん：04/12/25 20:56:58

Transaction Script＝構造化的OO
Domain Model＝DOA的OO
ってことでいいのか？
http://www.nri-aitd.com/tips/g-patern.htmlの
それぞれの特徴を見てるとそんな気がしてきた。

334 ：デフォルトの名無しさん：04/12/25 21:04:03

>>328
話が、ファウラーたんもびっくりレベルの複雑な業務ロジックだったときに、果たしてそういえるのか。
特定のコンポーネントだけをみて、自分と直接関係のあるコンポーネントだけをみて、用が足せるのか。
甚だ疑問。

335 ：デフォルトの名無しさん：04/12/25 21:09:27

>>333
またまたスレ違いの質問なんだけど、DOAの原典的な本とか、始祖的な人ってどこらへんになるんだろう？
一度中途半端に調べてみたんだけど、わからなかった。

336 ：デフォルトの名無しさん：04/12/25 21:23:52

>>334
疑問に思うのは自由だけど、それで用は足せる。
DIでは、自分の直接の知り合いとしか話しないから。
相手を探しにいくことはないんですよ。
コンテナが必要な人をDIしてくれるんだから。

337 ：デフォルトの名無しさん：04/12/25 21:26:40

PoEAAを書いた頃にDIってあったの？

338 ：デフォルトの名無しさん：04/12/25 21:48:02

>>336
べつにここでDIを出してくる必要はないと思うんだけど。

それと、DIでオブジェクトが組み立てられて、個々のオブジェクトが単純で、少ない数のオブジェクトとしかやりとりしないからといっても、本質的な複雑さが解消できるものではないと思うよ。
本質的な複雑さというのは、系が閉じているときは一定なので、モデリングのやりかたで複雑さがかわるものでもないし。

339 ：デフォルトの名無しさん：04/12/25 22:09:43

ここでDIが出てくる必要はないな。
業務サービスベースで考えるので、そもそもの実装が「なんらかの特定業務に
関連した情報を返す」ということがモデリングのスタート地点になってる。

ドメインモデルは「おれのモデルでできることはここまでだよ。他の処理はほかの
モデルがやるんだろ？おれは知らんよ」という構成になっているので、各モデルの
位置づけを理解した上で、さらにそれがどうつながってるか理解しないと、何を
やろうとしているのか（何の業務を解決しようとしているのか）分からなくなる。

サービスベースでもサービスが増えればややこしいのは事実。DAOも含めると、３０
近いクラスが絡み合ってることもあるよ。
でもこの複雑さは、おれたちが普通に関数なりメソッドを呼ぶときに「あ、ここはちょっと
別のprivateなメソッドにでも分けるか」とかやってメソッド一つずつをシンプルにして、
１メソッド3000行とかならないようにするのと似てる。つまり機能が複雑になってきたし、
重複しそうだから、一部機能を＿機能として＿分割してるわけで。

おなじ絡み合っているのでも、つながりが追いやすいんじゃないかな。

340 ：デフォルトの名無しさん：04/12/25 22:34:46

たぶんそういうことだろうね。
業務が複雑になったときには、ドメインモデルを構築してないと、「なんらかの特定業務」すらどこで行っていいかわからなくなると思う。
でも、ドメインモデル構築自体の複雑さが問題にならなくなるような複雑なシステムはそれほどない、と。
たぶんシステムの多くを占めてる、流通系とかお店のシステムだと業務がそれほど複雑じゃなくて、商品・サービスの移動と「なんらかの特定業務」がリンクしやすいしね。

341 ：デフォルトの名無しさん：04/12/25 22:35:36

最近なんかこのスレ妙に建設的じゃねーか（w
でも悪くない気分

342 ：デフォルトの名無しさん：04/12/25 22:41:00

おれのおかげだな。

343 ：デフォルトの名無しさん：04/12/25 22:43:18

>>342のせいで気分が悪くなった

344 ：デフォルトの名無しさん：04/12/25 23:07:12

英語や技術を頑張るのは結構だが、先人を平気で禿呼ばわりする人格を
変えるのが先だと思う。それとも英語で書く時と日本語で書く時に
使い分けるつもりなんだろうか？
ほんと気分悪い。

345 ：342：04/12/25 23:13:06

>>344
それはおれは関係ないよー。
でも、気分が悪いことを思い出させてしまってごめんよー。

346 ：デフォルトの名無しさん：04/12/26 00:09:43

>>344
誰もファウラータンを禿なんてよんでないよー。

347 ：デフォルトの名無しさん：04/12/26 00:25:30

　「_￣ﾌ　　ﾉ^ｰ┐　///////////ノ/
　,-､二、　ｰク /　　7_／////////^
　`ー‐‐'　　`ｰ'　　　　 ///////し
　　 _l^l_　　i^i　i^i　　 ///////
　 / ,--┘　Ｕﾉ |　　//////^
　 !__ニｺ　　lﾆ.ノ　　7///　　　　_,,.. .　__
　__l^l__へ　 i^i　i^i　　//^　　　．．　＿　｀ヽ
　ﾞ┐r┐Tﾞ　∪ ﾉ |　 |/ 　　　/：：／.┬".)　　l
　く,ﾉr'_,ﾉ　　lﾆ.ノ　　７　　 _iゞ/ｲ｡_ﾉ　　　_r'''､
　　　|　　　 ,へ　,ﾍ　/　　　/ ﾆ-''^＼¨　　 ∠.} l
　　　|　　　　`ﾞ / /　|.　　　｜l､ヾ⌒-|　 u　 r_ﾉﾉ "
　　　|　　ヾ二ノ　　|　　　ヽ |`´_,--|　　i､ﾆイ
　　　|　　　 /,ﾆ^＼.　|　　　＼ｌ<-ﾆﾌ　,ノ ,.　＼、'
　　| | | |　　| しリj |　＼　　　＼￣ ,／ノ/　, |　Z
　　ﾟﾟﾟﾟ　　`ｰ" ｰ' 　〔　　　　　 /￣／ '", //／　,.

348 ：デフォルトの名無しさん：04/12/26 03:07:23

俺はどっちかというと344のような
学級会的道徳観の持ち主の方がすんごい気持ち悪い。
おえー。

349 ：デフォルトの名無しさん：04/12/26 09:51:18

もし>344が上司のことを影で悪くいいながら
本人の前で言わないようなことしてたら同じ穴の狢
他人に腹が立つのは大抵そこに自分を見るかららしいぞｗ

350 ：デフォルトの名無しさん：04/12/27 01:17:16

ファウラーたん議論が終わった感じだけど、蒸し返してみる。

ドメインモデルってMVCモデルのMを具現化したものだろ。でもくーすってMVCじゃなくて、
ヤコブソンのBCEを具現化したものだろ。Boundary-Control-Entityって用語を使ってる
ところからして。

BCEってMVCの問題点を解決するものとしてあげられてるんだし、MVCなドメインモデル
から見て矛盾があるのはいわば当然じゃないかな。

351 ：デフォルトの名無しさん：04/12/27 01:47:28

>>350
ファウラーのMVCモデルは、ウェブプレゼンテーション層の中だけの話。
アプリケーション全体をMVCにして、UI以外を全てMに押し付けるモデルは、EJBが重すぎて崩壊してしまったのを見ればわかるように、実際には使い物にならない。

352 ：デフォルトの名無しさん：04/12/27 01:58:28

J2EEのMVC Model2におけるMはファウラーたんのドメインモデルの領域だと思うが...

あとEJBが重すぎるのはリモートコールを多用するからじゃないか？
ローカルコールで動かすと、悪名高いEntityBeanですらそれなりの速度で動くぞ。

353 ：デフォルトの名無しさん：04/12/27 02:00:05

動作の重さを言ってるわけじゃないのだが・・・
それと、蒸し返すといっても、少なくともこのスレでMVCという言葉は出てきたことがないのだが。

354 ：デフォルトの名無しさん：04/12/27 02:09:43

そうだね....
じゃあ、蒸し返すのでなく次の話題ってコトでどうだろうか.....

355 ：デフォルトの名無しさん：04/12/27 02:22:10

いやぁ、MVC Model2なんて使い物にならないというか、どうにもならないことがわかってるので、話題としておもしろくない・・・

356 ：デフォルトの名無しさん：04/12/27 02:44:32

MVCmodel2だと、VがMからデータを得る。
でも、ファウラーのMVCでは、Vはドメインモデルとやりとりしない。
MVCmodel2とファウラーのモデルは対応しない。

というか、MVCmodel2で、やんちゃなV(JSP)と、たよりないC(Servlet)を与えられて、「あとはMです。ご自由に」と広大な空き地をおしつけられても、ねぇ。

357 ：デフォルトの名無しさん：04/12/27 08:11:08

ドメインモデルとしてのMは、ほんとにドメイン特有のオブジェクト群。
MVCmodel2としてVに渡されるMは、ドメインモデルとは別のものでVが必要とするM。

ドメインモデルのMからMVCmodel2としてのMへの翻訳が必要。
おれはかならずこの翻訳を意識している。
翻訳しないケースがあれば、それはたまたま両者が一致しているという特殊ケースと位置付ける。

358 ：デフォルトの名無しさん：04/12/27 08:55:23

>>357
そのMVC Model2のモデルとドメインモデルの変換コストの話が
http://d.hatena.ne.jp/higayasuo/20041207#1102379088
http://d.hatena.ne.jp/higayasuo/20041220#1103516338
で、ドメインモデルが工数がかかるという根拠になってるみたい。

結局話題がリンクしてる?

359 ：デフォルトの名無しさん：04/12/27 10:00:03

kusuに話をもどしていいかな？
kusuが対象とする開発は20-50人の中規模と思うのだけど、
開発者にDIについての認識を強要するのは酷な話。
少なくとも、開発者全員が一読するという代物ではない。
であれば、kusuって開発の方法論であって開発標準ではないよね。
この規模の方法論って他にもあるのに、なんであえて提唱したのか
よくわからないんだよなぁ。

360 ：デフォルトの名無しさん：04/12/27 10:53:43

>>357
翻訳といっても、その幅は広いよね。
インスタンスへのリンクを渡すだけのファサードな場合もあれば、ドメインモデルの全プロパティをコピーするDTOな場合もある。
357の意図してるのはどちら?

361 ：デフォルトの名無しさん：04/12/27 11:20:48

>359
同じ規模のものが他にあっても、提唱しない理由にはならないでしょ。
ほとんど同じものが他にあるなら別だけど。

362 ：デフォルトの名無しさん：04/12/27 11:33:58

一口にMVCと言っても色々。
http://www.google.co.jp/search?hl=ja&q=%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%81%8C%E9%A0%91%E5%BC%B5%E3%82%8B+mvc
とかBuschmann本とか。

くーすと「レガシーなオブジェクト指向」との距離は、
Webアプリへの最適化によるものだ、と言ってみるテスト。

363 ：デフォルトの名無しさん：04/12/27 12:28:39

どうでもいいけど、Seasarそっちのけだな。

DIスレと分けた意味はあるんだろうか？

364 ：デフォルトの名無しさん：04/12/27 12:41:18

>>362
Webじゃなくても、基本的には変わらんと思うが。

365 ：デフォルトの名無しさん：04/12/27 12:43:10

>>361
他のものとどこが違うか、よくわからない。
Seasarに依存するってとこ？

366 ：デフォルトの名無しさん：04/12/27 12:50:35

>>361
PofEAAの解説にしかみえないのは、俺だけ？

367 ：デフォルトの名無しさん：04/12/27 13:00:07

>>361
いや、比嘉氏は既存の中規模システム開発用の開発標準にでは
満足いかなかったのではないかと思う。つまり、RUPを軽くした
国内開発者向けの標準を作らなければならないという危機感が
あったのではないか、と、そんな気がする。
kusu本を出すなら、その辺の経緯も記してもらいたい。

368 ：デフォルトの名無しさん：04/12/27 13:40:28

開発者が俺一人な小規模組織にはくーすは不要ですか?

369 ：デフォルトの名無しさん：04/12/27 14:52:46

>>368
自分の技術レベルが低いと思ったら使えばいいんじゃないの。

370 ：44：04/12/27 20:02:55

http://d.hatena.ne.jp/higayasuo/20041220#1103529853
>話を簡単にするために常にデータと振る舞いを一緒にするというのは、
>それはそれでOK。
>
>ただし、機能が増えるにしたがって役割多すぎなクラスになる
>危険性があるということです。最初は、データと構造を一緒に
>しておいて、機能が増えてきたらリファクタリングすればいい
>という考えもあるかもしれません。しかし、それは、
>リファクタリングではありません。利用する側から見て
>インターフェースが変わってしまうからです。

インターフェース/クラスの内部でExtract Classしたクラスへ対して委譲すればいいだけでは?
そうすればインターフェースは変わりませんよね。

371 ：44：04/12/27 20:14:15

http://d.hatena.ne.jp/higayasuo/20041220#1103529853
>「データ構造を公開することによる疎結合性を妨害」という点では、
>永続化されるようなデータの構造は、もともとpublicですから特に
>問題にはならないと思います。

何に対してpublicなのでしょうか?

また、データ構造をクラスの外へ公開することによるデメリットとして、修正箇所がアプリケーション中に分散してしまうことなどがあると思いますが、publicであることはこのことに何か解決策をもたらしているのでしょうか?

372 ：44：04/12/27 20:18:34

つい責めるようなな口調になってしまいました。申し訳ないです。

373 ：デフォルトの名無しさん：04/12/27 20:55:20

>371
>修正箇所がアプリケーション中に分散してしまうことなどがあると

あっちこっち直すことになるかもしれないが、
どの業務機能から使われてるかが分かるから影響範囲が明確になる、とも言える。
これは高度に抽象化をおこなわないことによるメリットかな。

修正が難しいのはデータを「変更」する処理だろうが、それって分散して存在することは稀。
SeasarならS2Daoでエンティティ単位の管理ができるから、そんなに大変ではないだろう。
主として影響を受けるのは大抵は入力・表示関係。そしてそれはUI層の問題だから別の話になる。

374 ：デフォルトの名無しさん：04/12/27 23:23:59

みなSeasarやくーすにどうしてそんなに熱くなるのか，
だれか分析してくれ。

375 ：デフォルトの名無しさん：04/12/27 23:44:14

それにはまずロバストネス分析から始めないとだめだな。
バウンダリはなんだ？

376 ：デフォルトの名無しさん：04/12/27 23:59:28

>>374
パンダに熱くなったほうがいいのにね。

377 ：デフォルトの名無しさん：04/12/27 23:59:50

>>375
ひがたん

378 ：デフォルトの名無しさん：04/12/28 00:01:49

>>372
とりあえず、以後、他人に意見するのは止めることですね。

379 ：デフォルトの名無しさん：04/12/28 00:05:03

>>378
パンダに意見するのはOKですか？

380 ：デフォルトの名無しさん：04/12/28 02:29:38

s2jsfのexampleなんで、編集だけで、削除とか作ってないんだ？
「易しさと優しさ」とか言ってたのに、あとは、自分でやれってことか？

381 ：デフォルトの名無しさん：04/12/28 04:34:27

>>373
とりあえず前半部分は技術者の意見とは思えない。

後半は俺が読み違えてるのかもしれないので確認したいんだけど、
public属性の影響を受けるのは、値を設定するところじゃなくて
むしろ単純読込の方が量が多くて問題になる。

たとえばその属性の型が変わったり、setXXの時に小数点2桁で丸めたい、
という変更があったときに、アクセッサ経由で統一されている方が楽。
そのモデルのサブクラスを作って変数をオーバーライドしちゃうと
ベースクラス側でのメソッドの中でアクセスしてる変数と別物になっちゃうので
スマートな形でサブクラス化できないこともある。

膨大な繰り返し処理の速度を速くしたくてわざとpublic属性にすることは
あるけど、そういうのは基本を踏まえた上での小手先のテクニックとして
ソースにコメントをつけながらやることであって、できるだけ基本は
守っていた方がいい事が多い。

ひがさんはOOPのメリットをあまり理解できなかった側の人だと思うので、
44さんはもう突っ込まないであげればいいと思う。DI自体は悪くない技術だし、
彼らのモチベーションが高い方がseasarがいい方に行くと思うから。

逆にseasarが好きで変な方向に行って欲しくないからこそ、ひがさんにいろいろ
突っ込みを入れてるのかもしれないけど

382 ：デフォルトの名無しさん：04/12/28 04:36:35

>>380
そこはスローガンなんだからそんな言い方するこたあないだろ。
「削除も作ってほしいなあ」とか言えば気分良く作ってくれる人が
いるかもしれないのに。

383 ：デフォルトの名無しさん：04/12/28 08:07:41

s2jsfってjsfのコンポーネントぜんぜん使えんのか

384 ：デフォルトの名無しさん：04/12/28 08:27:57

>>381
うーん、何が言いたいのかよくわからんわ。

> たとえばその属性の型が変わったり、setXXの時に小数点2桁で丸めたい、
> という変更があったときに、アクセッサ経由で統一されている方が楽。

だったらそうすりゃいいじゃん。
>>381はフィールドをpublic属性にする話をしているように読めるのだけど...
永続化データがpublicだという話をそう読んだわけ？

永続化されるようなデータはそもそも構造が公開されてるもんだと
いう意味で、publicだと言ってるだけだと思うけど。

S2Dao使ったって結局各データにはアクセッサ使ってアクセスするんだし、
プロパティとして扱ってるから、アクセッサ経由だし。

385 ：デフォルトの名無しさん：04/12/28 09:32:41

>>380
何だくれくれクンか

386 ：デフォルトの名無しさん：04/12/28 09:40:36

>>376
何でパンダなんだ？

387 ：デフォルトの名無しさん：04/12/28 09:43:19

>>381

> 膨大な繰り返し処理の速度を速くしたくてわざとpublic属性にすることは
> あるけど、そういうのは基本を踏まえた上での小手先のテクニックとして
> ソースにコメントをつけながらやることであって、できるだけ基本は
> 守っていた方がいい事が多い。

すまん、膨大な繰り返し処理って具体的にはどんな業務ロジックなんだ？
想像できんので教えてくれ。

388 ：デフォルトの名無しさん：04/12/28 10:31:43

ひが君がpublished的な意味でpublicって言ったのが、
>>381に伝わらなかったってだけじゃないの。

ttp://www.martinfowler.com/bliki/PublishedInterface.html

まあﾏﾀｰﾘ行こうや。>>387

389 ：デフォルトの名無しさん：04/12/28 10:39:14

>>386
NHKみてなかったの？かわいかったのに。
「NHKスペシャル地球大進化生命の巨大化」の枠でやってたから、巨大化ってパンダのことかーっ、と思いながらみてますた。

390 ：デフォルトの名無しさん：04/12/28 11:34:24

ＯＯが開発効率の足枷になってる事に留意しろっつうの

391 ：デフォルトの名無しさん：04/12/28 12:34:36

org.seasar.dao.impl.DaoMetaDataImpl#createResultSetHandler
method.getReturnType().isAssignableFrom(List.class)
↓
List.class.isAssignableFrom(method.getReturnType())

じゃないか？

392 ：デフォルトの名無しさん：04/12/28 12:37:39

>>388
比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても影響ないってことだろ。

393 ：44：04/12/28 18:33:55

http://d.hatena.ne.jp/higayasuo/20041227#1104147737
>もともと永続化されるデータ、テーブルで管理されるようなデータ
>というのは、その構造は、ER図などで外部に対して公開されています。
>
>一般的に言われるようなカプセル化の話は当てはまりません。

外部の意味が曖昧なので推測で。

ここでい言う「外部」が
>>392
>比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても
>影響ないってことだろ。
ということであれば、それでもなお、カプセル化の話は当てはまると思います。カプセル化さえされていればクラスの内部で、Extract Classした先への委譲でも、Replace Type Code with State/Strategyでも、なんでもやりたい放題できますから。

また、「外部」が外部システム等であったとしても、若干の不自由は強いられるかもしれませんが、それでもなお上記の理由でカプセル化する利点は存在すると考えます。

394 ：デフォルトの名無しさん：04/12/28 18:45:41

http://game10.2ch.net/test/read.cgi/game/1104208080/l100
このスレ荒らしてあげて下さい。
ウイルス貼りまくっていいですよ。
歓迎します。

395 ：44：04/12/28 18:46:59

http://d.hatena.ne.jp/higayasuo/20041227#1104186174
>補足しておくと、ドメインモデルは、もともとデータを持ってる
>クラスに振る舞いを持たせたほうが良いという観点なはずです。それが、
>
>public class Employee {
> private PayCaluculator calculator;
> ...
> public BigDecimal caluculatePay() {
> return calculator.calculatePay(this);
> }
>}
>
>という形だということは、役割でクラス分割するのと実質同じです。

Extract Classは以下のように行うので
http://www.refactoring.com/catalog/extractClass.html
PayCaluculatorクラスができることはありませんです。

396 ：デフォルトの名無しさん：04/12/28 18:52:42

>>387
> すまん、膨大な繰り返し処理って具体的にはどんな業務ロジックなんだ？
> 想像できんので教えてくれ。

業務ロジックかどうかは微妙だけど java.awt.Point数万個を使うようなグラフィック処理。
あと、石油埋蔵量予測システム。(どっかで読んだ)

397 ：デフォルトの名無しさん：04/12/28 19:20:48

>>396
サンキュ。そういうやつか。俺の仕事では出会うことは無さそうでほっとした。

398 ：デフォルトの名無しさん：04/12/28 21:34:31

今更こんな事を聞くには恥ずかしいんだけど・・・・・・・

MAIN─Seasar─dicon
　　　　　　　　　　　　│
　　　　　　　　　　　　├クラスＡ
　　　　　　　　　　　　├クラスＢ
　　　　　　　　　　　　├クラスＣ
　　　　　　　　　　　　└クラスＤ

「SeasarとはクラスＡ－Ｄの纏め役で、どれを使うかdiconに
書いておけば、そのクラスを返してくれるもの。」
という理解で合ってる？ドキュメントを１ヶ月ほど読み耽って
やっとこ辿り着いた答えがコレだったんだけど・・・・・・

399 ：デフォルトの名無しさん：04/12/28 22:15:34

ひがさんにOOSEを読んでみて欲しいな。

400 ：デフォルトの名無しさん：04/12/28 23:21:27

>ひがさんにOOSEを読んでみて欲しいな。

ひがさんが問題としていることは、OOSEでも取り上げられているから。

401 ：デフォルトの名無しさん：04/12/28 23:36:56

>>398 すっげーおおざっぱには、それでよい。

402 ：デフォルトの名無しさん：04/12/28 23:44:35

初心者が１ヶ月読まないとそこにたどりつけないドキュメント。

403 ：デフォルトの名無しさん：04/12/28 23:46:47

http://d.hatena.ne.jp/higayasuo/20041228#1104228438
>その原因は、過度なデータ中心のクラス設計にあると私は考えています。
>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。

OOSEのP120~P129はその答えとなりませんか?

404 ：デフォルトの名無しさん：04/12/28 23:50:20

>>402
ちょっとコードを書けばすぐにわかると思うんだけどね。
最近はドキュメント読んだだけで済ませようとする人が
多いのでびっくりだ。

405 ：デフォルトの名無しさん：04/12/29 00:07:16

>その原因は、過度なデータ中心のクラス設計にあると私は考えています。
>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。業務アプリケーションなどはとくそうで、
>直接関係のない機能が1つのエンティティに押し込まれやすくなります。

そうなった場合に適宜リファクタリングしてやれば解決する問題だと考えます。

>また、複数のデータにまたがるような機能は、そもそも適したクラスに
>振る舞いを割り当てるのが難しくなります。

複数のデータにまたがるような機能が全てそうだとは言いませんが、どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ割り当てれば良い、と古のOOSEに記されています。そのことには異存ありません。
# UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが

データと振る舞いをひとつのクラスにまとめる。責務が多くなりすぎたらクラスを分割してやる。振る舞いを割り当てるのに適したクラスが無い場合はコントローラクラスとする。これでも駄目なのでしょうか?

406 ：デフォルトの名無しさん：04/12/29 00:18:26

>>404
読む人のせいにする筆者

407 ：401：04/12/29 00:33:02

>>402
最新版のドキュメントは、昔と較べると段違いに充実していると思う。
# S2JSFのドキュメントがないのは、正式公開前だし、しかたないだろう。
まさたかさんの入門記事も参考になる。
http://d.hatena.ne.jp/masataka_k/searchdiary?of=15&word=%2a%5bseasar%2dtutorial%5d
（もしかすると若干記述が古くてハマるかもしれん）。

俺はS2財団の人ではない。単なるファンだ。
だが、煽りが出たらごめん。> やすを氏ほか。
あと技術的な話をしているところを、側面的なネタで汚してすまん。

408 ：デフォルトの名無しさん：04/12/29 00:36:32

>>401
そうですか・・・・・・やっと、やっとここまで辿り着きました(;´д⊂ヽﾋｯｸﾋｯｸ

>>404
ぶっちゃけその通りです＞ドキュメント読んだだけで済ませようと
「Seasar = フレームワーク」と勘違いして、「クラスを切り替えられるのは分かったから、それ
で最終的にはどうなるんだ？」という明後日な視点でドキュメントを読み続けてました。

髭剃りを他の何かだと頑なに信じ込んでしまってる人が、説明書を見ながら「髭が剃れるのは
分かったから、最終的にどうなるんだ？」と途方に暮れてる姿を想像してもらえれば近いので
はないかと・・・・・・
勿論、結論は「だから髭が剃れるんだよ」というものなんですが、見てる方向が違うと辿り着け
ないんですね、これが＿|￣|○|||

最後に、とりあえず現在のところドキュメントに不満はありません。
目は何も見てはいない、見ているのは脳。という言葉をちょっぴり実感した年末でしたｗ

409 ：デフォルトの名無しさん：04/12/29 00:38:44

>>405
>複数のデータにまたがるような機能が全てそうだとは言いませんが、
>どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ
>割り当てれば良い、と古のOOSEに記されています。
>そのことには異存ありません。
> # UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが

余談ですが、昨今の、ロバストネス分析で導出されたコントロールクラスは設計モデルでそのままストレートにクラス化すべし、という風潮はあまり好きになれないです。
某オブジェクト指向本も読んでみたんですが、ドメインモデル貧血症推奨な感じで、なんだか。

RUPの人もICONIXの人も、分析段階でのコントローラクラスの責務はバウンダリかエンティティに割り当てる、もしくはコントローラ自体をクラス化する、と言ってるように思うんだが。
というか、スリーアミーゴはICONIXの人よりもきつい言い方をしてて

「コントロールクラスを実現するのに別々の設計クラスを用意するのは
適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」

と言ってるのだが。

410 ：デフォルトの名無しさん：04/12/29 01:16:38

S2のドキュメントは昔に比べたらめっちゃ充実ですね。
S2Daoもここのところリリースが多かったですが、追加したあのテーションとかも
ちゃんとドキュメントに反映されてるし。

411 ：デフォルトの名無しさん：04/12/29 01:19:31

>>409
>「コントロールクラスを実現するのに別々の設計クラスを用意するのは
> 適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
> 実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」

原文を知らないので良くわからないのだけど、それってStrutsで言えば、
Action内で直接エンティティにアクセスするってことかな？

412 ：デフォルトの名無しさん：04/12/29 01:44:34

相変わらずドキュメントネタしか突っ込めない>>406

413 ：デフォルトの名無しさん：04/12/29 02:59:21

どうでもいいが、S2JSFだけ早くリリース汁

414 ：デフォルトの名無しさん：04/12/29 10:04:49

さっぱり話についていけないので、とりあえずPoEAAを読み始めた。

415 ：デフォルトの名無しさん：04/12/29 10:41:39

ひがし
> blogに、これまでのオブジェクト指向の批判を書くのは、
> 私にとってはものすごくリスクの高いことです。なにを
> 言われてもおかしくないですから。現にいろいろ言われ
> ているわけですが、それでもあえて書いているのは、こ
> れまでのオブジェクト指向がなぜうまくいっていないの
> かを考え直すきっかけになればと思っているからなのです。

「これまでのオブジェクト指向」の定義と
「うまくいっていない」とする根拠を明確に示さないとただの
戯言．今までにない自分が始めて見つけた設計方法と認識して
いるならば非常に痛い．自らの失敗経験や知りえる範囲での失
敗を踏まえた程度ではないのか．

416 ：デフォルトの名無しさん：04/12/29 10:47:38

　　↑
OO厨ｷﾀｰ！

417 ：デフォルトの名無しさん：04/12/29 10:53:09

>>415
同じコトをファウラーﾀｿにも突っ込んでやってくれ。
http://www.nri-aitd.com/tips/image/g-patern_4.gif
は根拠が薄弱すぎるとひが氏なんかよりも罪深いぞ。
特に線の交差するところは重要じゃないか？
SQLのあまりにもな例といい結構ファウラーﾀｿも危ういと感じる。

418 ：デフォルトの名無しさん：04/12/29 11:17:33

>>417

いいんだけど、ファイル名が怪しい

419 ：デフォルトの名無しさん：04/12/29 11:23:16

もうね、GoF以上にソフトウェア開発の実装におけるパターン化をやろうとしても、
ムリだってことがハッキリしたと思う。

これ以上ソフトウェア開発を効率化しようとするなら、
例えば業務会計ソフトなら、会計ソフトをプラグインで柔軟に変更可能にするとか、
そのAPIをソースコードごと公開するとか、
そういう、実装が伴ったものになると思う。
EJBのようなアプリケーション固有の実装を伴わないフレームワークは必要無い。

420 ：デフォルトの名無しさん：04/12/29 11:25:26

Enterprise Applicationは個々に異なる、という前提があるので、残念。

421 ：デフォルトの名無しさん：04/12/29 11:28:02

>>420
わからん
前提があるからどうなんだ？

422 ：デフォルトの名無しさん：04/12/29 11:35:10

>>419
DI + II まだー？

423 ：デフォルトの名無しさん：04/12/29 11:48:15

実装を共有しようとするのは現実的でなく、
フレームワークやパターンや開発手法を共有するしかない、ということ

424 ：デフォルトの名無しさん：04/12/29 11:53:57

>>423
PhotoshopやEclipseはどうなんだ？
プラグイン毎にソフト作り直すのが現実的なのだろうか

業務ソフトだってその考え方をもっと進めなきゃいかんと俺は思う

425 ：デフォルトの名無しさん：04/12/29 11:57:30

現実には、業務ソフトにまともなプラグイン機構を持ったソフトは
未だ存在しないから、せめてムダなフレームワークを使わず
ただシンプルに作り抜くことが、今できることなんだろうと思うけどね。

426 ：デフォルトの名無しさん：04/12/29 12:26:00

>>417
原文読め
自分がネタにマジレスってことに気付くから

427 ：デフォルトの名無しさん：04/12/30 05:38:44

>>424
ベースを作ればあとは付加機能でしかないという分野以外で、同じようにプラグインの仕組みを考えるのはナンセンスだと思うが。
やっても意味がないという結論がでるようなことがらについて考えを進めても意味がなさげ。

428 ：デフォルトの名無しさん：04/12/30 10:34:34

ひがさんのblog
> 手を変え、品を変え、オブジェクト指向は説明されてきましたが、情況はそれほど好転しているように思えません。

続く文章も、手を変え品を変えたオブジェクト指向の説明に見えるので、状況がそれほど好転しない気がする。

429 ：デフォルトの名無しさん：04/12/30 12:05:33

>>427

確かに、同じようなプラグインの仕組みは、やるだけムダなのかもしれないし
けど、うまく設計すれば、うまくいくかもしれない。
設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。

S2やEJBは何の解決にもならないのは確か。
ならシンプルな技術基盤で作りたいね。
Javaを使ったウェブプログラミングがめんどくさいからいろんなフレームワーク
がでているわけで、なら別のプラットフォームを選ぶのがいいと漏れは結論した。
結果を出せるのはスクリプト言語だなと思ってる。

430 ：デフォルトの名無しさん：04/12/30 12:29:30

>>429
>設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。
なんだよ、他人事かよ・・

431 ：デフォルトの名無しさん：04/12/30 12:32:07

業務というもの自体がPlugableじゃないからね。
何か新しい業務が埋め込まれたら、既存の業務に必ず変化があるし。

Plugableにするために工程とかプログラムの部分部分がちょっとでも複雑になるなら、普通にシンプルに作って、わかりやすく変更できるようにした方がよさげ。

432 ：デフォルトの名無しさん：04/12/30 12:54:03

>>431

プラグイン機構を持ったソフトを売るか、それ自体を使ったソリューションビジネスを始めようってんでも
ない限り、そういう先を読んだ拡張性を重視するのは、危険だな。
You aren't gonna need itの原則だ。
まさに、普通にシンプルがよさげ。

まぁ、プラグイン機構を持つのに向いている分野もあれば、向いてない分野もあると思う。
向いている分野も結構あると思うんだけどね。

433 ：デフォルトの名無しさん：04/12/30 13:20:21

たとえば、金融商品を扱うとかで、商品自体がデータ構造とアルゴリズムを持つような場合は、取り扱い商品をモジュールとして追加できるようにするというのはアリだろうね。

434 ：デフォルトの名無しさん：04/12/30 14:25:34

>>429はDIスレに帰れ。

皆さんネタ厨に餌を与えないでください。

435 ：デフォルトの名無しさん：04/12/30 16:11:04

>>434

多分、無知だからだと思うんだ。
だから、スクリプト言語によるウェブシステム構築よりSeaserで作ったほうがイイ点、
勝ってる点を教えてください。

436 ：デフォルトの名無しさん：04/12/30 17:44:22

>>435
規模とか開発の人数によるよ。
スクリプト言語よりもJava+Seasarの方が、均質なコードを書くための労力が少ない。
均質なコードを書く労力が問題なければ、スクリプト言語でいいと思う。

437 ：デフォルトの名無しさん：04/12/30 20:38:38

マジにスクリプトのほうがコンパイル言語より基幹につかうに向いていると思ってるなら、死んだほうがいいな。

438 ：デフォルトの名無しさん：04/12/30 20:41:53

基幹っていっても、でかい基幹ばかりじゃないからなぁ。

439 ：デフォルトの名無しさん：04/12/30 20:46:22

5年くらい前なら、Javaで基幹系? 正気ですか? 医者よびましょうか? というような
感じだったような。今はどうであれ、先の事はわからない。

440 ：デフォルトの名無しさん：04/12/30 20:55:03

そのときでも、実務では使えないだけで実績がでてきたら使いたいというのがあったわけだけど、スクリプト言語の場合は・・・

441 ：デフォルトの名無しさん：04/12/30 22:17:47

>437
>440

だから、それはなぜかを示してほしい

442 ：デフォルトの名無しさん：04/12/31 02:11:36

素人には基幹系は無理。
Javaプログラマは素人。
よって、Javaプログラマには基幹系は無理。
以上。

443 ：デフォルトの名無しさん：04/12/31 02:57:28

>442
二番目が根拠無し

444 ：デフォルトの名無しさん：04/12/31 06:40:09

明らかにスレ違い。>スクリプト言語と業務アプリ
別のとこでやってくれ。

445 ：デフォルトの名無しさん：04/12/31 06:58:58

ここの話の流れだと、スクリプト言語とJava+Seasarを対比して、Seasarの特徴を知るという感じでもないね。

446 ：デフォルトの名無しさん：04/12/31 12:16:06

>>436

均質っていうけどなぁ、
均質にするのは方法論であって。
その方法論を実現するのには、コンパイルに依存しない
弱い結合が必要だっていうから、Seaserがあるわけでしょ。
コンパイル依存をなくしたいと思って行きつくところは、
動的なスクリプト言語ってことにならないだろうか？

それに、O/Rマッピングとか、ソフトウェアを複雑にする要因を
増やしてもしょうがないと思う。

447 ：デフォルトの名無しさん：04/12/31 12:32:32

>>446
実装との依存性はなくしたいだけど、
仕様(interface)との関係は明確にしたい。
仕様に合致してるかどうかはコンパイラにチェックして欲しい。

O/Rマッピングは関係無いと思うけど。
S2Daoの話なら別に複雑じゃないよ。

448 ：デフォルトの名無しさん：04/12/31 13:01:45

>>447

しかし、キャスト要らずのコードにするために、
あのdiで書かれた設定ファイルが必要になるわけで、
どっちにしろ動かしてみるまで分からないのは一緒だと
思うのだけど、どうだろうか。

それに、あのdiファイルってすごく冗長で書くの辛いしツール要るしで、
なんか本末転倒感が強い。

449 ：デフォルトの名無しさん：04/12/31 13:03:08

キャスト要らずってのは、間違いかな。どっちにしろ要るんだから。

450 ：デフォルトの名無しさん：04/12/31 13:21:45

業務ソフトは必ず一から作り直さないとダメ、
プラグイン機構を持ってもしょうがない、
ってな話あるけど、必ずしも、
そうでもない気がする。
ERPソフトの全てがネタだとは思わないし、
適切なインターフェースさえ定義して
そのインターフェースAPIの意図を素早く読み取って
プラグイン作る人さえそろえば、
少ない労力で結果として効果の高いソフトが作れると思うよ。

451 ：デフォルトの名無しさん：04/12/31 13:38:52

確かにコンフィグ系コンテナって設定ファイルが冗長だよな。
S2は特にそうだ。

452 ：446,448,449,450 ◆iKwMOjCT4s ：04/12/31 13:54:34

そもそも、コンテナとは何か？
言語本来備わっている名前空間機能ではいかんのか？
と思うわけだな

453 ：デフォルトの名無しさん：04/12/31 13:55:39

モチツケ。

454 ：デフォルトの名無しさん：04/12/31 14:19:36

>>450

> 適切なインターフェースさえ定義して
> そのインターフェースAPIの意図を素早く読み取って
> プラグイン作る人さえそろえば、
> 少ない労力で結果として効果の高いソフトが作れると思うよ。

そうだな。早く藻前がそれを作って公開すればみんなそれがどれくらい素晴らしいか理解できると思うよ。
とっとと作れ。

455 ：デフォルトの名無しさん：04/12/31 14:19:51

>>448
また、使ってないやつがコメントしてるのか。
S2は自動バインディングがほんとだから
DIについてはクラスの登録以外はあまりすることがない。

Springの設定ファイルについて文句あるなら、
Springすれでどうぞ。

456 ：デフォルトの名無しさん：04/12/31 15:17:34

スレ違い+勘違いUzeeeeeeeeeeeeeeeeee!!!

457 ：デフォルトの名無しさん：04/12/31 18:22:16

比嘉氏のドメインモデルに対する懸念には同意だ。
ビジネスモデルも柔軟性があり、いい発想だ。
しかし、ドメイン分析をまともに出来る奴がいねーのは問題だわな。
巷にはノウハウ本が溢れているが、だーれも読んでねーってことだ。
読者がアホなのか、執筆者がアホなのか。
まぁ、後者だろう。

458 ：デフォルトの名無しさん：04/12/31 21:15:26

>>457
> 読者がアホなのか、執筆者がアホなのか。
> まぁ、後者だろう。

○ージス総研と○蔵に通報しますた。

459 ：デフォルトの名無しさん：04/12/31 23:10:34

>>458
つうか、日本でドメイン分析をまともにやったプロジェクトはないだろ。
あるなら教えてくれ。
まぁ、未経験者の執筆した本でも趣味でやってる奴には楽しめるかもしれん。

460 ：デフォルトの名無しさん：04/12/31 23:30:24

もし仮に、diconをポトペタできる様なRADツールが存在したとして、需要が有るか否か
もし仮に、diconをポトペタできる様なRADツールを作るとして、実現可能性はどれくらい
あるか？
または既にそういったツールが有るのか否か、情報提供キボーン

461 ：デフォルトの名無しさん：05/01/01 00:14:37

>>460
こんな年の暮れに何をかいとんねん。
もう新年だけど。
diconをぽとぺたする意味が良く分からん。
ツールならKijimunaはけっこう良くできてるよ。

462 ：デフォルトの名無しさん：05/01/01 02:32:56

皆様、あけましておめでとうございます。
なにはともあれ、今年もIT屋さんとしてがんばっていこうではありませんか ;-)

463 ：デフォルトの名無しさん：05/01/01 17:06:34

>>455
自動バインディングのために、クラスに定数定義したり、
やっぱりxml書かなきゃいけなかったりする。

そこまでする理由ってのが、どうにも見つからないんだな。
結局、Javaプラットフォームがプログラミングしづらいから、
なんとかカバーしようとしているだけとしか思えない。

464 ：デフォルトの名無しさん：05/01/01 17:39:59

だからJavaでやる意義を問いたいならスレ違いだって言ってんだよ。

465 ：あなたの運勢は【ぴょん吉】ですから!!残念っっ!!：05/01/01 17:46:02

m9(^Д^) ﾌﾟｷﾞｬｰ

466 ：デフォルトの名無しさん：05/01/01 19:08:51

>>464
いや、漏れが一番知りたいのは、
Seaser作る人使う人が
ウェブ／データベースプログラミングをJavaでやると選択した理由なんだよ。

漏れの知らない深い理由があるのではないかなと。

467 ：デフォルトの名無しさん：05/01/01 20:44:15

>>466
・CGIは力不足
・mod_{perl,ruby}は挙動が怪しいときに追うのが辛い
・PHPは言語仕様が糞

あとは別ﾇﾚでどうぞ

468 ：デフォルトの名無しさん：05/01/01 20:51:24

>>467
モチツケ

469 ：デフォルトの名無しさん：05/01/01 20:58:13

>>461
実は俺>>391なんです。
Kijimunaの存在自体知りませんでしたorz

ただ、それはそれとして、設定ファイルを書くのが面倒という意見が多いんで
工夫できないものなのかな？工夫する為のツールは存在しないのかな？存
在はしてるけど認知度が低いのかな？認知されてるけど機能が足りてない
のかな？等々、現状どうなってるのか不思議に思ったものでネタ振りしたつ
もりだったんですが・・・・・・スベっちゃいました。

「手書きが面倒」という感覚は、ある種の人達(例えばLinux畑の人達とか？)
にはどう説明しても理解してもらえないんで、もしかしたらSeasar使いの人達
もその類の人達なのかと思ったんですが・・・・・・

実際のとこ、どうなんでしょう？

470 ：469：05/01/01 21:00:04

間違えた、>>391ではなく>>398です。

>>391さんは無関係です。申し訳ない、ごめんなさい。

471 ：デフォルトの名無しさん：05/01/01 21:20:04

>>466
積極的に選ぶ奴もいれば仕事上仕方なしに使う奴もいるさ。
理由はそれぞれ。Javaを使うと決まったときに少しでも楽するために
S2を使うだけだ。気にしないでキミは自分の道を行くのが良かろう。

472 ：デフォルトの名無しさん：05/01/01 21:21:24

>>469
手書きが面倒だからといってVBみたいになれば楽かというとそうでもなかろう。
少なくともKijimuna使ってる分にはそんなに苦労はしてない。

473 ：.net厨のお年玉は【1519円】でした：05/01/01 21:34:24

(　´д)ﾋｿ(´д｀)ﾋｿ(д｀ )

474 ：469：05/01/01 22:01:01

>>472
「そんなに苦労はしてない」この言葉にはとても多くの意味があって・・・・・・

例えば、Linuxのlilo.confは手書きです。これは設定ファイル自体が非常に
単純で、GUIエディタを作るまでもないというのがLinux畑な人達の言い分な
んだと思うんですが、一方でグラフィカルなブートマネージャに対する人気
は凄く高いという側面もあります。

決して批判してるわけではないんですが(批判できるほどSeasarを理解でき
てませんorz)、使いこなしてる人ほど見えなくなる部分みたいなんで一石を
・・・・・・MSはそういうとこ上手いと思う。

て言うか、俺自身が更にSeasarやEclipseを学んで、ポトペタdiconプラグイン
for Eclipseとかを作れる様になればいいんですけどね・・・・・・遠いなぁ（´д｀；）

475 ：デフォルトの名無しさん：05/01/01 22:47:11

>>467

> mod_{perl,ruby}は挙動が怪しいときに追うのが辛い

これは、例えば、どういうとき？

476 ：デフォルトの名無しさん：05/01/01 23:48:52

>>469

私は手書き派ですが、diconファイルをクラスごとに用意してます。それでパッケージ単位でインクルードしたdiconファイルを用意していて、サブシステム単位でそれをインクルードして、さらに全てをインクルードしてます。
で、GUIでこれを出来たら楽という考えを持っています。その一方で、テスト用のdiconファイルを作っているのでそれを任意に出来るようなGUIが想像できないです。そこら辺のイメージが湧かないとGUIの評価も出来ません。
システムは多数の人間で開発するものですので、自分の変更がほかの人に迷惑をかけないようなファイル分割や、チェック方法や、排他方法を望みます。
それが可能ならGUIでもいいんですが。

477 ：469：05/01/02 00:19:49

>>476
ごめんなさい。書き込み内容の1/10も理解できませんorz

イメージとしては、GraphEdit(DirectShowFilterの接続をグラフィカルに
設定するMS製ツール)なんですが・・・・・・
dicon用GUIエディタをGraphEditの様なUIで表現可能なのかどうかが
先ず分かりませんorz^256

478 ：デフォルトの名無しさん：05/01/02 02:41:56

いや、別に単に「自分でファクトリつくるのめんどいなあ。S2でやっちゃうか」でも
十分に存在価値はあると思うんだけど。intercepter機能を一切使わなくてもね。

PHPはもうちょっとオブジェクト指向面で実績ができてからかなあ。
あと何でも連想配列でなんとかしていくのも俺は気持ち悪い。
Bean書く手間をかけても、そっちのほうがいい。それが俺のJavaを選んだ理由かな。

479 ：デフォルトの名無しさん：05/01/02 02:47:50

classファイルをドロップするとファイル位置を元にclassロードして、リフレクションで
完全クラス名を取得して自動的にdiconひな形作成して、GUIでプロパティ設定とか、
コンストラクタ設定とか、インターセプターとか設定できるようにすると面白そうだと
思う。

実現可能性（誰が作るのかとか）をとっぱらって考えると、こういうツールは敷居を
下げてくれるし、重要な要素だと思うよ。手書きで間に合ってる人はいらんだろうけ
ど、手書きXMLに敷居を感じる人間もいるわな。すそ野を広めようと思えば考慮す
る価値はあるよね。

俺はdicon手書きでもkijimunaでそれほど困ってないけど、正直GUIツールがあったら
便利だと思うね。チームの連中にdiconの概念を説明する手間が若干省けるし。

480 ：469：05/01/02 12:44:09

>>478
寧ろintercepter機能(S2AOPの事ですよね？)が使いたくてSeasarを追
っかけてます。まぁ、逃げられっぱなしなわけですがorz

例えば、今は単純なベタテキストのログを出力してるけど、将来的には
XMLで出力したい、いやいっそSYSLOGdへ出力したい、まてまてHTML
で出力してWEBブラウザで見るのも捨て難いぞ等と考えた時、それ用
のクラスを書いてdiconを編集するだけで、色んなログの出力が実現で
きるのだとしたら、とても便利そうだぞと、思ったんですが・・・・・・・

もっとも、この発想自体が間違ってる可能性も大アリなんですが（´д｀；）

481 ：デフォルトの名無しさん：05/01/02 13:37:34

漏れはGUIよりも、XDocletで吐き出せる方が嬉しいな。
読み込み順とかも重要だから難しいかなぁ。

482 ：デフォルトの名無しさん：05/01/02 13:45:40

>>480
その発想は間違ってないけど、すでにApacheのLog4Jで実現されてるので
そっち使った方が早い。Log4JはSeasar自身も使ってるし。

483 ：デフォルトの名無しさん：05/01/02 13:46:16

あ、いうまでもなく、ログ出力の多様化の話ね。

484 ：デフォルトの名無しさん：05/01/03 01:09:26

ttp://d.hatena.ne.jp/higayasuo/20050102#1104650907
＞Seasar3はJ2EE Development with EJBなのです。

( ´_ゝ`)ﾌｰﾝ

Seasarいらねじゃないの？
結局EJB最強ってことか

485 ：デフォルトの名無しさん：05/01/03 03:01:28

今S2で作ってるシステムはS3が出たらどうすればいいんだ。すごく不安になってきたよ。

486 ：デフォルトの名無しさん：05/01/03 08:41:27

>>485
漏れはアンチSeaserだが、
バージョン間の互換性問題はどこの世界にもある話。
PHPは本当に酷かった。

487 ：デフォルトの名無しさん：05/01/03 08:55:32

>>485
だから、リファクタリングの原則だ。
これができてればバージョン上げるくらい楽勝だ。

488 ：デフォルトの名無しさん：05/01/03 09:32:05

なんか新年早々えらいこと言い出しましたね。
バージョン間の互換性というより、根本的に考え方が違う。
-Seasar3がでたらSeasar2どうなる。メンテナンスするの？
-今開発中のS2*シリーズは影響受けないのか？
あたりが気になる。

ttp://d.hatena.ne.jp/higayasuo/20050102#1104650907
のコメントを見ると、取り巻き達もこの件は知らなかったの？
S2マンセーな方々がどういう反応するかな？

489 ：デフォルトの名無しさん：05/01/03 09:40:02

Seasarの中の人も大変だな

490 ：デフォルトの名無しさん：05/01/03 09:51:05

>>487
売りであるS2Daoが全然変わっちゃいそうだから
リファクタリングというより作り直しになっちゃいう。

491 ：デフォルトの名無しさん：05/01/03 10:42:40

ttp://d.hatena.ne.jp/higayasuo/20050103#1104716008
＞Seasar3は、Seasar2とは全くコンセプトが異なるので、基本的に互換性はありません。
＞でも、Seasar2を使われている方は、心配する必要はありません。
＞Seasar2は、今後も開発を続けます。J2SE5にも対応します。
＞今後も主力は、Seasar2 + S2ファミリーということになります。

あ～やっぱり。そうなるとS2/S3の２系列になる。それも悩ましい。

492 ：デフォルトの名無しさん：05/01/03 10:54:48

ひがたんは、ビジネスモデルとドメインモデルの違いを理解していない模様．

493 ：デフォルトの名無しさん：05/01/03 11:21:14

>>492
ドメインモデルもビジネスモデルもちゃんとした定義なんてないと思うよ。
もしかして、DDDの定義がちゃんとした定義だと思ってるとか。

494 ：デフォルトの名無しさん：05/01/03 12:44:45

ビジネスモデルはビジネスが成り立つことを表すためのモデル
ドメインモデルもシステム化対象となる問題領域を捉えるためのモデル
という理解ではだめか？

495 ：デフォルトの名無しさん：05/01/03 13:09:07

>>494
それは、それで違和感ないけど、みんないってること違うからね。
いまのところしょうがないんじゃないかな。
ファウラーたんがきちんと定義してくれたらそれがデファクトになるかもね。
ただドメインモデルの定義も
http://martinfowler.com/eaaCatalog/domainModel.html
でいいのかなぁって気も。

496 ：デフォルトの名無しさん：05/01/03 13:30:27

>>491
つまりSeasar3が作られたとしても、使うメリットは少ないってことだな。
Seasarという名のもとに違うコンセプトのものが語られて、開発リソースの分散と混乱をまねくだけまねいてあぼん、か。
先が見えたな。

497 ：デフォルトの名無しさん：05/01/03 13:44:03

>>496
藻前は、Seasar2もつかってないんだろうから、Seasar3も使わなくて良いよ。
ちなみに、Seasar2がでたときも、Seasar1と全く違うコンセプトのものだったよ。

498 ：デフォルトの名無しさん：05/01/03 14:08:00

ビジネスモデルをおもいっきし間違えてる。
ひがさんの言ってるビジネスモデルは「業務フロー」(ビジネスフローとでも言えばいいか)。
業務フローのなかで特有のモデルがドメインモデル。
常識的な範囲で、ビジネスモデルは儲ける方法のことだし。

煽り抜きで、ちょとがっかりした。

499 ：デフォルトの名無しさん：05/01/03 15:35:59

>>497
そのときは、Seasar1を捨ててSeasar2に移行したわけだろ。
まるっきりコンセプトを変えた新版を出して、旧版はそのまま継続って、そしたら新版使う理由なんかないよ。
開発リソースも限られてるわけだし、どっちかに偏らざるを得ない。
S2に偏るならS3は縮小していくし、S3に偏るなら移行のタイミングを与えられないままS2の利用者も減っていく。
違うコンセプトで同じ名前の２つのプロダクトを、混乱しないようにプロモーションする力があるようにも思えないし。

500 ：デフォルトの名無しさん：05/01/03 15:54:48

>>498

>ビジネスモデルとは、実際におこなっている業務、あるいは
>これからおこなおうとしている業務の形態・仕組みを指すこととします

といっているから、別に業務フローじゃないんじゃないの。
http://d.hatena.ne.jp/habuakihiro/20050103#1104733873
でいってる前者ってやつかな。
それによるとやはりちゃんとした定義はないということだけど。

それにしても、自分の考えと少しでも違うとまちがってると
いうやつが多いね。
2chだからそんなものだが。

501 ：デフォルトの名無しさん：05/01/03 16:16:34

S3の必要性がわからんな。

502 ：デフォルトの名無しさん：05/01/03 18:14:15

S3なんかまだ誰も望んでない、手前のS2JSFを確実に仕上げてくれ。

503 ：デフォルトの名無しさん：05/01/03 20:14:21

>>502
禿胴。S3なんてことしなくてもS2EJB3でいいじゃんと技術に疎い漏れが逝ってみるﾃｽt

504 ：デフォルトの名無しさん：05/01/03 20:14:38

>>499
> 開発リソースも限られてるわけだし、どっちかに偏らざるを得ない。
> S2に偏るならS3は縮小していくし、S3に偏るなら移行のタイミングを与えられないままS2の利用者も減っていく。

これはSeasarの開発陣の少なさを考えると杞憂とは言い切れんな。
取り巻き/応援団は結構多そうだが、実質開発リソースは１人だからな。
まぁ二兎追うものは(ry

505 ：デフォルトの名無しさん：05/01/03 20:44:44

EJBと比べてて思うんだが、S2で、アプリケーションサーバ（つまりS2Containerが動いている
ところ）だけ物理的に別サーバに写そうと思ったらどうしたらいいのかな。

EJBだとJNDIとRemoteHomeとでリモートでのメソッド呼び出しに対応できそうだけど、
たとえばStruts+S2で稼働してたとして、負荷が高くなってきたのでS2で作ったサービス
層を複数サーバにして、合わせてStrutsのプレゼンテーション層と物理的に分離しよう
としたとする。どういう方策があるだろうか。

おれがちらと考えたのは、Struts -> EJB -> S2 というように、間になんかリモート呼び出し
に対応した層を挟むしか思いつかないんだけど。

506 ：デフォルトの名無しさん：05/01/03 21:04:10

>>505
そこでS2Remotingですよ。

507 ：デフォルトの名無しさん：05/01/03 21:55:05

S2Remotingってどうなったの？
一向にリリースの気配がないようだけど。

508 ：デフォルトの名無しさん：05/01/03 21:56:09

>>505
Webコンテナごと横に並べればいいじゃん。

509 ：デフォルトの名無しさん：05/01/03 23:16:32

>>508
プレゼンテーション層とサービス層とDBを物理的に分離したい、と言われることは
十分あり得ることだろう。というか別件で言われたんだよ。そういうときS2ならどうなる
のかな、と。

510 ：デフォルトの名無しさん：05/01/04 00:28:40

ところでS3のコンセプトって何だろうね。それが素晴らしいなら応援する。
S2がDI+AOPで生まれ変わったのは素晴らしかったと思う。
S3はDI+AOPを捨てさるような新しい何かを考えてるんだろうか。
漏れにはどうもS2の作り直しにしか見えないので不安だ。

511 ：デフォルトの名無しさん：05/01/04 00:32:48

>>509

そこまで分離したほうがいいシステムって、
どういうもんかなと思ったんだが。思いつきで言ってるというか、
システム派手にしたいだけな臭いがしてくるんだけど。

Rubyのtuple spaceの実装例はけっこう感動した。これを使えば
物理的にネットワークに繋げれば自動的にサーバ同士が連携して処理速度上げたり
クラスタリングのやり始めたり、というカッコイイことも可能だ。
そんなことやったほうがいいような機能を求める顧客には、会った事はないが！

512 ：デフォルトの名無しさん：05/01/04 00:39:43

>>511
ハードをたくさん売るために決まってるだろｗ

513 ：デフォルトの名無しさん：05/01/04 00:46:26

>>511

で、顧客は次にこういうのだ。
「ハード一台で済むシステム作れないかな。台数少ないから、予算は前の1/4で」

こういう素人を超えたITオンチが今のシステム屋を支えているのだ
なんのために生きてんだろ！

514 ：デフォルトの名無しさん：05/01/04 11:37:10

>>511
DBさえ多重化していれば良いという程度のシステムばかりではないんですよ．

515 ：デフォルトの名無しさん：05/01/04 11:59:53

>>500
はぶのいうことは話半分で聞いたほうが良いよ．
ttp://www.atmarkit.co.jp/aig/04biz/businessmodel.html

516 ：デフォルトの名無しさん：05/01/04 12:29:04

ビジネスモデルでぐぐったがよくわからん。定義が曖昧ということはいえそう。
はぶ氏のも曖昧な中のひとつの自説ということじゃないだろうか。

517 ：デフォルトの名無しさん：05/01/04 12:42:34

大体ビジネスなんて言葉を使う時点で胡散臭いもんだ

518 ：デフォルトの名無しさん：05/01/04 12:46:50

>517
そこまで戻って話をせにゃならんのか？
でもまぁ、身のある話をするにはそうなのかもしれないな。
でかい声で言ったもん勝ち、それを分かった気になったもん勝ちな業界だし。

519 ：デフォルトの名無しさん：05/01/04 12:53:30

大体コンテナなんて言葉を使う時点で胡散臭いもんだ

520 ：デフォルトの名無しさん：05/01/04 13:50:03

はぶ氏とひが氏が誰を指すかの定義もあいまいなのか・・・

521 ：デフォルトの名無しさん：05/01/04 14:00:26

この時期にS3の話を聞きたいと思う奴はいないよな。
「別系列」ってゆーけど、S2=前Version=時代遅れ、と認識する人が多いだろう。
しかも、順調に行けばGW明けにそうなる。
そーゆーS2をこれからもメンテする献身的な人がどれだけいるか疑問だ。

http://d.hatena.ne.jp/habuakihiro/20050104#1104805780
＞Tiger対応とS2JSFリリースは、S3に関係なく最優先でお願いしたい事項です。

本音だろうな。他に頼む人いないし。

＞この辺は主としてマーケティングの話になってくるんでしょう。

ぷっ。

522 ：デフォルトの名無しさん：05/01/04 14:05:05

やっぱりEJBでないとダメな局面があったのでは。
それが技術的なものかどうかは知らないが。

523 ：デフォルトの名無しさん：05/01/04 14:13:57

分散させる場合は、EJBがいいよ。
EJBは分散技術だし。
EJBが提案されたときは、分散システムが主流になると思われてた。
実際には、分散が必要になるシステムは、非常に限られていたってことだ。

524 ：デフォルトの名無しさん：05/01/04 14:46:28

分散厨は実践J2EEシステムデザインとPofEAAを読みなさい。

525 ：デフォルトの名無しさん：05/01/04 16:14:48

>>517
businessという英語を外来語として日本語化したときに、胡散臭さが付け加えられてしまったからな。
システムとかエンジニアとかSEとかマネージメントとかDIコンテナとか、似たような例はたくさん。

526 ：デフォルトの名無しさん：05/01/04 21:31:40

つまり業界全体が胡散臭いと。
まああってるかもしれん。

527 ：デフォルトの名無しさん：05/01/04 21:40:19

要はOAだよな。

528 ：デフォルトの名無しさん：05/01/04 21:58:48

OriginalAnime？

529 ：デフォルトの名無しさん：05/01/04 22:11:17

S3のコンセプトは「優しさと易しさ」じゃなくて
「J2EEにフィードバックすること」なのかな。

530 ：デフォルトの名無しさん：05/01/05 05:28:55

S3のコンセプトは「自己顕示欲」です。

531 ：デフォルトの名無しさん：05/01/05 10:17:01

>>524

毛唐のやつらは複雑なこと VS. 簡単なこと
をポリシーなく立場を入れ替えながら争うのがそもそも好みですから．残念

532 ：デフォルトの名無しさん：05/01/05 10:43:37

なんかこのスレ文系臭い

533 ：デフォルトの名無しさん：05/01/05 20:44:24

行動を伴わなければ趣味でしかないような学びは雑学でしかない。
もしくは
人の仕事というのは趣味の延長でしかない

534 ：デフォルトの名無しさん：05/01/05 21:58:32

>>533
誤爆か？

535 ：デフォルトの名無しさん：05/01/05 23:38:53

>>534
誘爆かと。
ttp://d.hatena.ne.jp/habuakihiro/20050105#1104915865

536 ：デフォルトの名無しさん：05/01/05 23:55:06

S2ともくーすとも関係ないな。ストーカー怖い怖い。

537 ：デフォルトの名無しさん：05/01/06 00:01:43

せくーすしたいなあ…

538 ：デフォルトの名無しさん：05/01/06 00:45:44

「関係者の掲示板に貼り付いてチェックしてるアンチ」
の図を妄想してる輩はBloglinesを知らないんだろうか。
まさか。

539 ：デフォルトの名無しさん：05/01/06 01:18:24

>>538
スレと関係ないことまでいちいち書き込むあたりが怖いってことだろ。
>>533がストーカーかかまってくんか追っ掛けか知らないけどな。

540 ：デフォルトの名無しさん：05/01/06 11:28:21

>>535
彼はNIFTYのフォーラムにはまっていた頃からはったり雑学やろうでくちばっかりの
男でした．
>> 某スレ
酔うと伝票めくりをしていた時代からの成り上がり話をぐたぐた話すのは
いつもの十八番だ．たしかにうざい．

541 ：デフォルトの名無しさん：05/01/06 11:44:00

>540
句読点までこだわるとは、
手の込んだことをおやりになる。

542 ：デフォルトの名無しさん：05/01/06 11:58:16

>>540
一緒に飲んでるんだw
その場で説教してやれ
はぶｦﾁでｽﾚと関係ない
こと書くなｳｻﾞｲ

543 ：デフォルトの名無しさん：05/01/06 12:23:42

その場で説教すると何がおきるのかな？
だれか適当な聞き役をあてがって、その場を去るのが無難だね。

544 ：デフォルトの名無しさん：05/01/06 12:52:43

ヒガ氏、次のネタカモン

545 ：デフォルトの名無しさん：05/01/06 15:49:56

NIFTYの頃からヲチしてるて・・
S2周りの人大変だな。

546 ：デフォルトの名無しさん：05/01/07 13:28:56

にじみ出るふいんきは騙れませんよ。

547 ：デフォルトの名無しさん：05/01/07 18:33:36

S3の前に、S2のAOPをもうちょっと強力にして欲しい。AOPAlliance自体が
まだしょぼしょぼだから仕方ないのかも知れんが、現状のS2AOPの程度では、
お子ちゃまみたいなログ取りインターセプタか、トランザクション管理
くらいにしか使えない。
AOPはその程度でいいんだ、っていうならそれでいいんだけど・・・

548 ：デフォルトの名無しさん：05/01/07 19:18:18

AOPはその程度でいい

549 ：デフォルトの名無しさん：05/01/07 20:07:55

AOPなんて見えないgoto文みたいなもん。
その程度で済ましとかないと保守不能になる。

550 ：デフォルトの名無しさん：05/01/07 21:44:05

AOPを駆使しまくって実装されたシステム、保守すること考えたら憂鬱だな。
どこでなにが起きるか把握するだけで疲れそう。

551 ：デフォルトの名無しさん：05/01/07 22:56:41

そういや、各AOPのパフォーマンス比較が以前あったみたいだけど、S2AOPはどれくらいの能力なんだろうね

ttp://www.theserverside.com/articles/article.tss?l=AspectWerkzP1

552 ：デフォルトの名無しさん：05/01/07 23:32:05

>>547
どう強化されたらどんなことに使える?

553 ：デフォルトの名無しさん：05/01/08 00:57:30

日経ソフトウェアで、だれかがAOPについて書いてたね。
読みながら、コワイコワイと思った。

554 ：デフォルトの名無しさん：05/01/08 12:39:22

AOPって結局なんなのかイマイチ分かってませんが、S2AOPに限れば
必要な時にdiconを開いてみるだけで済みそうに思うんですが・・・・・・
大した使い方してないからそう思うのかもしれないけど・・・・・・

555 ：デフォルトの名無しさん：05/01/08 14:54:22

AOPはトレース埋める位にしないと。コミットとかロールバックを任せたら大変な事に。

556 ：デフォルトの名無しさん：05/01/08 14:58:19

>>555
詳細ｷﾎﾞﾝ

557 ：デフォルトの名無しさん：05/01/08 15:27:51

>>556
ねたにつられるなよ。
トランザクション制御は、AOPに向いてる代表的な機能の1つなんだから。

558 ：デフォルトの名無しさん：05/01/08 19:27:53

>>554
ある処理で何が起こるか正確に把握するために、diconファイルのすべてに目を通す必要が出てくる。

559 ：デフォルトの名無しさん：05/01/08 21:07:15

なんで「すべてに」なの？

560 ：デフォルトの名無しさん：05/01/08 21:59:42

投下してみるか
ttp://arton.no-ip.info/diary/20050103.html#p01

561 ：デフォルトの名無しさん：05/01/08 22:07:41

>>559
どこでどのオブジェクトにアスペクト仕込まれてるかわからなくなるから。
自分だけでコーディングするなら問題ないけどね。

562 ：デフォルトの名無しさん：05/01/09 03:19:38

ん～
適切にdiconファイルを分けておけば、「すべて」を見る必要はないような…？
まあ、あとはドキュメントとかコメントで対応するとか（アテにならん場合が多いけど）

563 ：デフォルトの名無しさん：05/01/09 04:04:37

>>562
オートインジェクションとか考えると。
適切に分けられてるかどうか確認しないといけないし。
ドキュメントは、コードがドキュメント通りになっているかの確認が。

自動的になにかするようなコードから追えないものは、オートインジェクションも含めて、コードを追うのが難しい。

564 ：デフォルトの名無しさん：05/01/09 05:55:15

追うのが難しいのは本質的にどうしようもない希ガス

管理手法の確立とそれの徹底をすればいいんだろうが、それだとコードとは
別なところに、全面的ではないにしろ大きく依存することになるわけだから、
それほそれで面倒な問題を孕むしな('A`)

管理とか保守をするのにソースコードとdiconファイルからインジェクションされてる
対象とその内容が簡単に視認できるようなツールがあるといいよなあ

まあ、漏れは今のところkijimunaで間に合ってるけど、AOPを非機能要件以外
のあれやらこれやらに使いたかったりするなら、保守の難しさが軽減されるような
何らかの仕組みなりモノがないとさすがにやってられないだろうな

565 ：デフォルトの名無しさん：05/01/09 19:47:41

>>564
> 保守の難しさが軽減されるような
> 何らかの仕組み

それは、Seaser非依存OOPプログラミングだ

566 ：デフォルトの名無しさん：05/01/09 20:11:19

>>565
現状に満足してるなら、別にそれでいいと思うよ。

567 ：デフォルトの名無しさん：05/01/09 20:38:48

Seasarを使い込んでる人に聞きたいんだけど、もしかしてdiconてかなり巨大
なツリー状になる？
メンテナンスが大変な事になってるdicon一式(実際の場面に即したdiconなら
擬似サンプルでも良くてclassとかの本体は不要)公開してもらえないですか？

568 ：デフォルトの名無しさん：05/01/09 21:54:22

>>567
いまの時点でSeasarを使い込んでる人って、いろんなことをちゃんとわかってやってるだろうから、メンテナンスが大変なことになってるdiconってないんじゃなかろうか。

569 ：デフォルトの名無しさん：05/01/09 22:05:24

diconって普通分割するだろ？用途別にとか層別にとか。

570 ：デフォルトの名無しさん：05/01/09 23:55:02

>>567
「巨大なツリー状」と「メンテナンスが大変なことになってる」が、つながらないんだけども。

571 ：デフォルトの名無しさん：05/01/10 00:04:50

>>567
「巨大なツリー状」と「メンテナンスが大変なことになってる」が、つながらないんだけども。

572 ：デフォルトの名無しさん：05/01/10 05:56:29

論理削除ってわざわざS2Daoで面倒見る必要ってあるのかな。
もう一層上で対応するのが自然だと思うが。
やるんなら、０、１のフラグだけだと使えん。
通常はnull値で、削除すると日時で更新されるようにならないと。
がんばってください。

573 ：デフォルトの名無しさん：05/01/11 22:56:46

> プレゼンテーション層の革命のはじまりです。

そんな、革命的なものじゃないように見えるけど
モアベター程度に見えるし、ほとんどの人は普通のJSPや普通のJSFで充分な気がする。

574 ：デフォルトの名無しさん：05/01/14 02:15:17

「多くの人が実際の能力以上のことができると思い違いをしている。
　誰でも、ポップスター、高裁判事、有能なテレビ司会者に
　なれるかのように教師が教えているからだ」

　　　　　　　　　　　　　　　　　　　　　　　　　　　　チャールズ英皇太子

575 ：デフォルトの名無しさん：05/01/15 01:46:50

>>574
大したスキルもないくせにひが君と同等の立場で
語りたがるアンチへの嫌味ですか。
そうですか。

576 ：デフォルトの名無しさん：05/01/26 14:10:33

S2Dao のデバッグは sql を出力してくれるんだが、
必要な　sql_quote がかかっていなくてsqlとして実行できないんだな。

sql がおかしいのかと思ってしばらくはまっちゃったぞ。
デバッグしにくいから、誰か気づいた人quote かけとくれよ。
おねげーしますだ。

577 ：デフォルトの名無しさん：05/01/26 17:30:36

>>576

sql_quoteって何。
文字列ならシングルコーテーションで囲まれていた気はするけど。

578 ：デフォルトの名無しさん：05/01/26 20:20:51

(・∀・)ﾊｲｰｷｮ

579 ：576：05/01/27 13:41:56

>>577
sql_quote ってのはあれだ、文字列の中にシングルクォートがあったら、
クォートしてくれるってことだ。
hoge'hoge -> hoge''hoge
そうしないと、sqlエラーになっちゃうだろ？
insert fuga(hoge) values ('hoge'hoge'); => era-
insert fuga(hoge) values ('hoge''hoge'); => ok-

580 ：デフォルトの名無しさん：05/01/27 15:07:19

>>579
era-ってかわいいね

581 ：デフォルトの名無しさん：05/01/27 21:20:51

>>579
バインド変数(/*hoge*/みたいな)を使えば関係ないんじゃないの。

582 ：デフォルトの名無しさん：05/01/27 23:19:30

SeasarとMayaの関係がよく分からないんだけど。

583 ：デフォルトの名無しさん：05/01/28 08:02:30

っつか、Mayaってなに？
仕様をがんばって作って、しょぼい実装ができそうなことだけわかったけど。

584 ：デフォルトの名無しさん：05/01/28 21:34:06

>>583
http://pc5.2ch.net/test/read.cgi/cg/1059565585/

585 ：デフォルトの名無しさん：05/01/29 02:12:15

>>584
あ、それなら使ったことあるよ。

586 ：デフォルトの名無しさん：05/01/29 18:36:52

SPEEDってのもあるね

関係が分からない。

関係者の方々説明たのんます。

587 ：デフォルトの名無しさん：05/02/03 21:56:06

既出だったらごめんなんだけど

S2JSFってHTMLを売りにしてるけど
あれって拡張子が.htmlなだけで厳密にはHTMLじゃないよね。
サンプルで普通のHTMLまで変換されてたのが気になって．．．
あれは拡張子htmlでいいのか？

588 ：デフォルトの名無しさん：05/02/04 10:19:49

拡張子なんて飾（ｒｙ

589 ：デフォルトの名無しさん：05/02/05 19:59:16

>>587
普通のHTMLが変換されたらなんか問題あるの？

590 ：デフォルトの名無しさん：05/02/06 18:57:03

そういやkoichik氏のとこでCGLIBをASMに置き換えたテストやってるな。きっかけは前スレの以下の発言。

http://pc5.2ch.net/test/read.cgi/tech/1092044210/571

>多少、建設的なネタを。ひが君「cglib 遅せーから Javassist 使う」とか言ってないで
>直接 ASM 使えよ。まー、バイトコードライブラリ作者は使う側のスキルはアテにしてないと
>思うけどな。
>
>　性能： ASM ＞ Javassist（初心者向け）＞ cglib(初心者向けASMラッパー)
>　　　　　　　＞ BCEL ＞ SERP

で、実際にASM使ったら３割程度しか変わらんかったそうな。

591 ：デフォルトの名無しさん：05/02/07 23:06:04

３割向上って、結構凄いと思うが。

592 ：デフォルトの名無しさん：05/02/08 23:02:21

やっちゃいけないベンチマークの見本のようなコードだけど、この結果信用できるのか？
何もしないメソッドなんて動的コンパイル後実際に呼び出されているかどうかすら怪しい。

593 ：デフォルトの名無しさん：05/02/08 23:10:50

呼び出し速度を測る方法として、空メソッド呼び出し以外のいい方法ってある？

ちょっと思い当たらないんだけど。

594 ：デフォルトの名無しさん：05/02/09 11:58:58

>>593
べつに、純粋な呼出速度計らなくていいだろ。
比較できればいいんだから。

595 ：デフォルトの名無しさん：05/02/09 13:09:55

>>593
>>592は、アスペクト有る無しで15倍違うという結果は怪しいってだけで本題じゃないんだ。
（とは言っても、Sunのクライアントコンパイラはそこまでやらないはずなので
以下のオーバーヘッドを除けば、まず正しいと思う。）
で、本題のCGLIBとASMの比較。
コンパイル前(1)、コンパイル(2)、コンパイル後(3)、全部纏めて測定しているのはどうだろうか。
俺は3だけ欲しい。が、これは体感値だと言われればぐうの音も出ない。
そこまで望むなら自分でやれと言われれば、いやあ御尤も。

596 ：デフォルトの名無しさん：05/02/14 21:56:30

あげ

597 ：デフォルトの名無しさん：05/02/14 21:57:01

さげちゃった。。。

598 ：デフォルトの名無しさん：05/02/15 10:36:16

MayaってS2とは独立したフレームワークだと思ってるんだけど
なんでSeasarプロジェクトで開発してるんだろう…
将来的にS2JSFの代わりに使うことを考えてるのかな？

そういうところがSeasarとMayaの関係がよくわからないという
状況を生み出しているような気がしないでもない。

599 ：デフォルトの名無しさん：05/02/15 12:04:05

というか、Mayaがよくわからない。
なにか開発してて、開発が進んでるらしくて、HTML吐くあたりで動くらしいということしかわからない。
まるでジンジャー

600 ：デフォルトの名無しさん：05/02/15 20:14:26

>>599
>>584

601 ：デフォルトの名無しさん：05/02/15 23:03:41

２回目はおもしろくないぞ。

602 ：デフォルトの名無しさん：05/02/16 03:51:57

>>599
極度に乱暴に言うとTapestryのHTMLテンプレート部分+JSPのTaglib資産継承かな。

詳しくはまさたか氏のBlog(ttp://d.hatena.ne.jp/masataka_k/)の去年の11月末前後をチェックすべし。

603 ：デフォルトの名無しさん：05/02/19 10:41:06

結局、ちょっと英語かぶれになればChengeLogも英語だけになって、「日本人が開発してるから情報が日本語」っていうことも満たされなくなるわけか。

604 ：デフォルトの名無しさん：05/02/19 17:08:58

正直、大言壮語に付き合うのがダルい。

605 ：デフォルトの名無しさん：05/02/19 19:00:20

確かに今は大言壮語かもしれない。
でも革命の初期ってそんなもんだろ？
俺はひがたんを信じているぜ！！！

606 ：デフォルトの名無しさん：05/02/19 21:00:04

笑う人は笑わせておけばいい

607 ：デフォルトの名無しさん：05/02/19 21:14:56

お笑いが流行ってますからね。

608 ：デフォルトの名無しさん：05/02/20 02:20:42

S2Daoはミもフタもない。

くーすはさらにミもフタもない。

ひが氏の英語はさらにミもフタもない。

609 ：デフォルトの名無しさん：05/02/20 02:49:59

えーっ、S2Daoはフタはないけどミはあると思うけどなぁ。
そういえば最近くーすってブログに書いてないね。

610 ：デフォルトの名無しさん：05/02/20 17:34:00

大言壮語は同感だけど英語で情報発信しようという姿勢はいいんじゃない？
なにもないよりは多少おかしくても英語情報があったほうがましだと思う。
日本のユーザも大切にして欲しいとは思うけどね。

611 ：デフォルトの名無しさん：05/02/20 18:51:59

608の人生はさらにもフタもない。

612 ：デフォルトの名無しさん：05/02/20 18:58:57

>611
ミはなくないんだ。

613 ：デフォルトの名無しさん：05/02/20 20:09:43

>>610
ここでの問題は、単に英語の練習というだけで情報が英語だけになったってことだ。

614 ：デフォルトの名無しさん：05/02/20 20:52:06

>>613
MLには日本語でアナウンスすることになったから安心汁。

615 ：デフォルトの名無しさん：05/02/20 21:07:09

>>613
練習だったんだ…。そりゃ失礼。

616 ：デフォルトの名無しさん：05/02/20 21:37:27

>>614
MLに情報流しログも見れるからサイトには情報いらない、という考え方？あいかわらず。

617 ：デフォルトの名無しさん：05/02/20 22:06:48

>>616
サイトって？

618 ：デフォルトの名無しさん：05/02/20 22:25:50

公式サイト。
で、そこから公式にリンクが張られてるseasar wiki。
最近のwhat's newには日本語での情報がない。

619 ：デフォルトの名無しさん：05/02/20 22:43:52

>>618
614に書いてないだけ。
seasar wikiも日本語でアナウンスするらしいよ。

620 ：デフォルトの名無しさん：05/02/21 00:05:23

あぁ、じゃ、まず英語で情報がでて、日本語はあとからゆっくりってことか。

621 ：デフォルトの名無しさん：05/02/21 00:38:45

>>620
「あとからゆっくり」のソースは？

622 ：デフォルトの名無しさん：05/02/21 00:40:50

2/9以降、Seasar本体とS2Daoの情報は、英語でしかwikiに書いてない。

623 ：デフォルトの名無しさん：05/02/21 01:20:34

>>622
過去のはあとからゆっくりじゃなくてもう日本語にならないんじゃね？
明日以降、過去のが日本語化されたら622のおかげ。

624 ：デフォルトの名無しさん：05/02/26 23:49:10

なんかMayaがすごいことになってきているね。

625 ：デフォルトの名無しさん：05/02/27 00:10:45

リリースがめちゃくちゃ早いことだけはわかるんだが、Mayaがなんなのか
よくわからない。

TapestryともS2JSFとも違う、なんかのプレゼンテーション層フレームワークらしい
ことは分かるんだが。

626 ：デフォルトの名無しさん：05/02/27 01:09:04

結局Seasar2が必要なんだよね？
なんか、面白い機能を試すのにSeasar2が必要だし、Seasar2単体で試しても面白くないしで、壁が高い気がする。

627 ：デフォルトの名無しさん：05/02/27 01:21:32

JSP2.0でいいや。

628 ：デフォルトの名無しさん：05/02/27 01:59:50

>>625
Jasperに相当するテンプレートエンジンだとか。
JasperはJSPを処理するけどMayaはHTMLを処理するのが違いだとか。
TapestryやS2JSFとの違いは、Mayaはテンプレートエンジンだけで
フレームワークではないということだと思ってる。
だから色々なフレームワークと組み合わせて使うことが出来るのだとか。

>>626
MayaはS2とは独立に使えることになってるはず。
WebWorkと組み合わせて動いたってレポートがあった。
どこかにSpringとも組み合わせられるとも書いてあった。

>>627
Webデザイナと協業しないとかWebデザイナがJSP大丈夫な場合はそれでいいかもね。

629 ：627：05/02/27 02:19:18

>>628
あぁ、そうなのか。
だからJSPで全然不満ないんだ。
Webデザイナとは無縁だし。

630 ：デフォルトの名無しさん：05/02/27 13:06:17

>>626
そりゃSeasarの壁じゃなくておまいの「好奇心の低さ」と言う壁だべさ

631 ：デフォルトの名無しさん：05/02/27 14:00:55

>>630
別にそれでもいいけど。
Seasar2自体には興味はないし。
他に同じようなことができるものがあるなら、そっち試すだけで。

632 ：デフォルトの名無しさん：05/02/27 16:37:09

うんそうだね。だから631はこのスレに来なくてもいいよ。

633 ：デフォルトの名無しさん：05/02/27 16:45:27

壁が高い
　　↓
おまえがクズ
　　↓
めんどう
　　↓
来なくていいよ

っていう流れ、好きだなぁ。

634 ：デフォルトの名無しさん：05/02/27 21:20:21

たしかに３割向上だったら、大手をふって効率アップっていえるかも。

635 ：デフォルトの名無しさん：05/02/27 21:35:44

ところで、そこの効率アップって、アプリ全体の影響って大きいの？

636 ：デフォルトの名無しさん：05/02/27 22:31:35

まあ2.2はJavassistで決定みたいだけどな

637 ：デフォルトの名無しさん：05/02/27 22:49:09

>>636
もう公開されてるよ
早くなった実感がない

638 ：デフォルトの名無しさん：05/02/27 23:01:27

結論：JSP2.0 + EJB3.0 これ。

639 ：デフォルトの名無しさん：05/02/28 00:02:19

思いがけぬ結論にワラタ

640 ：デフォルトの名無しさん：05/02/28 13:24:52

> DIは理解するものではなく、体で覚えるものです。

宗教みたいになってきたな。

641 ：デフォルトの名無しさん：05/02/28 17:47:32

セガサターン白！

642 ：デフォルトの名無しさん：05/03/01 02:43:49

S2JSFはSeasar2なしでいけるの？

643 ：デフォルトの名無しさん：05/03/01 11:37:36

>>642
無理。S2が必要。

644 ：デフォルトの名無しさん：05/03/01 13:06:48

> RC1からS2JSF自体は、JSP1.2に対応したWebコンテナ(例えばTomcat4.1)なら動作するようになります。

じゃあ、これ、どういうこと？
この文章見ると、S2JSFだけ使うなら、Tomcat4.1なら(他のライブラリなしに)動作するとも読めるんだけど。
というか、そう読んだんだけど。

645 ：デフォルトの名無しさん：05/03/01 14:13:39

>>644
EA7まではJSP2.0に対応したWebコンテナ(例えばTomcat5.0)が必要だったけど
その制限が緩くなったってことじゃないか？
「S2JSF自体は」と書いているのは、組み合わせるJSF実装なんかに制限される
場合もあるからだろうね。
いくらなんでも「他のライブラリなしに」は補完しすぎw

646 ：デフォルトの名無しさん：05/03/01 14:39:14

逆に、「S2JSF+Tomcat4.1」で動くという情報しかないから、何を補完して考えればいいのかわかんなかった。
Tomcat4.1なら動くっていうのも、じゃあ動かないのは？って考えてJSP1.1で動かないのはどうでもいいし、JSP2.0では動かないってことか？とか。
いままでJSP2.0で動いててJSP1.2で動くようになったなら「JSP1.2でも」だろ、と。

というか、「S2JSF+Tomcat4.1+なんかcommons系」くらいでSeasar2なしで動くようになったのかと期待してみた。

647 ：デフォルトの名無しさん：05/03/01 15:11:07

>いままでJSP2.0で動いててJSP1.2で動くようになったなら「JSP1.2でも」だろ、と。
それくらい補完しなよ。

>というか、「S2JSF+Tomcat4.1+なんかcommons系」くらいでSeasar2なしで動くようになったのかと期待してみた。
それならMayaに期待しなよ。
つーか、そんなにS2外したいのか？

648 ：デフォルトの名無しさん：05/03/01 19:01:22

> それくらい補完しなよ。

それで補完したのが「他のライブラリなしに」だったのさ。

>>647
> つーか、そんなにS2外したいのか？

選択肢としてね。

649 ：デフォルトの名無しさん：05/03/01 19:41:56

他のプレゼンテーションフレームワークを使ったらいいんじゃないか

650 ：デフォルトの名無しさん：05/03/01 20:15:40

>>649
いや、選択肢のひとつとしてね。
S2JSFだったりMayaだったりNirvanaだったりJSPだったり、それをS2と組み合わせたりSpringと組み合わせたり、コンテナ使わなかったり。
いろんな選択肢を考えれるようにしときたいし。
S2必須なら、S2JSFが他に比べて卓越してない限り、S2を使う前提でしか選択肢にならないから。

651 ：デフォルトの名無しさん：05/03/02 01:15:27

今まで細かいところで「これだとSpringに依存しちゃいますから！残念！！」とか言ってきたのに、
普通にS2が無いと動かないJSF実装を出すってのはどうなんだ。俺はダブルスタンダードに思えて
釈然としないんだが。

652 ：デフォルトの名無しさん：05/03/02 01:32:10

S2JSFはアプリじゃないから。
S2JSFのアプリはPOJOだからS2に依存しないと思うよ。

653 ：デフォルトの名無しさん：05/03/02 01:46:35

>>651
Maya使えば？

654 ：デフォルトの名無しさん：05/03/02 02:01:47

>>652
S2JSFに依存するのはOKなのか。

655 ：デフォルトの名無しさん：05/03/02 02:15:41

アプリはPOJOだからS2JSFにも依存しないと思うけど？
HTMLに独自属性を埋め込むページテンプレートはS2JSFに依存するけど。

656 ：デフォルトの名無しさん：05/03/02 07:31:08

なんで事あるごとにSpringにつっかかるんだろうな。まるでMicrosoftのアンチLinuxキャンペーンみたいだ
有名にさえなれば、類似プロジェクトとの比較なんてJava系雑誌がくどい位やってくれるだろうに

657 ：デフォルトの名無しさん：05/03/02 09:24:08

MSのキャンペーンに例えられるとはまるでS2のほうがSpringよりもメジャーみたいだｗ

658 ：デフォルトの名無しさん：05/03/02 14:00:10

>>655
POJOだから依存しないっていうのがねぇ。
POJOだから依存しないっていうのは、ソースコードレベルの話だけだ。
結局それなしでは動かせない。

659 ：デフォルトの名無しさん：05/03/02 17:14:12

>>658
それを言い出すときりが無くない？
コンテナが無ければ動かせない、そもそもJavaのランタイムが無いと動かせないサーバが無etc.etc...
どのレベルまで依存を許容できるか、ってだけの問題にしかならない。
具体的にどうして欲しいのか言ってみなさいよ。

Struts→JSFのときみたいに実装と仕様を分けろってこと？
（S2の仕様だけ分離して、いろんな人が実装する…あ、それは面白いかもw）
または、Springでも動く(ってぐらい依存度の低い)S2JSFを期待してるのかしら。

それとも単にいちゃもん付けたいだけなのかな。

660 ：デフォルトの名無しさん：05/03/02 17:23:06

> それとも単にいちゃもん付けたいだけなのかな。
何をいまさらｗ

661 ：デフォルトの名無しさん：05/03/02 21:16:36

>>659
> どのレベルまで依存を許容できるか、ってだけの問題にしかならない。

いや、その程度の問題なんだが。
S2が無いと動かないってのはどうなんだ？っていう答えがPOJOだからS2に依存しないっていうのが、的外れだってこと。

662 ：デフォルトの名無しさん：05/03/02 22:05:53

だらかね、
最終的に動作する環境でいろんなものに依存するのは当たり前なの。
おまいはサーバも無いところにソースだけ納品してるのか？

いちいち「依存してる」って言葉について説明するのも馬鹿らしいんだけど、
ここで言ってる「依存しない」は運用時ではなくて開発時のことさね。
特定のライブラリに依存しないPOJOで作れると何がよいって、テストが楽だし安全でしょ？

あともう一つ勘違いしてるっぽいポイントは、
S2を利用するプログラム(例えばおまいさんが作る業務システム)が、
S2/S2JSFに対して依存度が低いって言ってるんであって、(←しつこいけど開発時のことね。)
S2JSFがS2に依存しない何て話は出てないし話題にする必要も無い。
S2プロダクトシリーズであるS2JSFが、S2と密接に関連するのは当たり前だろう。

おまいはどんな世界を夢見てるんだい？

663 ：デフォルトの名無しさん：05/03/02 22:40:05

>>662
>>651の答えとして>>652の「POJOだから」が適当なのかという話をしてるわけだが。
なに逆切れしてんの？

664 ：デフォルトの名無しさん：05/03/02 22:42:18

> S2プロダクトシリーズであるS2JSFが、S2と密接に関連するのは当たり前だろう。

だから>>651の意見が出てくるんだろ。
それで、POJOだから依存しないって、なんかおかしいんじゃね？

665 ：デフォルトの名無しさん：05/03/02 22:50:23

>>664
> それで、POJOだから依存しないって、なんかおかしいんじゃね？

どうおかしいんだい？

666 ：デフォルトの名無しさん：05/03/02 22:57:03

HTMLをテンプレートとして使うJSF実装でS2非依存のモノもあるんだから（MayaとかNiravanaとか）、依存するのが嫌ならそちら使えばいい話かと。

667 ：デフォルトの名無しさん：05/03/02 23:05:31

技術的なことはわからないけどひがタンに難癖つけたい奴がブログの粗探ししてるだけだ。
技術的なことを真剣に考えて言ってるわけじゃない。そもそもS2に依存するのが嫌なら最初からS2ファミリーには興味持たない。

668 ：デフォルトの名無しさん：05/03/02 23:23:27

>>664
「これだとSpringに依存しちゃいますから！残念！！」みたいな発言は
たとえばSpringのDataSourceUtilsとか、ApplicationListenerなどを利用させるような開発手法についての批判だった気がする。
だからPOJOだから大丈夫という回答になるんだと思うけど
S2JSFがS2が無いと動かないという話とは別物のような気がするけどな。
例えるなら、「SpringのMVCフレームワークがSpring無しで動かないのはおかしい」みたいな話になるのでは？

669 ：デフォルトの名無しさん：05/03/03 00:05:02

>>664
S2/S2JSFのアプリはPOJO
　　↓
SpringのAPIを使ってない
　　↓
Springでは動かない
　　↓
結局S2/S2JSFに依存してる
　　↓
POJOだから依存しないって、なんかおかしいんじゃね？

ということか？
それで咎められるべきはS2やS2JSFじゃないと思うぞ。

670 ：デフォルトの名無しさん：05/03/03 00:44:44

>>669
別にとがめるとかではなくて、そこでPOJOだからっていうのは理由になってないんじゃない？って言いたいだけ。
「依存してるけどPOJOだからロジック部分は再利用可能」
だったらわかるけど。

>>667
> そもそもS2に依存するのが嫌なら最初からS2ファミリーには興味持たない。

S2JSFは面白そうだと思うんだけど。
S2に依存するのが嫌なら興味持たなくていい程度の、他と大差ないしくみなの？

671 ：デフォルトの名無しさん：05/03/03 01:00:14

>>670
>>668読めば、「POJOだからっていうのは理由になって」るのが分かるぞ。

672 ：デフォルトの名無しさん：05/03/03 01:05:26

＞S2に依存するのが嫌なら興味持たなくていい程度の、他と大差ないしくみなの？
他って具体的に何よ。半端な釣りすんなよ。

673 ：デフォルトの名無しさん：05/03/03 01:11:28

>>671
その、別物の方の話を>>651はしてるんじゃないの？
まぁ、>>651に関しては、S2Daoとかもすでにあったわけでいまさら言うことじゃないと思うけど。

674 ：デフォルトの名無しさん：05/03/03 01:12:30

>>672
Mayaとかちょっと上で話題に出てるんだけど・・・

675 ：デフォルトの名無しさん：05/03/03 01:13:46

別物の方の話をしてるってことは、つまり言いがかりをつけてるってことじゃないかｗ

676 ：デフォルトの名無しさん：05/03/03 01:21:14

なんか、変なやつが混じってるな。
つまりもなにも、いまさら言うことじゃないと書いてるわけで。
「そこでPOJOだから」はないんじゃないの？って言いたかっただけだ。
>>668の前後入れ替えればいいだけで、意図はわかったからもういいけど。

677 ：デフォルトの名無しさん：05/03/03 09:20:40

最初に自分が「S2JSFがS2ないと駄目なのか」とか言い出したくせに
途中から「POJOだからはないんじゃない」と言いたかっただけだと
すりかえておきながら変な奴が混ざってるとかいってる藻舞も変なﾔｼｗ

678 ：デフォルトの名無しさん：05/03/03 15:10:07

>>677
そりゃ、途中で「POJOだから依存しない」って言われたからさ。

679 ：デフォルトの名無しさん：05/03/03 15:13:32

>>677
変なやつというのは、「釣り」だとか「言いがかり」だとか、被害妄想的な煽り文句入れてるやつね。

680 ：デフォルトの名無しさん：05/03/04 00:00:15

で、結局POJOってのはハッタリだった訳だ。

681 ：デフォルトの名無しさん：05/03/04 01:12:09

それはそれで大切かと。
POJOであれば、ソースコード的には依存しないわけで。
そこには価値があると思う。

682 ：デフォルトの名無しさん：05/03/04 02:04:25

DI導入するだけで、こうもコードがすっきりするものかとびっくりするね。
俺はSpring使ってるけど

683 ：デフォルトの名無しさん：05/03/05 12:09:28

コンテナから生成するのはBCEのCだけですか？他はnewで生成する？
すべてコンテナから取得するわけではないとどっかに
書いてあった気がしたんですが。うるおぼえですみません。

684 ：デフォルトの名無しさん：05/03/05 19:59:24

Bはアプリケーションコンテナ(Tomcatとか)が生成、EはCに対してDIで生成…で良かったと思うけど。

685 ：デフォルトの名無しさん：05/03/06 20:53:52

ひがたん....
プレゼンテーション層だけ、と限定しても未だにWebObjectsが最強だと思うんですけど。

仕事ではStrutsでいらいらするけど。

686 ：デフォルトの名無しさん：05/03/06 22:25:06

WebLogic最強説

687 ：デフォルトの名無しさん：05/03/06 22:42:31

Webber最速説

688 ：デフォルトの名無しさん：05/03/06 23:23:42

しかし、
S2JSFからS2をはずそうという発送が出てくること自体凄いよなあ。
そしたらS2JSFじゃないじゃんｗ

つーか、そんなことをココで聞く前に自分でソースでも見てれば、そんなくだらない疑問はすぐに解決してこのスレが荒れることは無かったのに。

つーか、オープンソースなんだから。。。
ソース見ればすぐに分かるようなことを、クレクレしてくる奴はどうかと思うけどね。

689 ：デフォルトの名無しさん：05/03/06 23:25:31

>>688
すぐわかったあなたはえらい
自分で作ってみるまで良さがぜんぜんわからなかった…

690 ：デフォルトの名無しさん：05/03/07 02:31:27

Seasarはあまり触ってないけど、今月のJavaWorldに出てたS2JSFのサンプルを見てたしかに使い易そうだと思った。
来月のJavaWorldで特集組まれるみたいだし、最近JavaWorldはS2プッシュしてるね

691 ：デフォルトの名無しさん：05/03/07 16:53:40

S2JSFのエキザンポー、見たんだけど、
S2をいじるのは初めてで、S2JSFうんぬん以前に
あまりにあっけないんで、逆にすんごい不安になってしまった。

今の出向先の自社謹製フレームワークがもうしんどくてしんどくて。
早いところ自社に帰ってS2で仕事したい。

692 ：デフォルトの名無しさん：05/03/07 17:40:53

はぶにっきの荒らしコメントが
全く誰にも気づかれずに未だにポツンとあるのが
ちょっと笑った。元気が出た。

693 ：683：05/03/07 23:32:11

>>684
BCEのEはgetter,setterのみが幾つかあるようなものだと
思っているのだけれども、Eをコンテナから生成しても
意味なくないですか？

694 ：デフォルトの名無しさん：05/03/08 00:00:46

>>693
S2Daoって知ってるか？

695 ：デフォルトの名無しさん：05/03/08 19:26:17

テーブルA B Cの三つがあるとして、
AとBがN:1、BとCがN:1の関係になっています。
Select ... FROM A
LEFT OUTER JOIN B ON A.bid=B.bid
LEFT OUTER JOIN C ON B.cid=C.cid
としたい場合、Aのbeanクラスで
private B bbean;
public static final int bbean_RELNO=0;
public static final String bbean_RELKEYS="bid";
private C cbean;
public static final int cbean_RELNO=1;
public static final String cbean_RELKEYS="bbean.cid:cid";
とすると、
Select ... FROM A
LEFT OUTER JOIN B bbean ON A.bid=bbean.bid
LEFT OUTER JOIN C cbean ON A.bbean.cid=cbean.cid
ってなSQLが出力されます。
hsqldbなら問題無かったのですが、PostgreSQLだとAなんてスキーマは無ぇよ！って怒られます。

こういうときって本来はRELKEYSにどういう風に書けばいいんでしょうか？

696 ：デフォルトの名無しさん：05/03/08 19:34:23

>>695
メーリングリストでききなよ

697 ：デフォルトの名無しさん：05/03/08 19:48:10

だってMLは賢い人たちばっかりで、
漏れみたいなお馬鹿Qは投げにくいんだもん．．．．．

698 ：デフォルトの名無しさん：05/03/08 22:27:12

全然お馬鹿Qじゃないと思うが。

699 ：太田＠下宿：05/03/09 07:33:39

695さん>

http://www.wikiroom.com/oreju/?plugin=attach&openfile=s2daoNM1.zip&refer=%A5%B7%A1%BC%A5%B5%A1%BC%A5%B5%A5%F3%A5%D7%A5%EB%A5%D7%A5%ED%A5%B8%A5%A7%A5%AF%A5%C8

のサンプルと同じようにやるとうまくいくと思いますよ。クラスAでは，

>public static final String cbean_RELKEYS="bbean.cid:cid";

は定義しないで，

>public static final int cbean_RELNO=1;

のみを定義するとうまくいくと思います。

700 ：デフォルトの名無しさん：05/03/09 19:24:24

お馬鹿Q!!爆笑

701 ：695：05/03/10 11:00:19

やっぱりお馬鹿Qだ…すみません、肝心なこと書き忘れてました。

>>699
ありがとうございます。
頂いたサンプルでは、SQLファイルを用意しているようですが、
SQLの自動出力は難しい、ということでしょうか。

702 ：デフォルトの名無しさん：05/03/11 02:38:02

最終的に吐かせたいSQLが決まってるならSQLファイルを準備するのがいいと思う。

多種RDBMSに同一ソースで対応したいっていうなら話は別だけど。

703 ：695：05/03/11 10:02:41

>>702
そうなんですか！
僕は寧ろ、できるなら自動でやる方が好ましいのかと思って、
がんばってSQLファイル削減してるところでした＿|￣|○

今後は躊躇無くSQLファイルを使っていきたいと思います。
ありがとうございました。

704 ：デフォルトの名無しさん：05/03/12 01:11:56

S2Daoの利点って、効率良く書かれたSQLをそのままDAOに使用出来るところだよ。
これができるのって、あとはiBatisくらいしかないんじゃないか。

逆にSQLを徹底的に隠す方向のO/Rマッピングなら、Cayenneくらい徹底的に隠して
ほしい。

HibernateのHQLってそういう意味でなんか中途半端なイメージがあるんだよね。
クエリでSQLもどきをかくなら、もうSQL書かせてくれたらいいから、とか思ってします。

705 ：695：05/03/12 11:16:42

>>704
他のO/Rマッピングツールを使ったことが無かったので分からなかったのですが、
S2Daoの秀でている点というものが激しく納得できました。ありがとうございます。

といってるところにMLにタイムリーな話題が^^;

706 ：デフォルトの名無しさん：05/03/19 14:34:01

くーすのサイトってどこにあんの？
seasar.orgにはみつからん。

707 ：デフォルトの名無しさん：05/03/19 15:01:20

Spring >>>>>>>>>>>>>>> seasar2
国粋主義者以外はSpringかEJB3.0だろ。

708 ：デフォルトの名無しさん：05/03/19 15:43:29

沖縄も外国じゃねぇの？

709 ：デフォルトの名無しさん：05/03/19 22:03:25

Java PressでSpringの大特集してるね。
Kijimunaも良いけど、SpringIDEはもっとすごいね。

710 ：デフォルトの名無しさん：05/03/20 00:00:57

つか、Springに対して、Seasarの優ってる点って殆ど無いし。

711 ：デフォルトの名無しさん：05/03/20 01:44:14

えー、そうなの？
オートインジェクションが便利だよ。

712 ：デフォルトの名無しさん：05/03/20 02:06:13

直感的ではないファイル分割の挙動も素敵だ。

713 ：デフォルトの名無しさん：05/03/20 14:14:45

リリースが速いのはいいのだがそろそろs2-frameworkをcontainer部分とutils部分に分けてそれぞれ別のリリースサイクルにしてほしいっす。

ttp://lists.sourceforge.jp/pipermail/seasar-user/2005-March/001578.html
みたいな返答を見るとバージョンアップに躊躇してしまう。

714 ：デフォルトの名無しさん：05/03/20 14:46:27

くーす本いつ出るのかなあ
話なくなったのかなあ

715 ：デフォルトの名無しさん：05/03/21 00:05:37

S2Strutsを試してみようと思って、StrutsUploadのファイルアップロード処理を
作ってみようと思ったんですが、org.apache.struts.upload.FormFileをActionFormに
セットするのに失敗してしまいます。

java.lang.IllegalArgumentException:
Cannot invoke org.seasar.struts.examples.form.UploadForm.setTheFile - argument type mismatch

StrutsConfig.xmlはこんな感じです。
<form-beans>
<form-bean
name="uploadForm"
type="org.seasar.struts.examples.form.UploadForm"/>
</form-beans>
<action-mappings>
<action
path="/upload"
type="mylib.seasar.upload.UploadAction"
name="uploadForm"
scope="request"
validate="true"
input="/pages/uploadInput.jsp">
<forward name="success" path="/pages/uploadResult.jsp" />
</action>
</action-mappings>

どこが悪いのかわかる方お願いします。

716 ：デフォルトの名無しさん：05/03/21 01:24:29

UploadFormのsetTheFile()というメソッドを確認したほうがいいんでない？

717 ：715：05/03/21 02:41:19

UploadFormはこんな風になってます。
public void setTheFile(FormFile theFile) {
this.theFile = theFile;
}

FormFileは「org.apache.struts.upload.FormFile」で、UploadFormクラスは
StrutsUploadのサンプルからもらってきたものなんです。

StrutsUploadの方だと、アップロードしたファイルやその情報をFormFileに
格納して、setTheFileからセットしてくれるんですが、POJO型のActionじゃ
それは無理なんでしょうか。

718 ：デフォルトの名無しさん：2005/03/21(月) 13:22:43

typeがあってないわけだから
Object型でうけてみて
何の型できているか確認してみたらどうでしょう

719 ：デフォルトの名無しさん：2005/03/21(月) 13:23:27

およそ忠告ほど人が気前よく与える物はない。

　　　　　　　　　　　　　　　　　　ラ・ロシュフコー

720 ：デフォルトの名無しさん：2005/03/22(火) 00:15:27

>>718
なるほど！
ありがとうございました。

721 ：デフォルトの名無しさん：2005/03/25(金) 02:15:18

Java　Press読んだんだがspringIDEたしかに(・∀・)ｲｲ!!
Kijimunanaにはがんばってもらいたい

Java Worldのseasar特集はこれから読みまつ(｀･ω･´)

722 ：デフォルトの名無しさん：2005/03/25(金) 13:25:27

>>721
SpringIDEはプロパティ名やクラス名の補完をしてくれないから
実際はそれほど役に立たない｡
バリデーションはしてくれるけど｡
仕事でSpringを使っているひとで、SpringIDEを使っているって
あまりきいたことない。

あの意味のないグラフィック表示が使ったことのないやつには
すごいように見えるのかもしれんが｡

723 ：デフォルトの名無しさん：2005/03/26(土) 03:05:11

>>722
そうなのか…(´･ω･｀)

とりあえずS2JSF正式リリースおめ
これで次のプロジェクトに使えるよー

724 ：デフォルトの名無しさん：2005/03/26(土) 03:16:04

SeasarかSpringか毎回悩むんだが、立ち位置が微妙なんだよな。
Springのほうが上を説得するのはやりやすいのが実情。
ほっとくと「なんか有名なんでEJBでよろしく」とかなっちゃうんでねえ。

もうちょっとメジャーになってくれるとやりやすいんだが、それはこれから
の活動次第か。なんとかJavaWorldを見せることはできるようになったわけで。

725 ：デフォルトの名無しさん：2005/03/26(土) 12:25:07

結論としてはJSF+EJB3.0と

726 ：デフォルトの名無しさん：2005/03/26(土) 20:31:27

S2JSF+EJB3っていうのはどう？
S2JSF必須ライブラリのためにseasar2にクラスパスは通しておくだけ。

727 ：デフォルトの名無しさん：2005/03/27(日) 11:56:51

「ITのイチロー」って名前で、別の人が雑誌に載ってたね

728 ：デフォルトの名無しさん：int 2ch ＝05/04/01(金) 20:57:42

http://d.hatena.ne.jp/higayasuo/20050330#1112179222

> 今回のセミナーでは、魅力的なS2JSFの機能を紹介するだけではなく、
> マニュアルでは触れられていないような、でも知っているとS2JSFのことを
> より深く理解できるような、一歩踏み込んだトピックもお話します。

とあるんですけどS2JSFのマニュアルってどこかにあるんでしょうか？
サンプルの解説しか見たことないんですけど。

729 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 03:21:57

ﾏﾙｪｰ、ﾌﾞﾛｸﾞとｿｰｽがﾏﾆｭｱﾙですよぉー（ﾟεﾟ）

730 ：デフォルトの名無しさん：2005/04/03(日) 17:38:34

こんな例外に遭遇した人いませんか?コードを見たけどなんでぬるぽになるのかわからない。
S2.0.22です。

java.lang.NullPointerException
at org.seasar.extension.dbcp.impl.ConnectionPoolImpl$FreeItem.expired(ConnectionPoolImpl.java:244)
at org.seasar.extension.timer.TimeoutTask.expired(TimeoutTask.java:59)
at org.seasar.extension.timer.TimeoutManager.run(TimeoutManager.java:54)
at java.lang.Thread.run(Thread.java:536)

731 ：デフォルトの名無しさん：2005/04/03(日) 18:44:58

がっ

732 ：デフォルトの名無しさん：2005/04/06(水) 12:05:52

ttp://www.seasar.org/ が４０４なんですけど。

733 ：ひが：2005/04/06(水) 23:26:44

もう、疲れました。
探さないでください・・・。

734 ：デフォルトの名無しさん：2005/04/07(木) 02:05:01

工エエェェ（´д｀）ェェエエ工工

735 ：デフォルトの名無しさん：2005/04/07(木) 13:12:37

無事保護されて、連れ戻された模様です。

がんばれひがたん

736 ：デフォルトの名無しさん：2005/04/16(土) 23:16:57

HTML仕様にあってないものを拡張子htmlにして
ビューとロジックを完全に分割できます、すごいでしょ
なんて言ってるから日本人は仕様にかかわれないんだよ

737 ：デフォルトの名無しさん：2005/04/16(土) 23:31:24

以上、こんなこと言ってるから仕事を任せてもらえない>>736がお伝えしました。

738 ：デフォルトの名無しさん：2005/04/17(日) 14:18:25

結論：RELAX同様、信者以外には無視される運命。

739 ：デフォルトの名無しさん：2005/04/17(日) 17:11:14

設定ファイルの依存関係がわけわからんから、Springの方がとっつきやすい。

740 ：デフォルトの名無しさん：2005/04/17(日) 17:27:04

依存関係って、ただのincludeじゃん。

741 ：デフォルトの名無しさん：2005/04/17(日) 17:41:50

オートインジェクションに関わってくるわけだろ。ただのincludeじゃない。

742 ：デフォルトの名無しさん：2005/04/17(日) 18:04:45

いやだからさ、includeしてるやつを見れば分かるだろ。というかincludeといのは
そういうもんだろう。

Springの定義の継承とくらべてそれほど特殊なコトやってるかな？

743 ：デフォルトの名無しさん：2005/04/17(日) 18:56:34

>>742
インクルードされる側にインクルードする側での定義が影響するというのは、特殊なことだと思う。

744 ：デフォルトの名無しさん：2005/04/17(日) 19:07:35

インクルードされる側(子)からはインクルードした側(親)の定義は見えないし影響もないよ。

745 ：デフォルトの名無しさん：2005/04/17(日) 19:16:20

オートインジェクションは？

746 ：デフォルトの名無しさん：2005/04/17(日) 19:16:23

むしろSpringでこそ子のBeanFactoryから親のBeanFactoryの定義が見えるわけだが。

747 ：デフォルトの名無しさん：2005/04/17(日) 19:17:19

BeanFactoryの親子関係と、定義ファイルの分割は別問題でしょ。

748 ：デフォルトの名無しさん：2005/04/17(日) 19:17:22

>>745
親で定義されているコンポーネントは子では見えないからオートインジェクションされない。

749 ：デフォルトの名無しさん：2005/04/17(日) 19:46:25

>>747
設定ファイルの依存関係という話だから全く無関係でもないと思うが。
子のBeanFactoryに読み込まれる設定ファイルからは親のBeanFactoryが
読み込んだ設定ファイルが見える、つまり依存する(かもしれない)わけだろ？
設定ファイルの依存関係がわけわからくなるのはむしろSpringじゃね？

750 ：デフォルトの名無しさん：2005/04/17(日) 20:02:31

Springの場合は、依存関係とか考えずにただ分割するだけだから。

751 ：デフォルトの名無しさん：2005/04/17(日) 20:06:07

>>451
それはBeanFactoryに親子関係を持たせるときの話で、定義ファイルの分割とは別の話。
ごっちゃにして考えるもんじゃない。

752 ：デフォルトの名無しさん：2005/04/17(日) 20:23:01

>>750
それって全部依存しあうってことだよね。いいことなのかな？

753 ：デフォルトの名無しさん：2005/04/17(日) 20:34:35

>>751
話の発端は設定ファイルの依存関係だろ？
一つのコンテナに読み込まれる定義ファイルの分割だけに
話を限る必要はないと思うが。

754 ：デフォルトの名無しさん：2005/04/17(日) 20:39:18

>>752
名前空間という点ではちょっと問題。

755 ：デフォルトの名無しさん：2005/04/17(日) 23:25:05

S2Container _container = S2ContainerFactory.create("/tmp/test.dicon");
ThreadDataInterface _thread = (ThreadDataInterface)_container.getComponent("threadData");

こんな感じで実行すると、

org.seasar.framework.util.ResourceNotFoundRuntimeException: [ESSR0055]リソース(/Users/tetsuyak/Desktop/EORelationshipDISample/test.dicon)が見つかりません
at org.seasar.framework.util.ResourceUtil.getResource(ResourceUtil.java:49)
at org.seasar.framework.util.ResourceUtil.getResourceAsStream(ResourceUtil.java:68)
at org.seasar.framework.util.ResourceUtil 以下略...

とでる。 test.diconは、

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE components PUBLIC "-//SEASAR//DTD S2Container//EN"
"http://www.seasar.org/dtd/components.dtd">
<components>
<component name="threadData" class="jp.test.SampleThreadData" instance="prototype">
</component>
</components>

と定義。パスは天地店名に誓って間違ってない。なんだろう……

756 ：デフォルトの名無しさん：2005/04/17(日) 23:37:28

>>755
/tmpをクラスパスに入れてcreate("test.dicon")とか。

757 ：デフォルトの名無しさん：2005/04/17(日) 23:38:30

>>755
create(String path)に渡すpathは、クラスパスをルートとしたパス名だぞ。
俺の予想では、/Users/tetsuyak/Desktop/EORelationshipDISample/ ってのがクラスパスの
指してるところなんだろう。

なんで/tmpが無視されてんのかはよくわからんけど、「tmp/test.dicon」（頭の/がない）だったら、
/Users/tetsuyak/Desktop/EORelationshipDISample/tmp/test.dicon を探しにいくと思う。

名前からしてWebObjectsか....

758 ：755：2005/04/18(月) 00:07:53

どうもありがとうdeth。
>>(/Users/tetsuyak/Desktop/EORelationshipDISample/test.dicon)が見つかりません
この部分は正しくは、(/tmp/test.dicon) が見つかりません
です。別のウィンドウからコピペしちゃったものでした（恥

>>757
>>create(String path)に渡すpathは、クラスパスをルートとしたパス名だぞ。

ありがとうございます。もうちっと試してみます。

>>名前からしてWebObjectsか....

思いっきりバレバレです。ごめんなさい。

759 ：755：2005/04/18(月) 00:32:51

ウマくいきました。>>756、757さんありがとうございます。
（ﾄﾞｷｭﾒﾝﾄをきっちり読んでから質問します）

760 ：デフォルトの名無しさん：2005/04/18(月) 21:44:59

Relax自体は価値があるけど、Relaxerであのソースコード自動生成とか、
図らずも Java ってダメさ具合を明確なものにしてるんだよね。
型を気にして無意味なクラスを作る気持ち悪さ、生産性の低下、これを実感できる。
Seaserも全く同じで、これもまた図らずも、Javaでのウェブ／データベースプログラミングの
向いて無いことを証明してる。なんでこんな複雑なもの覚えても、実際には
スクリプト言語で見通しよく書かれたコードのほうが、よほど生産性が高くて堅牢だよね。

761 ：デフォルトの名無しさん：2005/04/18(月) 22:29:59

だからSeaserなんてないと何度言ったら（ry

762 ：デフォルトの名無しさん：2005/04/19(火) 01:25:28

とはいっても、動くシステムつくってサービス提供して安定稼働させて設けてる香具師がゴマンといるわけだから。そっちが勝ち組

763 ：デフォルトの名無しさん：2005/04/19(火) 01:52:23

後学の為にと思ってコンテナの部分だけをつまみ食いしてるんだけど
なんか出来上がりが自作PCみたい(CLASSがパーツでDICONが配線)
になってしまったんだけど、使いどこ間違ってる？

将来拡張するかもしれないと思われる部分にだけ、ピンポイントで使う
のが正しい？それとも、もうあらゆる部分を全部個別部品として作って
最後にDICONで繋いで完成とするのが正しい？

Seasarの使い方ではなく使われ方？上手く言えないけど、こういう例
ではこう使え！って感じのノウハウ集とかってのはないかな？

764 ：デフォルトの名無しさん：2005/04/19(火) 04:45:13

>>762
Springのほうか？
それとも、SeasarもSpringも使わないやつらか？

765 ：デフォルトの名無しさん：2005/04/19(火) 04:51:51

>>760
そうだね。だから君はこのスレに来る必要はないと思うよ。

766 ：デフォルトの名無しさん：2005/04/19(火) 07:07:22

>>765

誰もこの疑問に反論はできないし、それでも、生産性が上がることをアピール
したいために、作者は一生懸命に作ってるのも分かるのだけど、
でも、老婆心だけど、ここは、引き返す勇気を呼び起こすときだと思う。
やりたきゃやっていいけど、根本的な間違いがあるが故に、
やった結果何も残らないのだとしたら、なんかもうかわいそうだ。

767 ：デフォルトの名無しさん：2005/04/19(火) 07:42:29

ま、Seasarがどうこうはあるけど、DIコンテナ自体を「複雑なもの」としか思えないなら、スクリプト言語で見通しよく書かれたコードのほうが、よほど生産性が高くて堅牢だな。
DIコンテナを「複雑なもの」と思ったんなら、老婆心だけど、ここは、転職する勇気を呼び起こすときだと思う。
なんかもうかわいそうだ。

768 ：デフォルトの名無しさん：2005/04/19(火) 07:54:03

正直、DIは一時的な流行に終わる可能性大と思われ。
ちょっと前に流行ったSWTのごとく。

769 ：デフォルトの名無しさん：2005/04/19(火) 08:11:21

メタ議論で煽ってるのは荒し。
自分ではプログラムもできずに、
大規模プロジェクトに下請け派遣で入ってるだけの可哀想な人。

こーゆー可哀想なのにも半端仕事あてがってやれよw >> ISID

770 ：デフォルトの名無しさん：2005/04/19(火) 08:12:57

>>762
画面一つ作るのに 1人月以上かけて、しまいにゃ実装をオフショア発注しちゃう、ダメダメ現場かｗ

771 ：デフォルトの名無しさん：2005/04/19(火) 08:13:50

↑>>760の間違いです。首釣ってきます

772 ：デフォルトの名無しさん：2005/04/19(火) 08:46:16

>>769
> メタ議論で煽ってるのは荒し。

どれをメタ議論といってるのかわからんが、その発言自体がメタ議論であることは確かだな。
ということはつまり、>>769はISIDに半端仕事くださいといってるわけか。

773 ：デフォルトの名無しさん：2005/04/19(火) 09:13:41

しかし、DIをSWTと同じように見てるところが底が浅いというか。

774 ：デフォルトの名無しさん：2005/04/19(火) 09:41:19

>>766
お前のせいじゃないから気にするな
心配しないでここから去れ

775 ：デフォルトの名無しさん：2005/04/19(火) 09:43:36

SWTは必要だが、DIは不用だよな。SWTには明確な実益がある。

776 ：デフォルトの名無しさん：2005/04/19(火) 10:23:26

SWTの明確な実益は、Swingの高速化で不明確な実益になった。
というか、いまどきSWTに明確な実益があるとか言いきってる時点で情報収集能力に疑問がでてくるね。

777 ：スレ違いとかそんなもんいいだろ：2005/04/19(火) 17:17:43

>>776

>SWT の明確な実益は、Swingの高速化で不明確な実益になった。

まぁ、Swingも悪くは無いんだけど、JFaceのContentProvider, LabelProvider, Decorator あたりの
アーキテクチャはモダンだと思ったし、やっぱりまだ SWT のほうが速いし、ウィンドウシステムに
対して忠実であるのはSwingとの明確な違いとしてあると思う。

778 ：デフォルトの名無しさん：2005/04/19(火) 21:43:00

ちょっと速くてもちょっと便利なところがあっても、全体的にはSwingの拡張性にかなわないしWindows以外では速いといえないし、資料はないしノウハウはないしツールはないし、デメリットで相殺されてしまう。
JDK1.4.1くらいまでなら、それでもデメリットに目をつぶれるような速度差があったけど、今はそこまでの速度差がない。
しかも、メモリやらリソースやら食うから、SWTの方が遅いこともありえるような気がする。

779 ：デフォルトの名無しさん：2005/04/20(水) 10:35:44

>>777,778
ｽﾚﾁｶﾞｲｳｻﾞｽ

ところで、S2JSF(だけに限らずSeasar2全般)のリファレンスマニュアルって作る気ないのかな。
皆あの中途半端な「サンプルの解説」だけで満足できるの？
俺一人なら、ソース読むなり何なりするのでいいんだけど、
チーム全員にそれを強要するのは、うちのチームじゃ無理だね。

本気でS2を普及させる気があるなら、バージョンアップより先に詳細なマニュアルを早く作ってくれろ。

780 ：デフォルトの名無しさん：2005/04/20(水) 11:09:44

http://www.amazon.co.jp/exec/obidos/ASIN/4839917779
立ち読みしたけど、連打対策とか戻るボタン対策とかの話まであって
かなり実践寄りでよさげだった。

マニュアルとういか、これのS2JSF/S2Dao/S2バージョンを
書いてくれないかなあ。

781 ：デフォルトの名無しさん：2005/04/20(水) 11:14:28

779がつくればいいとおもうよ

782 ：デフォルトの名無しさん：2005/04/20(水) 12:46:38

>>779
「サンプルの解説」がダメなのにリファレンスなら大丈夫って
珍しいメンバーだね。
リファレンスだけあっても～ならありがちだけど。

783 ：デフォルトの名無しさん：2005/04/20(水) 13:57:03

>>782
サンプルでは機能が網羅してないってことだろ。
網羅してたとしてもリファレンス性も悪いし。

784 ：デフォルトの名無しさん：2005/04/20(水) 15:18:28

>>782
違う違う。サンプル解説がだめなわけじゃないって。
サンプル解説のおかげで、
「S2JSF使えばどういうことが出来るのか」って言うのはよく分かったよ。
それはいいのよ。確かによく分かったしありがたいこってす。

でもね、いざ新しい物を作ろうと思うと、どういう部品がどういう風に絡み合ってるのか、
新しい部品を作るにはどうしたら良いのか、そういうことが全然わかんなくて、すぐ壁にぶち当たりまくり。

「どういうことができるか」はとってもよく分かるけど、
「どういう風に作ればよいのか」が全然わかんない。サンプルの解説だけじゃね。

ちょいと誤解してるようだけど、リファレンスだけあれば良いっつってんじゃないよ。
サンプルの解説も、リファレンスも両方（できればチュートリアルもｗ）欲しいって言ってるの。

>>781
ごめんね。100%完璧に理解してるわけじゃないからこそ、
リファレンス等のドキュメントが欲しいのよ。

俺必死だなw

785 ：デフォルトの名無しさん：2005/04/20(水) 15:55:26

ちょっと雑談させてよね。
>>784
確かに資料、情報は多いに越したことはないもんな。
多くの人に普及させたければ必要なことだろうと思う。

ただ、こういうのって必要と思った人が用意するって文化を推奨してる
から。君がぶち当たった壁をWikiなりなんなりで公開すると
みんなウハウハ・・と。実際はそんな理想的にならないんだろうけど。

作者の周りには人が集まっているようで、いろいろ仕事割り振って
うまく回っていると俺は思っているんだけど、プログラマがあまりしたがらない
全体の統一的なドキュメント化のような部分をやってくれる人が多数
参加するようになるともっと良いのかもしれないね。
それにはもう少し時間が必要なんじゃない？

786 ：デフォルトの名無しさん：2005/04/20(水) 20:20:34

もう充分時間が経ったわけで。
リファレンスの必要性自体を感じてないような気もする。
日本語情報が多いっていうのがひとつの売りということだったけど、koichikさんのSpring入門記の方がSeasarのドキュメントよりも充実してる気がするし。

ってか、サンプルとかその解説とかは部外者にも書けるんだけど、リファレンスは開発者じゃないと書けないんだよね。

787 ：デフォルトの名無しさん：2005/04/20(水) 20:40:25

それはそうと、SeasarもSpringみたいに、主要バージョンは取り込んでバージョン番号をつけてリリースして欲しいね。
バージョンの依存関係がわけわかめ。

788 ：784：2005/04/20(水) 20:56:30

>>785
確かに協力してく気があるなら、
リファレンスは無理にしても、
「こんなのにぶちあたっちゃったの」は公開していくべきでしたね。
でも正直、ぶち当たりすぎちゃって既に嫌になってる部分もあったり…＿|￣|○ ﾓｳS2Strutsﾃﾞｲｲﾓﾝ

「ドキュメント不足」っていう理由のせいで、
S2JSFから人が遠のくなんてことは、実に寂しいことだと思うのです。
まずは人を惹きつけて…卵が先か、の話にはなっちゃいますけどね。

>>787
1行目は何言ってるのかわかんないけど、2行目は禿同。
その辺も、Seasarの敷居が高くなってる原因の一つだと思う。

789 ：デフォルトの名無しさん：2005/04/20(水) 20:59:50

結局ひがさんには、プロダクトを開発するセンスはあっても、プロダクトをプロモーションするセンスはなかったってことだよ。

790 ：デフォルトの名無しさん：2005/04/20(水) 21:49:37

>>789

漏れはプロモーションのセンスあると思うよ。
残念ながらSeasar は役立たずだけど、それでも雑誌の記事に載せるところまでは
到達できたのはたいしたもの。

Seasarのコミュニティがなかなか出来上がらないのは当然のことで、
もともとSeasarは実はあまり意味のない代物だから、分かってる人にしてみればスルーするだけだし
逆に、リテラシーの低い初心者が「分からないからドキュメントくれ」　が群れてくる。

いいプロダクトなら、リテラシーの高い人がチカラを貸すよ。カネになるってもそうだけど、
ちょっと頑張るだけで世界が変わるのを実感できる。
Seasarじゃ何も変わらないってのが、リテラシーの高い人には見えちゃうんだよ。

791 ：デフォルトの名無しさん：2005/04/20(水) 21:51:33

でも、開発者に全てを望むのは酷だよね。
開発されているものの価値を見出した人の中から広告塔になってくれるような
人が現れる流れがあると、自分らも楽しいと思わない？夢物語かなぁ。

作る才がある人が作ることにのみ集中できて、
その他の事をうまく分散できるといいのに。とか思ったりする。

792 ：デフォルトの名無しさん：2005/04/20(水) 21:58:27

>>791

Seasarが価値があるものならそれは人は現われるけど、そうではないのだから、どうしよもない。

793 ：デフォルトの名無しさん：2005/04/20(水) 22:02:28

>>790
的を射ているのかもしれない。

フレームワークなのだから、既にしっかりしたノウハウを持っている人の目には
今更…のように写ったりしそう。ただ、作成される多くのものが
そのフレームワークの作法に従うことで統一感が生まれて保守効率が
上がるような可能性はあるよね。それでは世界を変えるまではいかないけど。

プロジェクトとして推す時に「ここに詳細な情報があります」って言えることは
かなり大事じゃないかな。誰それのブログ端から読んでよってのはどうかねぇ。
情報は統一されていないと探しづらいと思うのだ。
これは、狙っている層がJavaの業務アプリだから特に思うこと。

794 ：デフォルトの名無しさん：2005/04/20(水) 22:03:49

>>790
雑誌の記事に載せるくらいでプロモーション力あるというなら、プロモーション力の敷居はかなり低いんだな。

795 ：デフォルトの名無しさん：2005/04/20(水) 22:05:27

>>793
MLのログもありますよｗ。

796 ：デフォルトの名無しさん：2005/04/20(水) 22:14:18

>>793

作法には価値があると思う。
だから、Seasarはだめでも、「くーす」はなかなか、広める価値のあるものだと思ってて。
コントロールはステートレスとか、分かってる人にしてみれば、当たり前だろみたいなことだけど、
学習中はその徹を踏んでしまうかも。

オブジェクト指向プログラミングって、深い理由がわからなくても、ＯＯ的にデザインされた
ライブラリを使うことで自然に生産性上がるのを体感して意味もわかってくるみたいなこと
あるけど、ウェブ／データベースプログラミングにおいては、いまいち実感しづらいところもあって、
Seasar使えば分かるんじゃないかみたいな人いると思うんだけど、残念ながら、
これはいくら使っても体感できないんだよね。

作法は作法として覚えるしかないと思う。フレームワークが解決することとも思えない。
Javaはウェブ／データベースプログラミングには向いてないし。
ホントに原理がシンプルで扱いやすいフレームワーク／言語も含めたプラットフォームの
分かりやすいものだけが生き残る。

797 ：デフォルトの名無しさん：2005/04/20(水) 22:17:21

>>794

雑誌って基本的にアホで、特にソフト開発者向けの雑誌ってさらにアホなんだけど、
それでも載せるってのは、あほだからこそでもあるけど、そう簡単じゃないぜ。

798 ：デフォルトの名無しさん：2005/04/20(水) 22:36:34

>>796
自分とは思想が逆みたいなんだけど、面白いのでしつこく食い下がってみる。
作法はできる限りフレームワークで吸収してやる部分じゃないかな。
例を挙げちゃうと焦点がぶれたりする可能性があるので
逆にまずいかもしれないけど、StrutsなんてFrontControllerだよね。
これをFrontController知らない人でも強制的に使わせてるよなと。

覚えること、考えることを減らすためにフレームワークやライブラリは存在
すると思う。オブジェクト指向については流すよ。哲学論争になりやすいし。

＞ホントに原理がシンプルで扱いやすいフレームワーク／言語も含めたプラットフォームの
＞分かりやすいものだけが生き残る。
これには同意。特に多人数開発ではキーになる考え方だろう。
わかりやすくて、しょぼい開発者がいてもちゃんと動く仕組みが宜しいかと。
そういう意味ではJavaもDIもそんなに的外れではないかなと思ってる。

799 ：デフォルトの名無しさん：2005/04/20(水) 22:43:44

>>798

> しょぼい開発者がいてもちゃんと動く仕組みが宜しいかと。
> そういう意味ではJavaもDIもそんなに的外れではない

フレームワークに関しては、漏れは、
ホントにいいものなら、無いよりはマシくらいの位置づけで、
たぶん、ほとんどの人はそうでないか。

フレームワークでしょぼい開発者が救われるのかといえば、少しは寄与するかしれんが、かなり嘘で、
そんなもん、ただ開発プロセスの中に学習・フィードバックの仕組みが機能してるかどうかだけにかかってる。

だから、もうSeasarとかJ2EEとかSpringやらに騙されるな、近寄るなと漏れは知らせたいんだよ。
そっちのほうがはるかに社会的だと思わんか。

800 ：デフォルトの名無しさん：2005/04/20(水) 22:46:19

フレームワークが少しは寄与するっつっても、それはいいフレームワークの場合の話で、
Javaはもともとウェブ／データベースプログラミングに向いてないし、
Seasarとか評価してみたけどやっぱり使わないほうがマシなんだよ。

801 ：798：2005/04/20(水) 22:47:13

ちょっと「作法」の意味がずれてしまっていたかもしれない。
>>793の「作法」はソースコードの統一感としての作法で
>>796以降の「作法」はもう少し価値の高いある種パターンのような
分野にまで発展した考えで論じられているね。

特に訂正は無いんだけど、確認のため投稿。

802 ：デフォルトの名無しさん：2005/04/20(水) 22:53:22

>>801

>793の「作法」はソースコードの統一感としての作法

まさかとは思ったけど、こういうのをフレームワークで縛れるとか思ってる人がまだ結構いるんだよね。
現実に目の当たりにすると、腹の底から軽蔑しますよ。
ホントにヒドイと思う。

803 ：デフォルトの名無しさん：2005/04/20(水) 22:58:04

>>799
> だから、もうSeasarとかJ2EEとかSpringやらに騙されるな
> 近寄るなと漏れは知らせたいんだよ。
> そっちのほうがはるかに社会的だと思わんか。

最後のこの部分しか読んでないが、この意見がアホなこといってることはわかる。

804 ：デフォルトの名無しさん：2005/04/20(水) 23:01:20

>>799
優等生的に答えると、フレームワークは設計の再利用だよね。
これは実装の再利用であるライブラリと対になっていると思う。
無ければ自分でその時作るだけ。だけどある程度良い設計、実装が
既に提示されているのなら利用した方が良いぞと。

既存フレームワークで救うのはしょぼい開発者の中でも
駆け出しの設計者になるだろう。あと、熟練者でもわざわざ0から
フレームワークを構築しなくて良くなるので時間の節約になるよね。
ドキュメント書かなくても良いし、既にそれを知ってる人はいきなり使うだけだし。

＞フレームワークでしょぼい開発者が救われるのかといえば、少しは寄与するかしれんが、かなり嘘で、
＞そんなもん、ただ開発プロセスの中に学習・フィードバックの仕組みが機能してるかどうかだけにかかってる。
教育の仕方をどうするかって話で解釈合っているかな。
もう少し上のレベルに話が広がってしまいそうなので流します。

805 ：デフォルトの名無しさん：2005/04/20(水) 23:11:08

＞だから、もうSeasarとかJ2EEとかSpringやらに騙されるな、近寄るなと漏れは知らせたいんだよ。
＞そっちのほうがはるかに社会的だと思わんか。
いろいろ書こうと思ったけど、まとまらなかったので質問してみる。
>>799の開発ではどんなフレームワークを使っているの？
もし良かったら書いてみてくれないかな。その方が話がわかりやすくなりそう。

>>802
うーんと、言わんとしているところが良くわからなかった。
ソースコードの統一感って言うのは見た目の問題だから
「Strutsで作ってるよ」「あー、じゃぁActionクラスを継承すんのね」
みたいな部分という意味で書いたんだ。もう少し書いてみてくれないか？

806 ：デフォルトの名無しさん：2005/04/20(水) 23:12:51

>>803
自分はここ以外はそれほど的外れでも無さそうに思ってる。

807 ：デフォルトの名無しさん：2005/04/20(水) 23:25:02

>>805
Seasar使うくらいならPure Servletのほうがいいよ。
シンプルにやりゃいい。

Struts使うことでAction使うことが自明になるとしても、それが？　って感じでしょ。
何の役にも立たない。なら使わないほうがいい。

ウェブインターフェースのアプリケーションなら、
Rubyが最適だと思いますよ。文字列処理が高機能、コードも短くて済む。
いい実装例だなと感じてるのは

http://www2a.biglobe.ne.jp/~seki/ruby/divip.html

バックエンドとの分離も簡単シンプル、台数並べれば並べるほど比例して処理を分散する
みたいな仕組みも作れる。そのプログラミングも贅肉なしのライブラリが使えるし。

808 ：デフォルトの名無しさん：2005/04/20(水) 23:35:47

>>807
えーと、プロジェクトの中でみんなServlet開発をしているって意味かな。
それは開発のスピードが遅そうに感じるんだけど、自分だけだろうか。
StrutsのActionの話は、そういう部分を合わせないと理解が遅い人が
いるよねって話。逆にこんなもん合わせるだけでルーチンワークに
乗せられたりするものだったりもする。

自分は今までの話を「多人数で開発する」ということを念頭に書いてる。
これは、Seasarみたいなものが狙っているターゲットがそうだから。
紹介してくれたアプリも多人数で開発するようなものでは無さそうだね。

ちなみに、個人で使うなら今のS2を使わないってのは自分もそうだと思うよ。
一人でWEBサイト構築するならRUBYは触ったこと無いのでPHPかな。
共通部をまとめてるうちに結局自分用フレームワークできちゃうけど。

809 ：803：2005/04/20(水) 23:44:20

>>806
あ、ほんとだ。
ってことはあれだね。
正しい意見を述べておいて、結論だけは正しくない意見にしておけば、正しくない意見を正しいと思わせることができるっていう高等技術。

810 ：デフォルトの名無しさん：2005/04/20(水) 23:45:51

>>807
Strutsは単にフォームへの入力をBeanに格納してくれるただのライブラリだ。

811 ：デフォルトの名無しさん：2005/04/20(水) 23:52:58

いくらRubyがよくってもまだまだ採用しやすい状況じゃないんだよね。
5年かもっと前のJavaみたいなもんで、ユーザとか元請けのSIerから
止められるのが普通じゃない？ちっちゃいところはいいかもしれんけど。
Rubyできるやつサクッと集められるとも思えないしね。
だから、ここでRubyが最適とかいわれても逃避にしか見えない。
Javaでどうするか、DIでどうにかなるのか、って所でスゲーやつの
話が聞きたいです。

812 ：デフォルトの名無しさん：2005/04/20(水) 23:57:13

>>809
いや、大抵は>>803みたいに最後だけ見て「こりゃだめだ」って切り捨てられる罠。

そろそろ筆置きます。
長文連発すまなかった。＞スレの人々
あと、S2から凄く離れてしまってすまん。
長々付き合いありがとう。>>807

813 ：デフォルトの名無しさん：2005/04/21(木) 01:35:17

>>788
>>787が1行目で言いたいのは、
メジャーなリリースと、マイナーなバージョンアップを分けてほしいということかと。

814 ：787：2005/04/21(木) 01:51:04

>>813
いや、S2StrutsとかS2JSFとか、全部含んでSeasar2.x.xとして出して欲しいってことです。
S2JSFのこのバージョンはSeasar2.1.8じゃないと動きませんよ、とか、でもS2XXXはこのバージョンでは動きませんよとか、わけわからん。

815 ：デフォルトの名無しさん：2005/04/21(木) 10:33:20

XMLファイルで生成物を変更できる小洒落たファクトリーとしてしか理解できてない
んだけど、十分に単純で便利だと思うんだが・・・・・・
なんでここでは否定的な意見の方が多いんだろう？

816 ：デフォルトの名無しさん：2005/04/21(木) 10:41:59

簡便なものが実用可能となると決まって反発がある。
そんな感じじゃないですか。

eclipseからJava始めた人はクラスパスとか
判ってなくてけしからん、とか。
俺は知らなくてもできるんならそれでいいし
トラブルになったらその時に調べて
覚えりゃいいと思うんだがなあ。

817 ：デフォルトの名無しさん：2005/04/21(木) 10:53:27

>>815
この理解で概ね合っていると思っていいよな？駄目だったら頭いい人突っ込んでくれ。
AbstractFactoryにしたくなるような生成部分を統一的な方法で提供しているって
理解なんだけど。

818 ：デフォルトの名無しさん：2005/04/21(木) 11:11:31

>>815
それならSpringの方が日本語の資料も多くて便利

819 ：デフォルトの名無しさん：2005/04/21(木) 11:22:28

>>815
ここで小難しいこと言ってSeasarだめ論(もっと言うとJavaだめ論)を展開してる人って、
案外そういう簡単なことが分からないのかもね。
難しく考えすぎと言うか。

>>818
それは好みの問題でしょう。

820 ：デフォルトの名無しさん：2005/04/21(木) 11:34:14

>>819
Seasarの説明に、次世代どうのこうのとか小難しく書いてあるから。

821 ：デフォルトの名無しさん：2005/04/21(木) 11:45:14

>>814
S2とS2Daoと、あと戦略商品としてS2JSFをバンドルしてくれればいい。
個人的にはS2Strutsも。

822 ：デフォルトの名無しさん：2005/04/21(木) 11:59:00

koichikさんﾚｽｱﾘｶﾞ㌧

823 ：デフォルトの名無しさん：2005/04/21(木) 12:09:22

>>807
> Seasar使うくらいならPure Servletのほうがいいよ。
> シンプルにやりゃいい。

シンプルっていうよりサンプルしか作ったことないとか？
まともに開発したことあるやつとは思えない。

> バックエンドとの分離も簡単シンプル、台数並べれば並べるほど比例して処理を分散する
> みたいな仕組みも作れる。そのプログラミングも贅肉なしのライブラリが使えるし。

後ろが分散できたってしょうがないだろ。なんか素人くさい。学生？

824 ：デフォルトの名無しさん：2005/04/21(木) 12:13:42

>>821
標準セットパッケージみたいな感じだよね。
これ一個でとりあえず美味しい汁を吸えますみたいな。

825 ：デフォルトの名無しさん：2005/04/21(木) 12:14:32

>>823
まぁまぁ、そう反応しなさんな。
見てる切り口が多分全然違うのだよ。

826 ：デフォルトの名無しさん：2005/04/21(木) 12:26:10

>>823
Strutsすら必要ないなら、Seasarも使わずServletに処理ベタ書きの方がいいってことじゃない？
仕事にはいろんな規模のものがあるんだから、それはそれでいいかと。

827 ：デフォルトの名無しさん：2005/04/21(木) 12:27:54

>>824
S2JSFがSeasarのコンテナ機能を使わずUtilだけ使ってるんだったら、UtilをわけてS2+S2DAO+Util/S2JSF+Utilというふたつのパッケージでもいい。

828 ：デフォルトの名無しさん：2005/04/21(木) 12:37:09

>>827
普通にjsf.diconとかあるけど

829 ：デフォルトの名無しさん：2005/04/21(木) 15:57:26

>>826
もちろんそれはそれで良いと思う。
けど、だからつって物知り顔で「誰にとってもフレームワークひいてはS2イラネ」って言うのはどうかと思う。
あんだけ自信満々で言われちゃうと、漏れみたいなお馬鹿チンは「本当にいらないのかな…」って不安になっちまう。
自分は今有効に使えてるのにね。

830 ：デフォルトの名無しさん：2005/04/21(木) 16:23:42

>>829
残念だけど、その取捨選択は君がするしか無いと思うよ。
人の言っていることを盲目的に受け入れるべきなのかそうでないのかって
ことだから。ここの人は自分が思うことを好き勝手に書いているだけだし。
>>790->>807みたいにちゃんと突っ込んだ話をしないとその根拠が
明白にならないからなかなか判断しようが無いのだけれど。

で、自分は彼の話がごく一部しか捉えていないようだと判断した。

＞自分は今有効に使えてるのにね。
これを根拠に「自分には必要だ」でも良いんじゃない？

831 ：デフォルトの名無しさん：2005/04/21(木) 20:39:58

>>819
日本語資料の多寡は「好みの問題」ではありません。

832 ：デフォルトの名無しさん：2005/04/21(木) 21:57:18

Tapestryが好みでしか使えないように、Seasar2も好みでしか使えないと。

833 ：デフォルトの名無しさん：2005/04/21(木) 22:53:58

またTapestryが何者だか訳分からんのだよなｗ
JAVAはフレームワーク多すぎ！て言うか、なんでもかんでもフレームワーク
って呼びすぎ！
俺のこれまでの知識では、「フレームワーク＝湯の張られた鍋」と理解してた。
具材を入れていくと料理になるという、そんなイメージ？
でも、JAVAでは制御の反転が絡むと全部フレームワークって呼びやがる。
Seasarでどんな料理が出来上がるのか、10日も探し回っちまったじゃねぇ～か！
当然、それだけでは料理になんかなるわけねぇ～！そもそも、鍋ですらねぇ～！
どっちかっつぅ～と、やかん？とにかく、俺の馬鹿＿|￣|○|||

834 ：デフォルトの名無しさん：2005/04/21(木) 22:57:07

Seasarってフレームワークだっけ？

最初からIoCコンテナ(DIコンテナ)としか言ってないような。やかんどころかコンロですな。

835 ：デフォルトの名無しさん：2005/04/21(木) 23:04:07

>>833
コールバックを含むライブラリのことをフレームワークと呼ぶのだよ。

836 ：デフォルトの名無しさん：2005/04/21(木) 23:04:50

>>834
分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は
ある。て言うか、変な人ほどフレｄｊさｋｌｊｆｓぢｊｆさいｊふぉいｊ

やかんの心は、冷たい液体から温かい液体を生成するファクトリー

837 ：デフォルトの名無しさん：2005/04/22(金) 00:11:45

>>836
> >>834
> 分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は

JARの名前がs2-framework～である件について

838 ：デフォルトの名無しさん：2005/04/22(金) 00:24:17

Apache AvalonがFrameworkを名乗るからには、SeasarだってFrameworkって名乗ったっていいだろうなあ。

Avalonは(Jamesみたいな）サーバアプリケーションを作成するためのフレームワークと銘打ってるけどね。

839 ：デフォルトの名無しさん：2005/04/22(金) 00:39:32

>>838
Seasarの場合は、S2Daoとか周辺を含まずにフレームワークなわけで。

840 ：デフォルトの名無しさん：2005/04/22(金) 00:49:59

>>839
Avalon Frameworkだって周辺も何も含まずにフレームワークを名乗っていた。
あれはコンテナとコンポーネントのコントラクトを規定しただけのライブラリ。
Avalon Excaliburがコンテナの実装、Avalon Phenixになるとサーバ
アプリケーション用のフレームワークという位置づけになっていたかと。
Marlinはよーわからんがそうやって発散してお亡くなりに…

841 ：デフォルトの名無しさん：2005/04/22(金) 01:18:27

まぁ、分類は学問的なこと考える人たちがすれば良い訳で。
分類の根拠がなんなのか位は抑えておいてもいいだろうけどな。

842 ：デフォルトの名無しさん：2005/04/22(金) 10:52:46

Javaでは>>835の定義だな。

843 ：デフォルトの名無しさん：2005/04/22(金) 10:53:49

テンプレートメソッドなクラスがあれば、フレームワークなのだよ。

844 ：デフォルトの名無しさん：2005/04/22(金) 21:10:01

とゆーか生Servletだってフレームワークだし

845 ：デフォルトの名無しさん：2005/04/22(金) 21:57:18

DIコンテナって、いろんな実装があるけど・・・
俺も学習用につくってみてもいいか？

846 ：デフォルトの名無しさん：2005/04/22(金) 23:45:49

>>843
それは文字通りのフレームワークだと思う。

ファンクタを要求する単体のオブジェクトはどうなんだろう？
IoCを伴ってはいるけど、これをフレームワークと呼ぶのに
は激しく抵抗を感じる。

>>845
いいんじゃない？
DIコンテナという言葉こそ出てこないけど、JAVAの格言に
は、抽象ファクトリーパターンと動的クラスローディングの
組み合わせ例として、iniファイルを利用したDIコンテナが紹
介されてる。

847 ：デフォルトの名無しさん：2005/04/23(土) 02:17:41

>>845
いいよ。
AOPまで実装すれば、とりあえずSeasarの対抗馬としてプロモーションできるし。
ドキュメントとメディアの取り込みさえできれば、すぐ広められる。
ただし、そういうプロダクトを運営するのには、結構手間がかかるし、覚悟がいる。

848 ：デフォルトの名無しさん：2005/04/23(土) 02:32:29

>>847
SeasarやSpringと張り合おうなんて気は毛頭ないから安心してくれ。
あくまで学習用だからきれいでシンプルな実装をしたい。

849 ：デフォルトの名無しさん：2005/04/23(土) 10:43:19

>>848
俺はそういう取り組みの繰り返しが将来の技術力を養うと思う。頑張れ。

850 ：デフォルトの名無しさん：2005/04/23(土) 11:24:16

>>848
そしたら、機能的にはPicoContainerとかをまず見てみるといいかも。

851 ：デフォルトの名無しさん：2005/04/23(土) 11:42:02

>>849
おいらはいい加減おっさんだが35歳で限界を迎えないように精進するよ。ありがとね。

>>850
Spring、Seasar、PicoContainerあたりの実装は確認済み。
PicoContainerのシンプルさは好きだね。

で、CgLibとjavassistの比較してるサイトとかしらん？

852 ：デフォルトの名無しさん：2005/04/23(土) 22:31:40

>>851
>で、CgLibとjavassistの比較してるサイトとかしらん？
ここらへんってちょっと前にSeasarでも話題になってたし、はてなでもいって探せば
参考になるサイトとか出てくるんじゃねー

853 ：デフォルトの名無しさん：2005/04/24(日) 01:43:13

>>817

AbstractFactoryが必要な部分ってシステムのコアに相当する部分で、
ここは自由にプログラミングできてしかるべきところを、
言語の非標準機能を使ってまで、統一的にする意味あんのかってあたりが微妙で、
テストしやすいとかいってるけど、これも結構あやしいと思う。
要するに、モックオブジェクトを返したいってことなんだろうけど、
冷静に考えて、それを作りたいシーンって、ホントにシステムのコアに相当する部分で、
ごく一部であって、そこをフレームワークにまかせてどうにかなるってことも、
無い気がする。有効なシーンがあれば教えてほしい。

854 ：デフォルトの名無しさん：2005/04/24(日) 02:39:08

>>853
もうフレームワークって呼ぶな。話が無駄に混乱する。

有効なシーンも何も、幹と枝葉の相関を切りたいという要求は
普通にと言うより普遍的にあるはずだが・・・・・・

855 ：デフォルトの名無しさん：2005/04/24(日) 02:57:19

>>854
切りたい欲求はそんなに無い、あったとしても、
そこはそのアプリケーションに合った適切な切り方をしたほうが
DIコンテナ機構を使うよりいいってこと思うんだけど

856 ：デフォルトの名無しさん：2005/04/24(日) 21:42:58

>>855
> そこはそのアプリケーションに合った適切な切り方をしたほうが

「アプリケーションに合った」部分をDIコンテナは侵食しないぞ。
あなたの設計だと、Factory部分のコードがアプリケーションによって変わってくるのか？
かなりひどい設計だと想像するけど。

857 ：デフォルトの名無しさん：2005/04/24(日) 22:57:32

俺はもう説明を諦めたんだが・・・・・・

>>856
どう言っても無駄だと思うぞ。
変な話だが、円滑なコミュニケーションにデザパタがどれほど大き
く寄与してるか実感した。

JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
からコンパイルへの依存を排除できる点」だよ。
で、説明は終わりなんだよな。
多段に積み重なった知識の最上段のみを対象に会話を進めていく
って行為は、モードの違う相手とはチャンネルが合わないんだなとｗ

858 ：デフォルトの名無しさん：2005/04/24(日) 23:44:32

>>857
> JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
> からコンパイルへの依存を排除できる点」だよ。
> で、説明は終わりなんだよな。

使ってるやつはそれで説明が終わりと思ってて、使ってないやつにとってはそれでは説明になってないと思う。

859 ：デフォルトの名無しさん：2005/04/25(月) 00:10:03

DIはパターンとしては優れてると思うんだが、
SeasarにしてもSpringにしても使うのちとめどい・・・
Picoのほうが個人的には好きなのだが、それほど使われてない模様

SeasarにコアのDI以外にも便利な機能って何が入ってるのさ
S2Strutsはそれほど便利でなかったし、
JDBC連携もDbUtilsとかで代用できんの？

ともかくXMLの設定とかめどい

860 ：デフォルトの名無しさん：2005/04/25(月) 02:07:25

AOPのこともたまには思い出してやってください…

861 ：デフォルトの名無しさん：2005/04/25(月) 02:24:32

>>856
>Factory部分のコードがアプリケーションによって変わってくるのか？

ソフトウェアの核になる部分って、やっぱり
キャッシュを解放するタイミングとか、ログの取り方、バックアップの取り方、パフォーマンスの計測とか
いろいろやることがあって、変わるに決まってると思うのだが

862 ：デフォルトの名無しさん：2005/04/25(月) 02:56:03

もう、なんつーかさ、スルーしとけばいいのか？

863 ：デフォルトの名無しさん：2005/04/25(月) 14:14:53

>>859
XMLがめんどいというやつは、Springをちょっと使って、
Seasarを使ってないやつに多い｡

Picoがいいというやつは、最近あまりみたことないが、
PicoよりはSeasarが簡単だろう｡
同じようにコンストラクタによるAutowireができて、
classを登録するだけですむんだから｡

APIをじかにたたく分には、SeasarもPicoもあまりかわらない。

864 ：デフォルトの名無しさん：2005/04/25(月) 18:17:21

>>861
ファクトリーは生成のパターンだから構造や制御とは無関係だよ。

865 ：デフォルトの名無しさん：2005/04/25(月) 19:03:38

>>862
頭がツルツルなのがきたら、スルーでおっけ

866 ：デフォルトの名無しさん：2005/04/25(月) 19:08:27

某所のコンサルで、

　　factory method数≒全クラス数

　　ただしfactory methodは大抵singletonを返す

ってのが居た。あの類だろｗ

867 ：デフォルトの名無しさん：2005/04/26(火) 00:15:33

>>864
フツーにnewするのがナニが不満なのか。
なんでもないところにAbstractFactory用いる意味は無い。

もしAbstractFactoryを導入する価値のある個所があるのだとすれば、
それはシステムのコアであるから、どっちにしろ、ここは自由にプログラミング
できないと無意味である。

868 ：デフォルトの名無しさん：2005/04/26(火) 00:21:47

つうか、じゃあ今のEJB使ってロジック層作ってみれば、なんでDIコンテナが出てきたか
なんて、１日の試用でわかるんじゃねえの？ EJB使った上で、DIなんて無意味非効率めんどくせえ、
とかいうやつがいたら、どっかいかれてるとしか思えん。

869 ：デフォルトの名無しさん：2005/04/26(火) 00:58:12

ソロプログラマでRAD使いの臭いがプンプンするな。
て言うか、十中八九こいつVBプログラマだｗ

870 ：866：2005/04/26(火) 01:35:32

>>866に書いたのは、>>861や>>869みたいな頓珍漢の事ね。

871 ：デフォルトの名無しさん：2005/04/26(火) 01:54:49

>>868
あれだね。
EJBを必要と思わなかったら、まったく意味のない比較だね。
めちゃくちゃめんどいEJBがめんどいDIになっただけということ？

872 ：デフォルトの名無しさん：2005/04/26(火) 02:44:31

>>871
そりゃそうだろ。DIコンテナが生まれてきた経緯を考えると、EJBへのアンチテーゼ
そのものなんだし。解決しようとしてる土俵で比較するのが筋じゃないか？

めちゃめちゃしんどいEJBが楽なDIコンテナに変わったってことだろ。
EJBはめんどいけど、コンテナのインスタンス制御機能（つまりファクトリとしての機能）や、
コンテナ制御のトランザクションなんて機能自体は必要なんだよ。そのために苦労して
EJB使うわけで。

DIコンテナはその両方を簡単に解決するじゃん。DIコンテナよりも簡単にEJBの機能を
提供してるものがあるんだったら、おれはすぐにでもそっちに乗り換えるよ。

873 ：デフォルトの名無しさん：2005/04/26(火) 03:30:16

つうことはEJB3がでりゃSeasarは必要ないってことだね。

874 ：デフォルトの名無しさん：2005/04/26(火) 04:05:05

そうか？

875 ：デフォルトの名無しさん：2005/04/26(火) 04:14:52

DIコンテナ機能あるし、簡単に使えるツールも出るだろうし。

876 ：デフォルトの名無しさん：2005/04/26(火) 05:00:17

XMLで定義する意味っていえば、
XMLはツールとの相性のよさってのがあって、
人間にも読めて機械にも読めるフォーマットとして意味があると思うんだけど、
なんつーか、DIコンテナなんつーものは、
本来はプログラミング言語が兼ね備えているべきレベルでの単純すぎるオブジェクト生成
にしか使えなくて、フツーにnew するのと変わらん。そんなのに意味あるか。

むしろそういうことなら、Eclipseのプラグインアーキテクチャにおけるxmlによる、
読み込むクラスの定義のほうが、価値があると思う。

877 ：デフォルトの名無しさん：2005/04/26(火) 05:46:20

>>876
XMLでの定義がいやなら、アノテーション。

878 ：デフォルトの名無しさん：2005/04/26(火) 06:58:17

S2GroovyBuilderもあるぞ

879 ：デフォルトの名無しさん：2005/04/26(火) 09:33:51

>>876
＞本来はプログラミング言語が兼ね備えているべきレベルでの単純すぎるオブジェクト生成
＞にしか使えなくて、フツーにnew するのと変わらん。そんなのに意味あるか。
このあたりが何を言いたいのかもう少し知りたい。
それと、どんなアプリを作る人なの？
この辺の違いがわかると話が噛み合ってくると思う。

880 ：デフォルトの名無しさん：2005/04/26(火) 18:29:17

>>873
正直、EJB3は全く追いきれてないんだが、DIコンテナ＋AOPという小さな
機能部品としてのSeasarには需要が残り続けると思う。

881 ：デフォルトの名無しさん：2005/04/26(火) 18:41:16

>Eclipseのプラグインアーキテクチャにおけるxmlによる
>読み込むクラスの定義のほうが、価値があると思う。
いや、それがDI(Dependency Injection = 依存性の挿入)でしょ？
コンパイルへの依存性を排除できるって、そういう事だと思ワン？

「価値があると思う」って、思いっきり認めちゃってるみたいだけど・・・・・・
えと、どういう事？DIコンテナは認めるけど、Seasarは駄目って話？
て言うか、スレが進むうちに段々DIコンテナの利点が分かってき
たんじゃないか？別に無理繰り否定する必要はないんだぞ？

882 ：デフォルトの名無しさん：2005/04/26(火) 19:36:20

>>881
それを一般アプリケーションに広げる価値はないといってるのでは？

883 ：デフォルトの名無しさん：2005/04/26(火) 20:19:59

EJBもめんどいと思うがDIも十分めんどい
もっと楽な方法が出てきそう

884 ：デフォルトの名無しさん：2005/04/26(火) 20:22:20

>>881
DIをするための方法として、一般的にDIコンテナと呼ばれている物の
方法は良くないと言いたいのかねぇ。

あ、違うよ。きっと彼はプラグインがDIだってわかってなかったんだ。

むしろそういうことなら、こんな不毛な議論なんかやめて
別の話したほうが、価値があると思う。

885 ：デフォルトの名無しさん：2005/04/26(火) 23:39:22

>>867 >>876

「AとBを結びつけるときに、その結びつきがAやBの中に直接埋
め込まれているのではなく、Cがその仲介をしてあげてくれると
AとBの実装がお互いに依存しなくて嬉しい」

っていうのがDIのありがたみだと思うのだけれど、これ自体には
異論はないのかな。
それともこれ自体に異論があるのか？

で、DIコンテナは上記のCにあたるところを一括して面倒みてく
れるのだけれど、その方法として「AやBの生成を請け負う」とい
うやりかたをしているため、その副作用として「生成したものを一
定の方法で改ざんできる（＝AOPを適用できる）」というメリットが
出てきていて、そこが個別にAbstractFactoryを用いるのとは決
定的に異なるのかなと。

886 ：デフォルトの名無しさん：2005/04/27(水) 01:09:19

>>885
あらたにCを導入して依存関係を複雑にしてるだけにも読めるが。
ともあれDI使ったところでAとBは依存するし、使わなくても実装が依存しないようにできるし。

887 ：デフォルトの名無しさん：2005/04/27(水) 01:17:55

アンチDIさんにはそろそろDIレスな素敵な実装キボンヌ

888 ：デフォルトの名無しさん：2005/04/27(水) 01:58:33

具体的な提案もないし、いちゃもんつけてるだけの厨にしかみえん
つーかスレ違いだ。DIスレでやれ

889 ：デフォルトの名無しさん：2005/04/27(水) 02:28:03

>>886
インターフェースに対しても同じ様な反応があるな。
AクラスとBクラスがそれぞれCインターフェースに依存してる。依存関係を複雑にしてる
だけなのではないか？と・・・・・・
「インターフェースに対してプログラミングする事でクラス間の依存性を排除できる」とい
う教科書的な説明は、間を省略し過ぎてて実は説明になってない。
インターフェースに対してプログラミングする事で直接的に排除できるのは特定のクラス
型に対する依存性で、これを排除しようとするモチベーションはJAVAが多重継承をサポ
ートしていないという点から湧いてる。
例えば、スレッドの実現にそのサブクラスである事を要求されたら？コールバックを実現
するのに特定のクラス型を要求されたら？インターフェイスを用いてクラス間の依存性を
排除するとはこういう事を指してる。

DIについても同じ視点から考察してみてほしい。教科書的な説明よりも、もう少し詳細な
視点で、DIが本当に排除してる依存性とは何なのかと、俺なりの視点については明日の
晩にでも書くつもりだけど、先ずは自分なりに考えてみてほしい。

890 ：デフォルトの名無しさん：2005/04/27(水) 05:05:20

>>881
コンパイル依存排除が目的っていうなら、それは無意味だ
拡張するためのアプリケーションで、拡張方法が明確に定義されているときのみ、
xmlでインスタンス化する対象を定義する意味があるのであって、
一般的なアプリケーションでわざわざxmlを書いてインスタンス化するもの
決める必要な無い。

>>889
Javaにインターフェースがある理由って、ハッキリ言わせてもらうと、型が合ってないと
コンパイルエラーで実行前に知らせてくれるっていう、それ以外にありえない。

インターフェース無くして、実行時にメソッドの有り無しのみでポリモーフィズム
やっても、問題は無いでしょ。
デメリットはコンパイルエラーが無くなってちょっとエラー発見が遅れることなのであって。

891 ：デフォルトの名無しさん：2005/04/27(水) 08:01:16

DIの議論はDIスレへ
http://pc8.2ch.net/test/read.cgi/tech/1099827125/

892 ：デフォルトの名無しさん：2005/04/27(水) 09:22:49

DIが排除する依存は、オブジェクト間の依存であってクラス間の依存は排除されない

893 ：デフォルトの名無しさん：2005/04/27(水) 11:02:17

Seasar無関係の話(例: DI, Interface, 初心者質問, その他信念表明等)は、
それぞれ別スレでやるべきですね。

894 ：デフォルトの名無しさん：2005/04/27(水) 11:10:36

DIはSeasarとは無関係です。
InterfaceはSeasarとは無関係です。
初心者はSeasarとは無関係です。
さすが、閉鎖的なことで定評のあるSeasarです。

895 ：デフォルトの名無しさん：2005/04/27(水) 12:17:08

スレ違いと誘導するよりも、進んでネタを振りましょうｗ

896 ：デフォルトの名無しさん：2005/04/27(水) 13:04:42

Seasarに関係したい奴が絡んでるだけか

897 ：デフォルトの名無しさん：2005/04/27(水) 13:53:59

郵政民営化とSeasarはもちろん関係があるし、意外と知られていないが後藤真希の胸がGカップまで巨大化した件は依存性の注入という点からみると非常に関係が深い。

898 ：デフォルトの名無しさん：2005/04/27(水) 14:53:25

(；・`д・´)　!? (`・д´・ (`・д´・；) な、なんだってー!?

899 ：デフォルトの名無しさん：2005/04/27(水) 15:30:51

注入！どひー

900 ：デフォルトの名無しさん：2005/04/27(水) 20:37:36

これだけは言わせてくれ
>>896
そういう無意味な煽りが、余計にウンチを産んでるのをいい加減分かれよ。それともおまいもアンチSeasar/DI？

で、>>890 >>インターフェースがある理由
理由はそうであれ、そこを原点にして様々なメリットが生まれてる。

あと、遅れるのは「ちょっと」どころではないぞ。規模が大きくなればなるほどね。
テスト段階でも発見できなくて、稼動後に発見なんて可能性も大いにある。これは大問題だ。

901 ：デフォルトの名無しさん：2005/04/27(水) 22:25:54

結論：EJB >>>>>>>>>>>> DI

902 ：デフォルトの名無しさん：2005/04/27(水) 22:40:38

動的型付けができないからインターフェースがあるですよ
EJB3は素敵ですよ
Seasar2はS2Daoが素敵ですがS2JSFはいうほどではありません。

903 ：デフォルトの名無しさん：2005/04/27(水) 22:41:46

インターフェイスなどどうでもいい。
ttp://220.111.244.199/otakara/idol/050427a1.jpg

904 ：デフォルトの名無しさん：2005/04/27(水) 22:43:49

-----------------------------------
　　チンパンジーのアイちゃんが
　　　　　　　　　書き込んでいます（はぁーと
　　　　　　　　　　　　　　　　　　　(霊長類研)
-----------------------------------

905 ：デフォルトの名無しさん：2005/04/28(木) 02:03:16

しかし、ジャバワールドのインタビューの写真、特集1日目のブタと3日目のクマに入れ替えても誰もきづくまい。

906 ：デフォルトの名無しさん：2005/05/02(月) 22:13:23

http://www.atmarkit.co.jp/fjava/rensai3/springdi01/springdi01_1.html

非常に分かり易くDIについて書かれてる。
これくらい噛み砕いてあると、非JAVA脳な人にはすんなり入ると思う。

907 ：デフォルトの名無しさん：2005/05/03(火) 07:53:38

おれは>>885の説明がわかりやすかった。ありがとう>>885

908 ：デフォルトの名無しさん：2005/05/03(火) 14:27:05

@ITってネタをベタにするメディアだからなぁ

局所化してデバッグしやすいとかいって、
DIのメリットとオブジェクト指向プログラミングのメリットを
すり替えしてんじゃん。
こんなネタに騙される奴なんか顔も見たくないよ。

909 ：デフォルトの名無しさん：2005/05/05(木) 22:48:43

>908
>局所化してデバッグしやすいとかいって、
>DIのメリットとオブジェクト指向プログラミングのメリットを
>すり替えしてんじゃん。

禿同。
最近そこんとこを勘違いしてる人が多いよね。

まあ、勘違いであろうがなかろうが、テスタビリティの高い(=高凝集で疎結合な)プログラムが作られることは大歓迎。

910 ：デフォルトの名無しさん：2005/05/05(木) 22:57:46

＞最近そこんとこを勘違いしてる人が多いよね

アンケートとったんかよ、わりゃ（激笑

911 ：デフォルトの名無しさん：2005/05/05(木) 23:49:06

>>910
周りがよっぽど優秀か、
それとも業務以外に興味がないかどちらかですね

912 ：デフォルトの名無しさん：2005/05/06(金) 00:13:44

不吉な匂いがするな。

はやくOO抜きでAOPできるようにならんと、
またOOの二の舞になる予感がする (判ってないのがデタラメを広める)

913 ：デフォルトの名無しさん：2005/05/06(金) 00:14:40

(俺って、なんで訳判んないレスにいちいち返答するんだろう・・・。)

914 ：デフォルトの名無しさん：2005/05/06(金) 00:28:06

あ～、今日も中身ねぇ～

915 ：デフォルトの名無しさん：2005/05/06(金) 11:42:57

>>912
OOの二の舞ってことは、すごく普及して当たり前になるってことか。

916 ：デフォルトの名無しさん：2005/06/02(木) 01:47:53

(・∀・)ﾊｲｰｷｮ

917 ：デフォルトの名無しさん：2005/06/02(木) 01:59:55

一ヶ月近く発言無しだったんだな。

まあ本家にもこれといった動きは無かったしな。

918 ：デフォルトの名無しさん：2005/06/02(木) 04:13:39

露出に一生懸命だね。

919 ：デフォルトの名無しさん：2005/06/02(木) 04:20:54

>>917
なんかいろいろあったみたいよ。なんかいいたそうだよ。
すなあそびとか決まったときにいろいろ人に言えない話が決まったんじゃないの？

920 ：デフォルトの名無しさん：2005/06/02(木) 08:49:01

>>918
ナニを露出したんだ？

921 ：デフォルトの名無しさん：2005/06/02(木) 19:49:51

そまつなもの。

922 ：デフォルトの名無しさん：2005/06/02(木) 21:59:14

ウホッ

923 ：デフォルトの名無しさん：2005/06/02(木) 22:40:44

男だらけのシーサープロジェクト、ぽろりもあるよ♥

924 ：デフォルトの名無しさん：2005/06/02(木) 23:12:58

925 ：デフォルトの名無しさん：2005/06/03(金) 03:25:40

ふと思ったけど、seasar.orgに載った雑誌・記事の一覧があると嬉しい。

926 ：デフォルトの名無しさん：2005/06/03(金) 04:17:47

こんな感じでどう？ (「リソース」からリンクあり)
http://www.seasar.org/publication.html

927 ：デフォルトの名無しさん：2005/06/03(金) 07:04:44

わ～いヽ（´ー｀）ノ
でもリソースからたどれねぇですよ。

928 ：デフォルトの名無しさん：2005/06/03(金) 07:06:54

あ、見れた。キャッシュしてたかな。

929 ：デフォルトの名無しさん：2005/06/03(金) 07:10:40

どうでもいいけど、JAVA PRESSとかWEB+DB PRESSは、全部大文字じゃね？

930 ：デフォルトの名無しさん：2005/06/04(土) 00:58:20

>>929
修正しますた

931 ：デフォルトの名無しさん：2005/06/04(土) 15:40:15

>>930
乙

932 ：デフォルトの名無しさん：2005/06/04(土) 21:16:53

下らない指摘だな

933 ：デフォルトの名無しさん：2005/06/04(土) 21:17:15

「電車男」ストーリーが実話であると勘違いしている人々のために
http://f41.aaa.livedoor.jp/~outerdat/faq.html
■電車男＝エルメス＝まとめサイトの管理人＝久保田康■すべて同一人物 ■久保田康の自作自演と判明■
電車男とエルメスの恋物語は４０歳の久保田康が一人でつくった嘘１００％の創作。

電車男＠ＦＡＱ
http://f41.aaa.livedoor.jp/~outerdat/faq.html
関連サイト
電車男の時刻表
http://subway.seesaa.net/
電車男＠全過去ログ
http://f41.aaa.livedoor.jp/~outerdat/
http://www.geocities.jp/outer797/
記帳所＠全過去ログ
http://www.geocities.jp/outer626/
電車男 - 2ch-Library
http://2ch-library.com/male/train/
見たこと聞いたこと: 電車男関連
http://sunrise-sunset.seesaa.net/category/75887.html
見たこと聞いたこと（退避版）
http://blog2.fc2.com/sunrisesunset/
「電車男」の「中の人」こと、久保田康40歳（今年3月19日で41歳）のご尊顔
http://white.jpg-gif.net/bbsx/18/img/115816.jpg
久保田康氏のサイト「記憶博物館」のミラー
http://www.geocities.jp/outer214/outer214.html

934 ：デフォルトの名無しさん：2005/06/11(土) 08:13:41

S2Container#getComponent(Object)はなぜ引数がObjectなのでしょう？
getComponent(Class)とgetComponent(String)のほうが自然な気がするのですが。

935 ：デフォルトの名無しさん：2005/06/12(日) 23:37:08

別に意味はないような気がする。気がするだけだが。

引数としてはどうせ定数かリテラルしか使わんだろうし、分けた時のメリットもデメリットも余り無いってのもあるかと。

936 ：デフォルトの名無しさん：2005/06/13(月) 23:47:17

ひがやすをさんを生で見てきた
結構好き

937 ：デフォルトの名無しさん：2005/06/13(月) 23:54:28

ISIDとか三井情報開発とか、結構よさげな会社だなぁ。
あんな所でマターリとオプソ開発したかったな

938 ：デフォルトの名無しさん：2005/06/13(月) 23:55:17

>>936
何かイベントがあったの？
それとも内輪のミーティング？

939 ：デフォルトの名無しさん：2005/06/14(火) 00:12:55

>>937
ISID（電通国際情報サービス）の評価は？
http://science3.2ch.net/test/read.cgi/infosys/994954074/l50

こんなスレもあるんで、会社ってより
個人の力量も相当あると思われます。

940 ：デフォルトの名無しさん：2005/06/14(火) 00:21:40

>>938
福岡のイベントなんジャマイカ？

941 ：デフォルトの名無しさん：2005/06/14(火) 00:43:36

S2Daoで

public class Foo {
public static final String TABLE = "foo_table";

// properties and accessors
}

public class Bar extends Foo {
public static final String TABLE = "bar_table";

// properties and accessors
}

public interface BarDao {
public static final Class BEAN = Bar.class;

public int addBar(Bar bar);
}

こんな感じの継承されたDtoクラスをBEANとしてBarDaoを定義した場合にTABLEが親クラス(Foo)の値を使ってしまう。

BeanDescImpl#setupField()でClass#getFields()が親クラスのTABLEフィールドも一緒に返してしまうのが原因だと思うけど。

小心者なのでMLじゃなくてスレに書いてみる。

942 ：デフォルトの名無しさん：2005/06/14(火) 00:52:36

エンティティクラスの考え方からして、
親と子でTABLEアノテーションが変わるのは
違和感があるけどなあ。

あーでも最近は継承テーブルとかいうのもあるんだよな。

943 ：デフォルトの名無しさん：2005/06/14(火) 06:56:25

>>938
福岡のJavaセミナー

944 ：デフォルトの名無しさん：2005/06/23(木) 14:35:44

ﾌﾚｰﾐﾝｸﾞｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

945 ：デフォルトの名無しさん：2005/06/23(木) 15:17:05

∑(ﾟДﾟ≡ﾟДﾟ)ﾄﾞｺ??

946 ：デフォルトの名無しさん：2005/06/23(木) 15:26:19

[Seasar-user:2241]付近

947 ：デフォルトの名無しさん：2005/06/23(木) 15:34:40

スレッド中13/26個のメッセージが同一人物とは、
随分な粘着っぷりだな（藁

948 ：デフォルトの名無しさん：2005/06/23(木) 15:40:01

ふと思ったんだが、PoolSizeMax=0でこけるのは当たり前、1を指定すべきなんじゃないかと

949 ：デフォルトの名無しさん：2005/06/23(木) 15:43:18

宮沢りえみたいな髪型のひごﾀﾝに、
漏れも叱られてみてぇ～

　じゃ、ずばり言うわよ　！！！

　（ﾄﾞｷﾄﾞｷﾄﾞｷﾄﾞｷ

950 ：デフォルトの名無しさん：2005/06/23(木) 15:46:00

>>948
同時接続数を１にしてどうすんねん

951 ：デフォルトの名無しさん：2005/06/23(木) 16:24:11

>>949
その話題には全然参加してないけど、自分に言われてるみたいで反省＿ノフ○

952 ：デフォルトの名無しさん：2005/06/23(木) 16:28:39

>>951
ｺﾚｶﾜｲｲ

＿ノフ○

953 ：デフォルトの名無しさん：2005/06/23(木) 16:38:43

なんだか、改めてみるとkくんに該当するひとばっかりだな

954 ：デフォルトの名無しさん：2005/06/23(木) 16:39:09

盛り上がってまいりました！ｗ

>>952
たしかに、＿ノフ○ なんかいい感じだな。

955 ：デフォルトの名無しさん：2005/06/23(木) 20:13:59

俺は断然Ｋを推すぜ！

956 ：デフォルトの名無しさん：2005/06/23(木) 20:15:51

まだ複数コミッタ制にして日が浅いせいか、ひがﾀｿの
影響力が強すぎる気がするな。

957 ：デフォルトの名無しさん：2005/06/23(木) 20:24:46

S2Axisあたりで、話題のｋ氏とエビちゃん大好きｋ氏の間で何かしっくり行ってない気はしてたんだよねぇ。

放っておけばおとなしくなると思ったのに、ひが氏出てきてかえってややこしくなったような。

958 ：デフォルトの名無しさん：2005/06/23(木) 21:06:22

人格攻撃だの価値観の押し付けだのはよくわかんないけど、
連続投稿って掲示板だけでなくML上でも結構うざいんだってことはよく分かった。

それよりも、ｋ氏の親分とひがﾀﾝの関係がまずくなったりしないかな？と余計な心配をしてみる。

959 ：デフォルトの名無しさん：2005/06/23(木) 21:07:57

Ｋがいっぱいいるw

(1)ただいまブレイク中のイチャモンＫ
(2)モデル・アイドル大好きオタクＫ
(3)理事か何かのとてもエライＫ

で(2)が(1)や(3)と意見がぶつかり気味。

コミッタ複数いて表面的には民主主義的だけど、
実際にはひがﾀｿとモデルおたくＫの思想・哲学に
かなり引っ張られている。もちろん彼らは優秀だと
思うけど。

960 ：デフォルトの名無しさん：2005/06/23(木) 21:22:05

(4)最近結婚したk
(5)hibernateのk
(6)mﾀｿのk
(7)読書会のk
(8).NETのk
(9)RMIのk

だいたいHとKでまわってるな。

961 ：959：2005/06/23(木) 21:33:30

そういえば俺もＫだわ

962 ：デフォルトの名無しさん：2005/06/23(木) 22:04:02

うちは爺ちゃんがＫだ

963 ：デフォルトの名無しさん：2005/06/23(木) 22:07:53

(10)phpのk
(11)mavenのk
(12)seasar wikiのk

964 ：デフォルトの名無しさん：2005/06/23(木) 22:18:29

>960
Kしかいないぞ

965 ：デフォルトの名無しさん：2005/06/23(木) 22:21:59

>>964
(1)中心人物のh
(2)アニオタh
(3)アニオタ部下h

966 ：デフォルトの名無しさん：2005/06/23(木) 22:27:01

(3)がわからん

967 ：デフォルトの名無しさん：2005/06/23(木) 22:28:33

て言うか、オタはこっそりやれｗ

968 ：デフォルトの名無しさん：2005/06/23(木) 22:29:17

Seasar法人の理事じゃないの？

969 ：デフォルトの名無しさん：2005/06/23(木) 22:33:22

>>966
元sourceforgeうp担当かな？
今は(2)の部下じゃなくなったはずだが…

970 ：デフォルトの名無しさん：2005/06/23(木) 22:35:24

理事ってKHHだろ

971 ：デフォルトの名無しさん：2005/06/23(木) 22:36:34

オタ理事Hいらね
コード書かない奴はクソ

972 ：デフォルトの名無しさん：2005/06/23(木) 22:39:37

苗字の頭文字で統一ｼﾙ！

973 ：デフォルトの名無しさん：2005/06/23(木) 22:41:25

ほんとに技術ネタの出ないスレだなｗ

974 ：デフォルトの名無しさん：2005/06/23(木) 22:42:37

たぶん(3)は取締役社長のＫ氏だね。

ttp://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20041120/152861/

975 ：デフォルトの名無しさん：2005/06/23(木) 22:50:09

>>974
kの(3)はすぐわかるからhの(3)の話じゃね？

976 ：デフォルトの名無しさん：2005/06/23(木) 23:37:34

>>971
ばかぃやるぉう！
HBたんは殺伐としがちなSeasarプロジェクトのの「和み」担当じゃないかｯ！

977 ：デフォルトの名無しさん：2005/06/23(木) 23:52:35

殺伐(1) Seasar-user:1059～ k(1)とk(2)
殺伐(2) Seasar-user:2050～ k(2)とk(3)
殺伐(3) Seasar-user:2215～ k(1)とk(2)とh(1)
全てk(2)絡みw

978 ：デフォルトの名無しさん：2005/06/24(金) 00:02:35

デブオタが出来るのは和みだけか（藁

979 ：デフォルトの名無しさん：2005/06/24(金) 02:01:56

今回の殺伐(3)を読み返すと、k(1)k(2)が技術的なやりとりをしててk(1)が名前の付け方にぽろっとちゃちゃいれたところを、h(1)が横槍いれて勝手に切れただけに見える。

980 ：デフォルトの名無しさん：2005/06/24(金) 02:13:45

>>978
豚の餌ほどの役にも立たないおまいより全然ましw

981 ：デフォルトの名無しさん：2005/06/24(金) 03:59:18

>>980
四国乙

982 ：デフォルトの名無しさん：2005/06/24(金) 04:04:49

k(2)は、位置付けかんがえると(1)にしたほうがよかったのではなかろうか。
ってか、k(1)だと名前どおりになる。

983 ：デフォルトの名無しさん：2005/06/24(金) 08:40:30

じゃあぷちバトル発生順に

人物(1) モデル・アイドル大好きオタクＫ
人物(2) 代表取締役社長のとてもエライＫ
人物(3) ただいまブレイク中のイチャモンＫ

殺伐(1) Seasar-user:1059～ k(1)とk(3)
殺伐(2) Seasar-user:2050～ k(1)とk(2)
殺伐(3) Seasar-user:2215～ k(1)とk(3)とh(1)

全てk(1)絡みw

という感じ？

984 ：デフォルトの名無しさん：2005/06/24(金) 09:45:54

k(1)は、扱ってる範囲が広いのと、作ってるのがS2と何かをつなぐブローカーだからバトりやすいってのがあるんじゃないかな。

985 ：デフォルトの名無しさん：2005/06/24(金) 12:04:18

発生順ならk(2)とk(3)が逆、殺伐としたやりとりは他にもあったので追加するとこうなる

k(1) モデル・アイドル大好きオタクＫ
k(2) ただいまブレイク中のイチャモンＫ
k(3) 代表取締役社長のとてもエライＫ
h(1) 中心人物のh

殺伐(1) Seasar-user:1059～ k(1)とk(2)
殺伐(2) Seasar-user:1792～ k(1)とk(2)
殺伐(3) Seasar-user:2050～ k(1)とk(3)
殺伐(4) Seasar-user:2215～ k(1)とk(2)とh(1)

全てk(1)絡みw

986 ：デフォルトの名無しさん：2005/06/24(金) 12:32:31

ヲチスレ化してるな

987 ：デフォルトの名無しさん：2005/06/24(金) 12:40:51

漏れはk(1)のほうを応援する
k(2)やk(3)は押し付けがましい

988 ：デフォルトの名無しさん：2005/06/24(金) 13:13:24

漏れはk(2)だな
k(3)は社長だからたっぷり稼いでる
k(1)もブランド漁るくらい稼いでる
k(2)くらいしか応援できん

989 ：デフォルトの名無しさん：2005/06/24(金) 13:42:28

それではオレは、k(13)seasarに無関係なk を応援する

990 ：デフォルトの名無しさん：2005/06/24(金) 15:15:22

ではオレはk(14)seasarに恋してるk を応援する

991 ：デフォルトの名無しさん：2005/06/24(金) 15:35:57

そしてオレはk(15)seasarをシーソーだと思ってたk だ。

992 ：デフォルトの名無しさん：2005/06/24(金) 19:24:40

新スレ立てたぞ。

国産DIコンテナSeasarとくーすその４
http://pc8.2ch.net/test/read.cgi/tech/1119608621/

993 ：デフォルトの名無しさん：2005/06/24(金) 19:44:08

k(2)って毎回パターンが同じなんだよな。

「○○は俺の考えたようには（動かない、だから俺はこのようにソース変更して使っている」

　その使い方に問題がある可能性は微塵も考えないんだろうか。