国産DIコンテナSeasarとくーす その３
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
NGNGってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 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/
0002デフォルトの名無しさん
NGNGスレ立て乙。
このへんも関連スレかな。
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
0003デフォルトの名無しさん
NGNG>960 名前：デフォルトの名無しさん [sage] ：2004/12/12(日) 18:38:39
>>>957
>むしろ、くーすは上流工程に責務を集中させるから、XP 等に比べて
>その部分の取替え可能性に関するリスクが高い、という見方もあると思うが。
XPについては、俺に仕事くれてる人が採用したがってるんで検討してみたんだけど、
検討してみた結果、この手法は実装フェーズ以降にしか使えないと思った。
というのは、XPでストーリーをタスクに分割する前に、まずはシステム全体のアーキテクチャ、
つまりシステムを何層に分割するのかとか、例外の扱いはどうするのかとか、ログはどうとるのか
とか、全体に及ぶような設計を先にして「今回はこういうルールでやってください」って言っとかないと、
なんだか訳の分からない実装の集合体ができそうに思う。まったく統一感がなくてメンテナンスが
しにくい。
だから、XPでもやっぱり上流行程って必要なんじゃないかな。
で思ったのだが、 くーすの流れで言うところの、ロバストネス解析あたりまでを設計チームでやり
こんで、シーケンス図を書くあたりからXPの手法を導入ってしたら案外うまくいくんじゃないだろう
か。業務フロー図一枚くらいをストーリーにして、あとはタスクに分割して実装していくって感じで。
0004デフォルトの名無しさん
NGNG0005デフォルトの名無しさん
NGNG> だから、XPでもやっぱり上流行程って必要なんじゃないかな。
「アジャイルと規律」を読め。その問題が詳細に検討されてるから。
# 関係ないが、DIスレの213-214ゴールデンコンビを思い出す…。
0006デフォルトの名無しさん
NGNGFDDでいいじゃん。
0007デフォルトの名無しさん
NGNG0008デフォルトの名無しさん
NGNG0009デフォルトの名無しさん
NGNG0010デフォルトの名無しさん
NGNG0011デフォルトの名無しさん
NGNG0012デフォルトの名無しさん
NGNG0013デフォルトの名無しさん
NGNG0014デフォルトの名無しさん
NGNG僕も欲しいし、賛同者>>934さんもいるみたいなので、
ちょっとコード書いてMLに流してみます。
0015デフォルトの名無しさん
NGNG> update文で「このフィールドひとつだけ更新したい」ってときにもSQL文を書かなくてすむ。
これってむしろS2Dao側で属性ごとにダーティーチェックして対応してくれるのが
正しい気がするんだが。現状のS2Daoってそういうことやってないの?
教えて君でスマソ。
0016デフォルトの名無しさん
NGNGフラグをオンにしたいだけなんだよ」とかいうときに、いちいちSQLファイル作って、
ARGSアノテーション書いてってのが邪魔臭い。
別に対した手間じゃないんだろうけど、でも全カラム一斉UPDATEがわずか一行で
定義出来るのに、それより短いSQL文のためにSQLファイルをつくんのかよ....orz
という気分になってしまう。
0017デフォルトの名無しさん
NGNGもしかして１項目変更するのが全項目変更するより簡単な処理だと思ってるの？
0018デフォルトの名無しさん
NGNG>>17
確かにクエリを組み立てる側の制御は組み立てるクエリの長さで決まるわけじゃないからねえ。
だから、ARGSアノテーションとかが必要になるんだと思うんだけど。
16は仕組みをあまり分からず書いているのかもしれないけど、
そういうユーザーの要望の中から対応すべき要望を抽出して対応することによって
ツールとかは熟成されていくんだと思うよ。
くだらなくても要望出さなかったら作者の必要な機能ばかりのツールになってしまうからね。
0019デフォルトの名無しさん
NGNG0020デフォルトの名無しさん
NGNG自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？
まぁ、いちいち噛み付かずに
>>17さんの言う通り、
ちょっとづつでも要望出してちょっとづつでも良いツールになっていってもらおうよ。
僕は一応、ソースのどの辺いじればよいのか調べています。
0021デフォルトの名無しさん
NGNG>>>16の「大した手間じゃない」はS2側の内部処理ではなくて、
>自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？
そうです。
短いSQLのためにSQLファイルを作るのが面倒だという話です。
S2Daoは「UPDATE テーブル SET PK以外のカラム全部 WHERE PK」ってなSQLを自動生成
してくれるけど、「PK以外のカラム全部」を特定のカラムだけにするのにSQLファイルを書く
のがね。
SQLを一行書いたファイルを作るだけなんだけど、「PK以外のカラム全部」のカラムが２０個
だったりしても長いSQLが自動生成できるのと比べてしまうと、たった一つのカラムのために
SQLファイルを書くのが面倒に感じまして。
0022デフォルトの名無しさん
NGNGだって。よかったじゃん。
tp://d.hatena.ne.jp/higayasuo/20041215
002315
NGNGこういうところもS2が好きな理由です。
002515
NGNG002614
NGNG0028デフォルトの名無しさん
NGNG0029デフォルトの名無しさん
NGNGお礼がズラズラと並んでる図は信者臭くてダサいし
0030デフォルトの名無しさん
NGNG0031デフォルトの名無しさん
NGNG0032デフォルトの名無しさん
NGNG0033デフォルトの名無しさん
NGNG0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNG0036デフォルトの名無しさん
NGNG早く、事例集を作らないかなあ。
実績がはっきりしてナイト採用しないところもあると思うんだけどねぇ。
0037デフォルトの名無しさん
NGNGネタに騙されてるよ
0038デフォルトの名無しさん
NGNGネタ？
MLでの導入事例集作成のやり取りのことですか？
0039デフォルトの名無しさん
NGNGつーかおれ、未だにAOPの使い方がよくわかんね。コンテナ機能だけでも便利だからいいけどさ。 orz
0040デフォルトの名無しさん
NGNG0041デフォルトの名無しさん
NGNGモックオブジェクト使えないし、デリゲートも自動でできないんだぞ。だめじゃん。
0042デフォルトの名無しさん
NGNGとりあえず、ドキュメントどおりにdiconファイルに記述すればOK
0043デフォルトの名無しさん
NGNG考えながら付属のやつを使ってりゃそのうちinterceptorを自作するようになるさ。
0044デフォルトの名無しさん
NGNG> SQLを自動生成したり、Beanからバインド変数を組み立てたりという仕事は、
> これまで、BeanMetaDataにさせてました。データのことを最も知ってるクラスに
> 振る舞いを持たせるのは、自然なことだと思っていたためです。
>
> しかし、S2Daoに仕様の追加があるたびに、BeanMetaDataに変更が入るのです。
> メタ情報は全く変更されていないのにもかかわらず。
SQLの自動生成ロジックの変更によって、メタ情報に変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?
バインド変数組み立てロジックの変更によって、メタ情報の変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?
どちらも何の問題もないように思いますが。
0045デフォルトの名無しさん
NGNG> SQLを自動生成したり、Beanからバインド変数を組み立てたり
> という役割は、メタデータを管理するというBeanMetaDataの
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。
それは単に責務の割り当て方が適当でなかったために
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。
と感じるのだと思いますが。
例えば
BeanSchema.toXML
のようなメソッドはBeanMetaDataクラスに持たせるべき責務のように
思えます。
0046デフォルトの名無しさん
NGNG> モデリングするという考えは、重要ながらかなり見落とされている
> ことが多いのではないでしょうか。
よくわからないので、
具体的な例を挙げていただけませんか?
0047デフォルトの名無しさん
NGNGメソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
べきだった、という話じゃないの？
で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。
その点についてはおれは反対する要素はないぞ。
0048デフォルトの名無しさん
NGNG> SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
> メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
> べきだった、という話じゃないの？
>
> で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
> するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。
うんにゃ、
ひがさんは BeanMetaDataには振る舞いを持たせるべきではない、と言っているよ。
0049デフォルトの名無しさん
NGNGここではなくてblogのコメントに書いていただけませんか？
0050デフォルトの名無しさん
NGNG> 1つのクラスに複数の役割を持たせることになります。
なりません。
データは何一つサービスを提供しません。
よって、データは責務を持ちません。
0051デフォルトの名無しさん
NGNGS2Daoのソース読んだわけじゃないから詳しいことは分からんが、
少なくとも>>45には激しく同意。
Object指向としての理想的なモデリングは、SwingとかEclipseなんかが
参考になるとは思うんだが、その中にデータを表すってだけの
構造体みたいなクラスは見当たらんよね。ま、ドメインが違うじゃんって
いわれればそれまでだけど。
くーすはどうも退化としか思えないんだよね。
目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
柔軟性や多態性なんかが損なわれてる気がする。
0053デフォルトの名無しさん
NGNG目先のお手軽さや便利さを求めちゃ何故まずいんだろう？
それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。
オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。
お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの？
0055デフォルトの名無しさん
NGNG> くーすはどうも退化としか思えないんだよね。
> 目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
> 柔軟性や多態性なんかが損なわれてる気がする。
同感です。
結局は、前々スレの686の一言につきると思う。
>686
> くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
> (予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
> 決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
> Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
> カバー、的な。
0056デフォルトの名無しさん
NGNGそのBlogに対する書き込みをニヤニヤして読んでると思われ。
必死で書き込んでる奴らは
ヒガ氏の掌で踊らされているだけだということを
自覚したほうがいいな（藁
0057デフォルトの名無しさん
NGNG>>54
> >>49
> そんな度胸ありません！
そのとおりですw
0058デフォルトの名無しさん
NGNGみなさんはいい部下をお持ちのようですね。
うちは素人だらけなので後ろ向きな方法論で結果を出すしかありません。
しかも、各自で技術力を向上させようとする前向きさも、センスもない連中が山ほどいます。まじで皆さんがうらやましいです。
0060デフォルトの名無しさん
NGNG> >>51
> 目先のお手軽さや便利さを求めちゃ何故まずいんだろう？
>
> それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。
>
> オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。
>
> お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの？
それについては否定はしないけど、それはビジネスの話。
技術者ならくーすの技術面について話をしようぜ。
0061デフォルトの名無しさん
NGNG技術者よりの話題だと思うんだが。
まあみんな分かってるとは思うけど、くーすでいっていることは、すげえ新しいことでは
なくて、いままでビジネスの世界で生きてきた人が経験として得てきた知識と言うかノウハウ
（ともかくこの低スキルどもにコーディングをさせてこの仕事仕上げないといけないんだよ！、
とかいうやつ）だよな。それを手続きとしてまとめたもんだ。
で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
づけしたもんなんだし。
0062デフォルトの名無しさん
NGNG現場の事情で、その対価としてOOP的な「柔軟性や多態性なんかは損なわれて
いる」という結論でいいんですか？本当に？
アホでも素人でも妄想でも語れる現場話にしたい人は置いとくとして、エンジニア
の人達はこの結論でいいの？本当に？
006344
NGNG>で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
>呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
>づけしたもんなんだし。
それ自体は否定しないし、これらをまとめあげようとするひがさんは偉大だと思う。
ただ、的外れな指摘で「レガシーなオブジェクト指向」とかいうのはやめて欲しい。すごく迷惑。
0064デフォルトの名無しさん
NGNGヒガ氏の提唱しているのはビジネス的な視点での方法論で、
ここで書き込んでる人たちはビジネス的は視点としては理解はできるものの
技術的な視点で話をしたいと。
それじゃ、話が合うわけねーじゃん。
つーか、なんでそんな人たちがヒガ氏やらくーすやらに興味持ってるのかさっぱりわからん。
0065デフォルトの名無しさん
NGNGくーすの技術面？
くーす語るんだったら技術面じゃなくて
ビジネスでの有効性だとかそういう話じゃないの？
0066デフォルトの名無しさん
NGNG技術的に語れる人間はこのスレには居ないって事だ。
それはそれで構わないと思う。そこは所詮２ちゃんだし？
重要なのは、このスレがヒガ氏へのＱとして機能し得るか否かって事だ。
何が言いたいかって言うと
ヒガ様、手隙の時で構いませんので、その辺をBLOGの方で技術的に解説よろ
って事だｗ
006744
NGNG> 要するに、
> ヒガ氏の提唱しているのはビジネス的な視点での方法論で、
くーすの言う、DTOとかStatelessBusinessロジックはビジネスの話だと。
はあ、そうですか。
って、んなわけねーだろ。
0068デフォルトの名無しさん
NGNGいや、ひがさんの日記は、BeanMetaDataに振る舞いを「もたせるべきではない」という
話ではないだろ。BeanMetaDataはメタデータの管理（に直結した振る舞い）だけをすべき
だったのに、SQL自動生成とか関係ない振る舞いを持たせてしまった、という話だろ。
振る舞いとデータを分離するといってるんじゃなくて、「データにやまほど振る舞いをつけた
くなったとき、その振る舞いがデータと直結してるかどうかちょっと考えてみろ」っていって
るんだと思うけど。
まあ俺が思うのは、データに直結してないけど、そのデータを利用する機能を山ほど搭載
したFatなクラス設計（モデリング？）というは、「レガシー」なんではなくて、そんなものは
始めからオブジェクト指向の原則に反してるだろ、ということだな。
それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
かなり微妙だし、俺も正直言って間違うよ。
データと振る舞いをまとめるときに、「データと直結した振る舞いを持たせる」「データをつかった
ほげほげは別にする」というのはオブジェクト指向的には正しい判断じゃないか？
0069デフォルトの名無しさん
NGNGああ、それ自体は技術の話題だ。
でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。
0070デフォルトの名無しさん
NGNG> >>67
> ああ、それ自体は技術の話題だ。
> でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
> 技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。
もしそうっだったとしたら、なぜひがさんは
従来のオブジェクト指向を「レガシー」と言って技術的に批判するの?
0071デフォルトの名無しさん
NGNGここでレガシーと言われているものって、レガシーなんじゃなくて、そんなのはもともとオブジェクト指向的に
間違ってるんだし。
0072５１
NGNGいや、別にくーすに従わなきゃS2使ってバリバリにOOPなシステム作ることは
可能なわけよ。だからひが氏の実装自体には問題ない。むしろ素晴らしいと思うよ。
問題なのはくーすだよ。ただ、心配してるだけなんだけどね。
マジョリティとしての技術の方向性っちゅーのかな。それがこの先どうなっちゃうのか、とか、
くーすによってさらに加速されるであろう量産型低スキルエンジニア達の増産とか、
そいつらと一緒に、これからも仕事していかなきゃならない自分の身の振り方とかを。
ビジネス的にはそれでいいだろうけどさ、長期的に見て、まず「人」は育たないよな。
だから前々スレ686の一言に尽きるって結論になっちゃうんだけど。
ま、「レガシー」って言っちゃったのは失言でしたってこった。
どれだけ多くの人たちがあなたのBlogをチェックしてんのか忘れないでね。>>ひが氏
0073デフォルトの名無しさん
NGNGいけないんですか」とか聞く奴が毎年量産されていることを考えると、そいつらと一緒に仕事
していく手法を身につけとかないといけないってのは切実な問題かもしれん。
だって毎年量産されるんだし...
0074デフォルトの名無しさん
NGNGいろいろ覚えることあって大変だ。何がどういう役割を持っていてどう扱うのが正しいのか、
原作者にしか分からない理論（しかも、漏れ的には相当あやしい）を理解するのに何年かかるんだ。
そして覚えてそれで一体何になるのか。謎は深まる。
0075デフォルトの名無しさん
NGNG0076デフォルトの名無しさん
NGNG将来の客と現場に対する思考を停止するためのエクスキューズ用語。
0077デフォルトの名無しさん
NGNG0078デフォルトの名無しさん
NGNG示して難解フレームワーク固有の知識で壁を構築するっていうのは、
よく見かける手ではあるけどね。
シンプルな解決法は他にいくらでもあるのに。
本当にいいものは分かってもらおうという迫力が文章やコードで示されてる
のだけど、Seasarは・・・、まぁ、しょうがないな。
0079デフォルトの名無しさん
NGNGなんか凄い自信家ですねｗ
＞＞それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
＞＞かなり微妙だし、俺も正直言って間違うよ。
この辺に自惚れさが見え隠れしているように感じられるのは気のせいでしょうか？
0080デフォルトの名無しさん
NGNGそうだな。Strutsよりはマシかもしれん。
Strutsも大いなるネタの代表例でさ、あれよりいいってうのは、
果たして。大差は無いように思う。
0081デフォルトの名無しさん
NGNGくーすはWeb開発ノウハウの集合体であって、別に独自のフレームワークや固有の知識だと
思った事ないんだが。むしろ「あーたしかにそんな感じでやってるよ」ってくらいで。
逆にその「まとめよう」というところに価値があると思ってる。
0082デフォルトの名無しさん
NGNGみんな比嘉さんにもてあそばれてるなあ。
しかし、「レガシー」って括られるとそりゃ頭にきますよね。
みんな最先端を走ってるつもりなんですからねえ。
そう書けばここで盛り上がるのわかって書いてるのに
予想通りの盛り上がりを見せてるのはちょっと笑えるね。
しかし、Blogで２ちゃんのスレに煽りを入れて、
こんなにたくさんの人が踊らされるなんて、さすが比嘉さん。
0083デフォルトの名無しさん
NGNGDIスレの213=332と同様。厨がいたほうが一見盛り上がってるように見える罠。
0084デフォルトの名無しさん
NGNGそうか。やっぱり、ネタだったのか。
くそー、悔しい。
まぁ、そりゃそうか。
でも、本当にイカンのはマジなトーンで
DIコンテナORマッピングAOPとか言ってるやつらだぞ。
思わず反応してしまう・・・
0085デフォルトの名無しさん
NGNGもし本気でレガシーって思って書いてたら、S2自体の価値が疑われかねないので、
調子のって突っ走ってしまったと思いたいね。
まあ一方で、データと振る舞いの組み合わせ方は微妙な判断が必要な問題だ
と思う。その判断を卒業したてのＰＧに任せたくはないが、やらせないと低能の
ままの奴と付き合い続けなければいけないというジレンマに...
0086デフォルトの名無しさん
NGNGほんとにもてあそんぶためのネタとしてレガシーなんて言ったんだとしたら、S2に対する指示を
失いかねないネタだと思うぞ。
おれは勢い余ったんだと思うけどね。
0087デフォルトの名無しさん
NGNG0088デフォルトの名無しさん
NGNG☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ ﾋｶﾞﾀｿ消火まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
DIスレをリスペクトして「ﾃｨﾝ」だ。
0089デフォルトの名無しさん
NGNG0090デフォルトの名無しさん
NGNGEJBが実は最も壮大なネタで、
それよりマシなものなら「漏れにも作れる！」
と思う香具師、たくさんいるんじゃないかね。
しかし、EJBよりマシなものできたところで、
EJB自体がネタだから、どっちにしろネタなのだ。
0091デフォルトの名無しさん
NGNGメジャーな手法を使うのは当然だよな。
0092デフォルトの名無しさん
NGNG0093デフォルトの名無しさん
NGNG0094デフォルトの名無しさん
NGNGレガシーっていってるのは、1つのクラスが役割を複数持ってる
ような設計のことでしょう。
これまでのオブジェクト指向がすべてレガシーっていってるわけじゃない。
ナイーブって言い方に変わってるね。
0095デフォルトの名無しさん
NGNG正直どう思ってるんだろう。S2Struts使うとStrutsConfとダイコンも
書かなきゃいけないし。
特に全体を追おうとするときって、目茶目茶だるい。EclipseでCtrl+クラス
で実装開いてくれるけど、インターフェース使ってると
インターフェース開くから、ダイコン見て実態クラス見てって。。。
書いてる本人は分かるから良いんだろうけどさ。
あと、お客に技術トランスファーしなきゃいけないのに
Seaser使っちゃって（一緒にやってる人がね）、おいおい
お客さん（IT企業じゃないないシステム課の人）
に分かるように説明できるのーって感じ。
やっぱりね、Seaserに限った事じゃないけど楽になるだろうって思って
使うのは、全体的に見て楽になるかを見ないといかんね。
0096デフォルトの名無しさん
NGNG＞＞この「ナイーブ」は当然 (？) without EJB のアレ (笑) です．幼稚・稚拙というニュアンス．
だそうですから。
0097デフォルトの名無しさん
NGNG対して技術的に難しい概念ってことはないと思うが。
009895
NGNG>技術的に難しい概念ってことはないと思うが。
OOで一回でも作った事がある人は難しいとは思わんとだろうけど
お客はそうじゃないし。
DBAがプログラム中にSQLがあるのとO/Rマッパ使ってるときとで
インパクトが違うのとにてるんでないかなーと。
0099デフォルトの名無しさん
NGNG実装を意識する必要はないというやり方ですからね。
気にするのは、インターフェースであり実装ではない。
実装はブラックボックスで良いと思う。
0101デフォルトの名無しさん
NGNGプロジェクトで役割を明確にしろよ。
みんながみんな実装のロジック見るわけじゃないだろ。
なんのためのインターフェースだと思ってる？
てか、Saesarをどうのこうの言う以前にOO開発できないでしょ。
そんな考え方じゃ。
0102デフォルトの名無しさん
NGNG0103デフォルトの名無しさん
NGNGちゃんと設計しろよｗ
0104デフォルトの名無しさん
NGNG0105デフォルトの名無しさん
NGNG基本を教えてください。
0106デフォルトの名無しさん
NGNG基本？
それってあんたのMY RULEのこと？
0107デフォルトの名無しさん
NGNGそうですか。
0108デフォルトの名無しさん
NGNGそうですよ。
傍観者は書き込まないでください。
0109デフォルトの名無しさん
NGNG「interface開く ～ interfaceのタイプ階層を見て実装クラスを開く」
って2段階になるのがうざいよね。
IDE側に、interface名にカーソルあわせて「実装クラスを開く」
みたいな機能が欲しくなる時がある。実装クラスが一つの場合は
そのまま実装クラスのソースを開き、複数ある場合はドロップダウンで
選択とか。
0110デフォルトの名無しさん
NGNGS2Daoが返す、テーブルに対応したBeanとか）にいっさい振る舞いを持たせなくて、
setterとgetter以外あってはいけないとか思ってる人が多いのか。
そりゃ貧血症どころか構造体にすぎんじゃないか。
おれはモデルにほとんど機能は実装しないが、それでもそのモデルに直接関わる機能
（モデル内のインスタンス・フィールドだけで処理が片付いてしまうようなもの）はモデルに
実装するぞ。複数のモデルが絡んでくるようなものはサービスにまわす。貧血症ぎみの
クラスは多いが、それでも構造体よりはましだと思う。
0111デフォルトの名無しさん
NGNG前スレの後半で俺も似たようなこと言ったんだけど、
構造体として使うのがくーすらしいよ。
つーかドメインオブジェクトが何かって事をそもそも理解されてないようだから、
このスレの"ナイーブOO指向好き"と論点が噛み合わないんだよな。
複数業務にまたがるロジックがあるからこそドメインオブジェクトが存在してるんだろうに。
あれだけ、でかでかともっともらしいことを書くんなら、せめてもうちょっと
OOについての理解を深めてからにしてもらいたい>>比嘉氏
0112デフォルトの名無しさん
NGNGそうですか。
0113デフォルトの名無しさん
NGNGttp://d.hatena.ne.jp/higayasuo/20040801#1091337811
> OOPの良さは分かったけど、OOA,OODってよくわからんと思ってました。
> プログラミングのスタイルも我流で、適当にクラスを作っていただけです。
> 心がけていたのは、メソッド全体を一度に画面で確認できるくらい
> 小さいものにすることだけ。
0114デフォルトの名無しさん
NGNG0115デフォルトの名無しさん
NGNGほれ
http://eclipsewiki.net/eclipse/?Implementors%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3
0116デフォルトの名無しさん
NGNG自分で勝手に育っていく奴以外はほっとけ。
そんなことに金かけてる時代じゃねーんだよ。
ま、あんまりたくさん育っても任せる仕事がとってこれないから
くーすみたいなのでできない奴をうまく使いつつ、
勝手に育った奴に仕事任せていけばいいんじゃない？
育たない奴はいつまでもプログラマ。か、別の業種で頑張ればいいんじゃないか？
一般的な会社組織ってピラミッド型になってて、
成長していくとピラミッドがでかくなってしまうよね？
でもピラミッドの上方（高給取り）の比率を高くしないように
ピラミッドの形を維持していかなければならないから、
実はみんなに育たれちゃうと困るんだよね。
（全体の人件費を抑えざるを得なくなってしまうから）
日本の高齢化社会の年齢構成みたいに高給の人間の比率が多い組織になると
収益率を上げていくのは大変だからね。
0117デフォルトの名無しさん
NGNG0118デフォルトの名無しさん
NGNGデータアクセス層を純粋にデータアクセスだけに特化させることはＯＫな感じもする。
つまりDBからデータを取ってくる以外のロジックは存在しないただのBeanって感じで。
0119デフォルトの名無しさん
NGNG0120デフォルトの名無しさん
NGNG熟成とは縁のないファストフード作りのマニュアルじゃん。
0121デフォルトの名無しさん
NGNG> 問題は、ドメインオブジェクトに業務ロジックを追加するのが、
> ナイーブかどうかということです。
>
> 私の経験からするとドメインオブジェクトが複数の業務で
> 使われるということは良くある話です。
> 複数の業務の業務ロジックを1つのドメインオブジェクトに
> 持たせるということは、単一責任の原則に違反しています。
> クラスを変更する理由が複数あるためです。
複数の業務の業務ロジックをドメインオブジェクトへ
持たせたとしても、単一責任の原則には違反しません。
「業務Aの機能と業務Bの機能をドメインオブジェクトDへ持たせている」
と考えると単一責任の原則に反しているように見えますが、
「ドメインオブジェクトDの機能を使って、業務Aの機能と業務Bの機能を実現している」
と考えれば、Dの変更理由は常にひとつです。
よって、
> 問題は、ドメインオブジェクトに業務ロジックを追加するのが、
> ナイーブかどうかということです。
は「ナイーブではありません」が結論。
# ちなみに「単一責任の原則」はアジャイルソフトウェア開発の奥義に
# 載ってます。いい本ですよ。
0122121=44
NGNGくーすのネーミングの理由を聞かれたakonが
> 車輪の再発明ではなく、昔の道具でも使い方しだいで対応できるという心をこめてのネーミングです。
って言ってることですし、手続き型上等、TransactionScriptマンセーと開き直ればいーじゃない。
0123デフォルトの名無しさん
NGNG0124デフォルトの名無しさん
NGNG>人が育たないって主張に対するレスポンスがないな
くーすは人を成長させるとことにフォーカスしてないからしょうがないよ。
人を成長させるってことなら、XPが一番だな。とくにペアプロが効果大。
0125デフォルトの名無しさん
NGNGそれは設計によるだろ。
0126デフォルトの名無しさん
NGNG俺はそこがいやで転職したわけだが。
0127デフォルトの名無しさん
NGNGくーすやSeasarを使おうが使うまいが、
力のない会社にプロジェクトは失敗はついて回るでしょうし、
くーすやSeasarを使おうが使うまいが、
力ののある会社はそつなくプロジェクトを成功させるでしょうね。
012895
NGNGあー、開発段階の話じゃないのよ。
納品して、お客さんがちょっとカスタマイズしたいって場合ね。
もちろんサポート外になるのは、こっちもお客も同意済み。
>>115
さんきゅー
012944
NGNG> 私がいっているのは、データと振る舞いをカプセル化するという
> 考えは、オブジェクト指向の重要なポイントですが、単純に
> データに振る舞いを追加するのではなく、そこに、クラスは
> 1つの役割だけを担うようにするという視点を必ず持つように
> しましょうということです。
これは分かるのですが、これを理由に
>役割ごとにクラスを分割するという観点で考えると、
>
> * 永続化されるデータを管理するクラス
> * データベースにアクセスするクラス
> * 業務ロジックを扱うクラス
> に別れるというのは、理にかなったことだということが
> 分かると思います。
という結論が導き出される理由が分かりません。
「データを管理」や「業務ロジックを扱う」などはクラスの役割とするには低レベルすぎますし、曖昧にすぎます。
以下はjunitのjavadocから抜き出したものですが、
-TestResult
A TestResult collects the results of executing a test case.
-TestSuite
A TestSuite is a Composite of Tests.
役割というのは上記のような粒度のものであって、データの管理や業務ロジックを扱う、などはその内に含まれるものです。それ単体で役割として考えるべきものではありません。
013044
NGNGよく分析麻痺、設計麻痺に陥ってるプロジェクトがあるけど
そういうプロジェクトにはくーすの割り切りの良さはスゴク効果的だと思うな。
0131デフォルトの名無しさん
NGNGその論理が成り立つなら、どんなクラスでも単一責任の原則に
違反することはない罠。
あるクラスの機能を使ってるといえば良いんだから。
0132デフォルトの名無しさん
NGNG間違いない。
0133デフォルトの名無しさん
NGNGS2ActionServletとかRegistActionClassPlugInを使えば
Actionに関しては全くダイコンを書かなくても大丈夫だよ？
ファイルの分散も気にならなくなり、
さらに金運も上がって女の子にもモテモテでウハウハです。
ActionにAOP適用してたりするとだめだけどね。
漏れの場合はその辺もRequestProcessorへのAOP適用で代用できたけど。
013444
NGNG???
もっと詳細キボン。
0135デフォルトの名無しさん
NGNGあるオブジェクトZが、A, B, C, ..., Yの役割を持っていたとしても、
オブジェクトZの機能を使ってるんだといえば、
単一責任だというように読める。
業務Aのための機能と業務Bのための機能は、
やっぱり別々の役割で内科医。
0136デフォルトの名無しさん
NGNG業務って、具体的に何をどうすることを想定しているのだ
0137デフォルトの名無しさん
NGNG0138デフォルトの名無しさん
NGNG0139デフォルトの名無しさん
NGNGそれじゃ大きすぎないかな。
支払を管理する支払テーブルがあったとして
支払に関連するものとして、
通常の買掛金に対する支払と
売掛金返金に伴う支払と2つあった時に、
トランザクション単位で考えれば業務は2つだけど
支払データ生成ロジックは共通で使いたいでしょ。
この場合、買掛金消込、売掛金返金、支払データ生成
の最低3つを業務と捉えるのが望ましいと思うんだけど。
トランザクションの数とは一致しない。
とはいえ、確かに殆どの場合は
トランザクションと一緒で問題ないかもね。
0140デフォルトの名無しさん
NGNG単一責任がどーのこーの言う前に、まずオブジェクト指向の基礎から学び直していただきたい。
0141デフォルトの名無しさん
NGNGナイーブの意味もついでに調べてみよう
0142デフォルトの名無しさん
NGNGデータと振る舞いが一緒だとオブジェクト指向だと思っている
単純なやつはけーん。
0143デフォルトの名無しさん
NGNG157には同意
0144デフォルトの名無しさん
NGNGナイーブなオブジェクト指向、っていうことばなんだけどさ、
http://www.ogis-ri.co.jp/otc/hiroba/OoBook/Beginner/B3.html
OOSE以前のオブジェクト指向設計方法論の
「OOピュアたるべし、ユースケースはOOじゃない」
みたいな考え方を指していたと思うんだけど、
いつの間に凝集性の低いクラスを作ることを「ナイーブなオブジェクト指向」と呼ぶようになったの?
0145デフォルトの名無しさん
NGNGよーどんさんたちの言う
「ナイーブなオブジェクト指向」は知らないけど
普通に「ナイーブ」なオブジェクト指向って事なら
142の煽りのような意味で取りますわな。文脈からしてさ。
そういう意味でひがたんは使ってると読んだんだけど・・・
なにっ？もしかして、OOワールドでは
コードやヨードンが厳密に定義した言葉として
認識されてるのかっ？
0146デフォルトの名無しさん
NGNGそうだな。確かに>>157はいいことを言ってる。俺も禿胴だ。
014744
NGNG[ 業務A ]
ログイン機能 ---> use isExpired()
[ 業務B ]
社員給料計算機能 ---> use calculatePay
[ オブジェクトZ ]
------------
社員クラス
------------
+isExpired
+calculatePay
------------
この場合のオブジェクトＺは単一責任の原則をやぶってると思う?
おれは思わないよ。
0148デフォルトの名無しさん
NGNG違う概念を同じ名前で表したら混乱を招くでしょ。
014944
NGNG>工数は、リッチな業務ロジック層とDTOパターンのほうが少なくなります。
>DTOとEntityを相互変換する手間がかからないためです。
リッチなドメインオブジェクトパターンではDTOは(めったに)使わないですよ。
0150デフォルトの名無しさん
NGNG厳密に定義されてなければ、同じ言葉を別の意味でつかっても混乱をまねかない、ってもんじゃないだろ。
0151デフォルトの名無しさん
NGNG>この場合のオブジェクトＺは単一責任の原則をやぶってると思う?
システム領域の機能とビジネス領域の機能を一緒に持たせて単一責任も何も。
ナイーブすぎませんか?
015244
NGNG> 振る舞いを1つにすることが、常に正しいとは限らないなんて
> 書くことは、私にとってものすごくリスクの高い&なんのメリット
> のないことです。
>
> にもかかわらず、あえて書いているのは、正しくオブジェクト
> 指向を実践しているように見えても、それが保守性の低下を招く
> 場合もあるということを認識して欲しいということです。
これの例として
> EntityDを使う新たな業務機能が追加されるたびにEntityDに
> メソッドを追加していくと、EntityDは次第に複雑に
> なってきます。
を挙げられているようですが、
EntityDが複雑になる原因は、データと振る舞いを1つにしたことではなく、機能の追加によって次第にEntityDの責務が単一でなくなっていくからです。
このような場合、「データと振る舞いを分割する」のような極端な方法に走らなくとも、EntityDが持つ責務に応じてExtract Classしてやればよいと思います。
> 薄いサービス層とリッチなドメインオブジェクトパターンは、
> 業務機能Aに仕様変更が入っても業務機能Bに仕様変更が入っても
> EntityDを修正することになります。
業務Aから呼ばれようが、業務Bから呼ばれようが
EntityDの持つ責務に変更が入ったのだからEntityDに修正が入るのは
当然だと思いますが。
015344
NGNGどちらがシステム領域で、どちらがビジネス領域?
両方ビジネス領域だと思いますが?
0154デフォルトの名無しさん
NGNG「ナイーブな」オブジェクト指向、って感じで普通に使ったんじゃないの？て話。
148も150も、ナイーブって言葉をはじめて聞いたんでしょうか？
俺、もっと普通に使う言葉だと思ってましたよ。
151がさりげなく使ってるように。
ばかばかしいからこの話やめな。
「ナイーブなオブジェクト指向」って言葉は
テクニカルタームとして、ヨードン、コードが定義した内容でフィックスされてて
ひが氏の使い方は間違い、で、俺の負け、それでいいよ、もう。
0155デフォルトの名無しさん
NGNGhttp://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?DomainModel
を知ってるのだろうか。
0156デフォルトの名無しさん
NGNG確かに、ログインした職責によって
権限を切り替えたりとか、ビジネス領域ですね。
ただ、認証クラスが処理した結果取得出来た属性（IDや職責）を
社員クラスにセットしてやるだけで後はいいじゃん、とか
給料計算を社員自身にさせるのはどうかなあ、とか
議論のある所だと思います。
正解がないだけに色々と人によってまちまちになっちゃうから
いっその事統一ルールで、データの振る舞いは
全部分けちゃえって話だと読みましたがどうでしょう。
0157デフォルトの名無しさん
NGNG前スレでその話は出たのです。
貧血症でも金欠症よりはましだという
はぶさんの言葉もありましたな。
0158デフォルトの名無しさん
NGNGくーすが気に入ったからと言ってS2でないと駄目ってことでもないし。
そもそもどっちもマイナーなんだし放置でいいんじゃないのと思うのは俺だけか？
0159デフォルトの名無しさん
NGNG>両方ビジネス領域だと思いますが?
J2EEが提供するような低水準サービスと間違われたか? ｽﾏｿ
情報システム以前に存在する概念(実体)とシステム化に伴う
概念とを一緒にするのがどうかってことなんだけど。
ところでシステムにログインできるのは社員だけ?
役員や派遣社員は? バイトを雇ったら?
漏れはログインに関わる機能が社員にあるのは、
例としても不適切すぎると思うが、
44氏はアダルト、で、俺の負け、それでいいよ、もう。
0160デフォルトの名無しさん
NGNGおっしゃることはわかりました。けど
you arent gonna need it.
今想定しているシステムでは
-社員のログイン
-社員の給料計算
しかやらないのでこれで十分ですw
必要になったらリファクタリングしましょう。
0161デフォルトの名無しさん
NGNGその話は面白いので、いいよもうで逃亡しないで
もっとやって下さい。
ログインが159の言う意味でのシステム領域か
ビジネス領域かは案件によって様々で
一概にはいえないと思いますけど、
後半は全く同意で御座居ます。
0162デフォルトの名無しさん
NGNGということは、傍観してる俺の勝ち。
0163デフォルトの名無しさん
NGNG>
> http://d.hatena.ne.jp/makotan/20041219#p4
>
> で、うまくまとめられてると思いますが、できる限りスコープ(役割)を小さく抑えることで、
> 修正が入ったときの影響範囲が小さくなり、保守性が増します。
リンク先を読みましたが、データと振る舞いを分けるメリットが
よく分かりません。
データと振る舞いを分けるとなぜ修正の影響範囲が小さくなるのでしょうか?
また、私には逆にデメリットばかりが思いつきます。
-データ構造を公開することにより、疎結合性を妨害
-ポリモーフィックな振る舞いを持てない
-いくつかのデザインパターンの適用を妨げる(Compositeパターン等)
> それを考えるには色々な情報が必要になって一概に言えないので
> 簡略化する為に常にデータと処理を分離することにする。
簡略化するために常に分離しないことにしても良いのでは?
016444
NGNG> うれしかったです。これからも、よろしくお願いします。
そんなご丁寧にw
こちらこそよろしくお願いします。
0165デフォルトの名無しさん
NGNG0166デフォルトの名無しさん
NGNGこれ実際のプロジェクトでやられたら激しくやだ
calculatePayはどう考えても社員クラスにもたすべきじゃない。
44は実務でこんな設計してんの？それとも実務を知らない学生さんなのか？
0167デフォルトの名無しさん
NGNG月給=体重/(身長*身長) 万円 とか。
016844
NGNG> >>147
> これ実際のプロジェクトでやられたら激しくやだ
> calculatePayはどう考えても社員クラスにもたすべきじゃない。
> 44は実務でこんな設計してんの？それとも実務を知らない学生さんなのか？
アジャイルソフトウェア開発の奥義の125Pから持ってきた例なので、
文句があるならロバート・C・マーティンへどうぞw
冗談はさておき、calculatePayを社員へ持たすべきじゃない理由を教えてほしいんだけど。
0169デフォルトの名無しさん
NGNG0170デフォルトの名無しさん
NGNGSQL文のログと、「トランザクションを～」のログレベルが同じなのはどうかと思う。
SQL文って障害解析時に使うけど、「トランザクションを～」が同じレベルで存在してると、ウザイ。
0171デフォルトの名無しさん
NGNG0172デフォルトの名無しさん
NGNG>アジャイルソフトウェア開発の奥義の125Pから持ってきた例なので、
>文句があるならロバート・C・マーティンへどうぞw
書いたのが誰であれ、自分が引用したんだから、自分で責任もって答えたらどうなの？
やっぱり学生さんなのか？
>冗談はさておき、calculatePayを社員へ持たすべきじゃない理由を教えてほしいんだけど。
1.社員の情報だけじゃ給与計算なんて出来ん
勤怠情報とか、税金とか、手当てとか、あと成果主義の会社だったら
会社の業績とかが給与計算に必要なわけで、calculatePayを社員にもたすと
社員とその他もろもろのあいだに依存関係が出来る。
2.calculatePayを社員にもたすと給与計算の変更があるたびに社員クラスを変更しなければならない
そのときに社員クラスにバグを作りこまないという保証がない。
3.calculatePayは月給を計算するんだとして、ボーナスはどうするのか、出張旅費清算はどうするのか？
社員クラスにcalculateボーナスメソッドを持たすとして、会社の制度が変更になってボーナスがなくなったらどうすんの？
0173デフォルトの名無しさん
NGNGやっぱり給与計算となると、
皆自分の経験したり勉強した
実務の事考えちゃうんだと思う。
そうなるとはぶ氏のいってるような事を
考えちゃって、違和感を感じる、と。
＞160で、この例ではそこまで想定してないから
YAGNIだって書いてあるけども
簡略すぎて逆にイメージ湧かないんだと思います。
0174173
NGNG＞172
そんな訳で、このお題に関しては、そこまではYAGNIらしいんだ。
0175デフォルトの名無しさん
NGNG図形クラスがあったとして、saveメソッドを図形クラスに持たせるべきかどうか？
複数の保存形式をサポートしたい場合、saveメソッドを図形クラスに持たせた場合と
別のクラスに持たせる場合で修正の影響範囲ばどちらが小さいか？
、saveメソッドを別のクラスに持たせる場合
-データ構造を公開することにより、疎結合性を妨害
-ポリモーフィックな振る舞いを持てない
-いくつかのデザインパターンの適用を妨げる(Compositeパターン等)
というデメリットが実際に起こるかどうか？
44はくーすがどうたらいう前に、オブジェクト指向を勉強しなおした方がいいと思う。
0176173
NGNG何度もすんません。せっかくだから自分でも考えてみた。
１はなるほど。
2は、社員クラスだろうと給与計算だろうと、変更のリスクは同じかなーと。
どちらかというと、そのリスクを回避するために、
テストがよりしやすいのはどっちかな？って話に持ってった方が吉だと思う。
3は、給与計算に出張旅費生産を組み込むのはちょっと仕事させすぎだと思う。
俺だったら経費の支払と給与計算は別にする。
仕訳も作ったりする場合、まったく別だしね。
最終的に銀行に振り込む情報を管理する機能（例えばFBデータを管理するクラスとか）や
給与明細を出力する機能はこれまた別じゃないか、と。
3はちょっと揚げ足気味かな、ごめん。でも気になったので。
ボーナスは、うーん、どうしよう。
0177デフォルトの名無しさん
NGNG171は、障害出たとき、スタックトレースだけを頼りにしてるのか？
SQLExceptionだったら、どうするんだ？SQL文なくても分かるのと、分からないのあるだろ。
0178デフォルトの名無しさん
NGNG> 簡略化する為に常にデータと処理を分離することにする。
MMRのキバヤシの口調に似てる。
0179デフォルトの名無しさん
NGNG思うが、Strutsを使った時のDTO <--> ActionForm変換の手間をなんとかできんものか....
0180デフォルトの名無しさん
NGNG思ったんだけどどうだろうか。「あーここでロールバックしてるわ」とかそういう
情報になるしさ。
0181デフォルトの名無しさん
NGNGorg.seasar.extension.jtaだけINFOにするとかで止めれるんじゃない?
0182デフォルトの名無しさん
NGNG0183デフォルトの名無しさん
NGNG018444
NGNG1と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
018544
NGNGごめん、質問の意図がわからないよ。
0186デフォルトの名無しさん
NGNGcalculatePayとisExpiredは無関係。
そんな例示でいったい誰を説得しようというのか。
0187デフォルトの名無しさん
NGNG> 役職によってのみ決まる
役職によって決まるんなら、役職に持たせれ。
0189デフォルトの名無しさん
NGNG給料の計算はPaymentCalculatorクラスにまとめるでどうよ。
019044
NGNG> stackのpushとpopは対(つい)の操作。
> calculatePayとisExpiredは無関係。
> そんな例示でいったい誰を説得しようというのか。
対の操作 = ひとつのロール、だよね。
172は、例えひとつのロールとして表すべきクラスでも、
エンバグの危険を避けるためにデータと処理を分けるべき、と言っていると思ってるんだけど。
もしそうじゃなかったとしたら、172の2の反論自体無効だね。
だって、おれは複数のロールを持つクラスをロールごとに分割することには賛成なんだもん。
0191デフォルトの名無しさん
NGNG> 役職はクラスじゃないだろう。
なぜ？
役職によって違うなら、役職ごとに違う処理を役職ごとに実装するのはありだと思うが。
0192デフォルトの名無しさん
NGNG>だって、おれは複数のロールを持つクラスをロールごとに分割することには賛成なんだもん。
calculatePayとisExpiredはひとつのロール？
おれはどう考えても別々のロールだと思うんだけど。
019344
NGNG> calculatePayとisExpiredはひとつのロール？
> おれはどう考えても別々のロールだと思うんだけど。
コンテキストによる。
0194デフォルトの名無しさん
NGNGいいと思う。
あくまでモデルの話だけどさ。
0195デフォルトの名無しさん
NGNGじゃそんな例出すなよ。コンテキストによるなんていわれたら議論のしようがない。
おれはcalculatePayとisExpiredがひとつのロールになるコンテキストなんて現実にはほとんどありえないと思うが。
0196デフォルトの名無しさん
NGNG>>147で
>この場合のオブジェクトＺは単一責任の原則をやぶってると思う?
>おれは思わないよ。
ていってるのはなんなんだ？これを見たら普通44はcalculatePayとisExpiredがひとつのロール
だと考えてると思うんじゃない？
0197デフォルトの名無しさん
NGNG0198デフォルトの名無しさん
NGNGなんでも適当に言えばいいってもんじゃないぞ
0199デフォルトの名無しさん
NGNGいや、そんなに悪くないんじゃない?
俺の場合、役職に関する処理が増えた場合はそれを採用するかも。
0200197
NGNGある役職の処理が変わっても、社員や他の役職のソース修正しなくて済む。
けっこう良かったですよ。
0201デフォルトの名無しさん
NGNG役職や職責でstateパターンってまだ試した事無いんだけど
どうも永続化が、って逆か、DBから読み込んで
Entityを生成する時が面倒な気が、ぼんやりとするんです。
どうでした？俺が判ってないだけかなー。
0202デフォルトの名無しさん
NGNG0203デフォルトの名無しさん
NGNG197の提案は、同じ設計パターンが使えませんかねって話なので
202は反論になってないです。
ファウラーに、在庫推移は複式簿記で管理しないだろ、大丈夫かお前？
といってるようなもんじゃないでしょうか。
もうちょっとダメな理由を詳しくよろしく。
0204デフォルトの名無しさん
NGNGデザインパターンはマニュアル思考しかできない人間を生産してしまう
などというトンチキな批判がうまれる原因ｗ
0205デフォルトの名無しさん
NGNG処理中心になってしまうかもしれないけど、考え方としてはStrategyパターンで行ったほうが素直なのではないでしょうか？
やっぱり、役職は状態ではないと思う。
話が戻ってしまうかもしれないが・・
0206デフォルトの名無しさん
NGNGHibernateにおまかせ。
0207デフォルトの名無しさん
NGNG役職はロール（というオブジェクト）の一種。
組織の規程は、ロールに対して責務を割り当てる。けして個人や部署じゃない。これはビジネスルール。
個人や部署はパーティとしてまとめられる。
パーティはN個のロールを持てる。
組織の規程は、パーティへのロールの割り当て方について制約を課す。これもビジネスルール。
0208デフォルトの名無しさん
NGNG0209デフォルトの名無しさん
NGNG0210デフォルトの名無しさん
NGNG手続き型マンセー、Transaction Script上等って結論じゃなかったか？
0211デフォルトの名無しさん
NGNG0212デフォルトの名無しさん
NGNG0213デフォルトの名無しさん
NGNG給料計算は、給料計算担当者が。
0214デフォルトの名無しさん
NGNGAチーム、なつかしーなおい。
0215デフォルトの名無しさん
NGNG0216デフォルトの名無しさん
NGNG社員は
-自分の役職
-役職からの給与算出方法
のみを知っていれば「権限」などなくても給与計算できます。
よって給与計算担当者は必要ありません。
もちろん、コンテキストによっては給与計算担当者が必要になることがあるかもしれないことは否定しませんが。
0217デフォルトの名無しさん
NGNGで、社員ひとりひとりに自分で給与計算させる会社があるの？
モデリングとは話が違うかもしれんけど、社員を渡せば給料が返ってくる、給与計算者がいるほうがいいと思うなぁ。
0218デフォルトの名無しさん
NGNGこの前提がそもそも非現実的で意味無し。
0219デフォルトの名無しさん
NGNGサンプルコードに何を求めてるんだろう?
0220デフォルトの名無しさん
NGNGあした使えるコード。
あさって納品できるコード。
0221デフォルトの名無しさん
NGNG「社員が持つべきケースのサンプル」
と、「計算担当者が持つべきケースのサンプル」があるだけ。
0222デフォルトの名無しさん
NGNG0223デフォルトの名無しさん
NGNGそいつのせいでスレ違いな書き込みばかりになってるじゃないか！
0224デフォルトの名無しさん
NGNGログ見ても、ナイーブがどうこうとか、某blogのアイドル写真がそろそろ邪魔くさいとか、あまりスレタイとは関係ないし。
0225デフォルトの名無しさん
NGNGどうやらファウラーらしい
0226デフォルトの名無しさん
NGNG> 正解がないだけに色々と人によってまちまちになっちゃうから
> いっその事統一ルールで、データの振る舞いは
> 全部分けちゃえって話だと読みましたがどうでしょう。
に賛成。
債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。
0227デフォルトの名無しさん
NGNG維持すべき設計文書を書いてないだけじゃないかな。
0228デフォルトの名無しさん
NGNGしかも、設計文書とJavaソースとViewやトリガは、見るためのツールが違うので、煩雑に。
それだけ追うための手間が増えるわけですよ。
修正の場合も、設計文書を必ず修正する必要があって、この作業は徹底するのにかなりの労力を伴う。
単純に比較すれば、一ヶ所で記述した場合にくらべて、労力自体は増えると思うのですよ。
とくに、設計文書管理の労力。
0229デフォルトの名無しさん
NGNG実際には、問題になるのは、レベルではなくて、考え方で。
むしろレベルが高い、考え方の違う人が書いたシステムが非常に追いにくくなるわけで。
システムを追う前に、どのような考え方で書かれたのかをプロファイリングしないといけない。
0230デフォルトの名無しさん
NGNGアプリケーション独自のロジックに関しては、ドキュメントがなくてもわかるようなものが理想で。
ただし、アプリケーションの骨格がドキュメントに依存するのは仕方がないと思う。
でも、アプリケーションの骨格は、揺るぎにくく共通化しやすいから、その部分をみんなで使えるようにしましょう、と。
で、そのアプリケーションの骨格のドキュメントが、くーすなのかなぁと思う。
0231デフォルトの名無しさん
NGNG0232デフォルトの名無しさん
NGNG> に賛成。
> 債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
> DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。
債務(さいむ)じゃなくて責務(せきむ)な。
0233デフォルトの名無しさん
NGNG恥ずかしげも無くよく言えるな、おい。
ＸＰｅｒもどきの増殖にも困ったもんだ。
0234デフォルトの名無しさん
NGNG数度の変更を経たにもかかわらず、ちゃんと同期しているドキュメントをみたことがない。
0235デフォルトの名無しさん
NGNG0236デフォルトの名無しさん
NGNGうらやましいな。
0237デフォルトの名無しさん
NGNG0238デフォルトの名無しさん
NGNG先ず書く、そして打つという手順を守りさえすればそんなはずはない
と上司は言うけれど・・・・・・・・
短期で動くモノを差し出せとせっつかれて、それどころじゃないのです。
アジャイルって本当に素晴らしいモノなのかな？なんか週間連載を
抱えた漫画家みたいって言うか、納期が短い間隔で何回もやってく
る感じで、昔よりも寧ろ過酷になってる様な気がするんですが・・・・・
0239デフォルトの名無しさん
NGNG0240デフォルトの名無しさん
NGNG変更管理をきっちりすれば同期問題はおきないぞ。
0241デフォルトの名無しさん
NGNGだから、変更管理をきっちりしてる
プロジェクトで仕事した事がない、って話なんです。
ちっこい案件は別だけど。
0242デフォルトの名無しさん
NGNGＰＭがマヌケということか。同情するよ。
まぁ、悲観するな。そのうちまともなＰＲＪに出会えるから。
0243デフォルトの名無しさん
NGNG構成管理をきっちりしないと、同期問題がおきるってことでしょ。
で、構成管理をきっちりすることは、組織的な成熟度が高くないといけない。
適用しやすい開発方法論を考えるのなら、
「こうやればうまく開発できます。でもドキュメントが大切なので、構成管理はきっちりやってください」
というものはどうかと思う。
構成管理がきっちりできるなら、他の能力も高いことが多いから、どうとでもやってくれという感じ。
0244デフォルトの名無しさん
NGNG. |（･∀･）|
. |￣￣￣ ｼﾞｻｸｼﾞｴﾝ王国
△
△ｌ |
＿＿△|_.田 |△＿＿＿＿＿
|__|__門_|__|＿＿＿＿＿|＿＿＿＿＿
0245デフォルトの名無しさん
NGNGTheBlobを避けるためにPoltergeistに向かっているように思うなー。
The Blob
http://www.antipatterns.com/briefing/sld024.htm
Poltergeist
http://www.antipatterns.com/briefing/sld030.htm
0246デフォルトの名無しさん
NGNGだからフレームワークは無用
プログラミングしよう
0247デフォルトの名無しさん
NGNGまぁ、わからないでもないよ。最近は知ったかぶりのアジャイル莫迦が多すぎるからな。
JAVAWORLDも酷い記事を書くやつが増えたが、編集は何をやっているんだか。
0248デフォルトの名無しさん
NGNG0249デフォルトの名無しさん
NGNG使い捨てで、ソースコードとの同期はやらないんだよね。
0250デフォルトの名無しさん
NGNG捨てはロバストネス図じゃなかったっけ？
0251デフォルトの名無しさん
NGNG捨てはロバストネス図じゃなかったっけ？
0252デフォルトの名無しさん
NGNGあれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
0253243
NGNGもちろん適切に使えばよいけど、一度乱用する時期を経ないと適切に使えないと思う。
プロジェクトの発言権を持った人の中に乱用する時期の人がいる可能性も高い。
0254243
NGNG「ドメインモデルは、複雑なコードを整理しやすいのがメリットだ。
ただ、開発者にとって理解しにくく、またRDBMSとのマッピングが複雑になる。
そこで、ORマッピングレイヤを設けなくてはならない。
そのため、ドメインロジックがシンプルな場合は、トランザクションスクリプトを採用した方がいい。」
ということだ。やっぱファウラータンは俺のために言葉を用意してくれてて偉いな。
ttp://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html
0255デフォルトの名無しさん
NGNGそんな考えはレガシーで、ドメインモデルは複雑な
ロジックを記述するには向かない
という考えってどうよというのが先週からの話。
少しは流れを嫁。
0256デフォルトの名無しさん
NGNGつまり、すごく複雑ならドメインモデルでちょっと複雑ならトランザクションスクリプトっていってるのを、すごく複雑でもトランザクションスクリプトでってこと？
0257デフォルトの名無しさん
NGNG0258デフォルトの名無しさん
NGNGこの辺かな。
http://d.hatena.ne.jp/higayasuo/20041223#1103771319
1週間くらい前からいろいろもとねたがある。
0259デフォルトの名無しさん
NGNG0260デフォルトの名無しさん
NGNG> ２．1を再帰的に繰り返す。
構造化じゃん。
0261デフォルトの名無しさん
NGNGメソッド分割なのかコンポーネント分割なのかという話だと思うよ。
ちなみにそれが構造化ならあらゆる処理がが構造化。
自分で処理するか他人に任せるしかないんだから。
0262デフォルトの名無しさん
NGNGでも、トランザクションスクリプトじゃない、って書いてある。
ここに書いてあるのは、トランザクションスクリプトを構造化したらいいって話だよね？
そしたら、コマンドパターンっぽく切り替えやすくなると。
構造化って、おおざっぱなものが細かいものを再帰的に内包するモデルのことだよね？
違うの？
0263デフォルトの名無しさん
NGNGで、Javaだと、ひとつの処理をひとつのオブジェクトに割り当てるといろいろ切り替えれて便利、っていう話だと思ったんだけど。
0264デフォルトの名無しさん
NGNGってことで、オブジェクトに持って切り替えれるようにしましょうってことでしょ？
切り替える用途やら規模によって、ストラテジーだとかコマンドとかステートとか、いろいろパターン名が変わるだけで。
0265デフォルトの名無しさん
NGNGたぶん、構造化というよりは、自分の役割だけをこなしてあとは、
人に任せるということなんだと思う。
ドメインモデルは、1つのクラスに役割が集中しすぎる危険性があるという話。
0266デフォルトの名無しさん
NGNG言い方が違うだけで、構造化とやってることは同じだと思うけど。
人=オブジェクトって考えが出てるけど、これはJavaの言語仕様上オブジェクトが便利なだけで。
関数ポインタが使えるか、メソッドを代入できる言語では、オブジェクトである必要はなさそうだし。
そのオブジェクトはステートレスなんだよね？
つまりは、ドメインモデルを適切に構築するのは難しいから、構造化されたトランザクションスクリプトで、ってことでしょ？
0267デフォルトの名無しさん
NGNGただ、ここでインターフェイスを持ち出してくる必要があるのかないのか。
インターフェイスはテストの都合で必要なわけで。
処理を動的に切り替える予定がない部分をインターフェイスにする理由は、それしかないよね？
0268デフォルトの名無しさん
NGNG0269デフォルトの名無しさん
NGNG「モデル」部分を「単純なデータ保持／DBアクセスオブジェクト」として完全委譲した
だけで、これはドメインオブジェクトだって理解した方がいいんじゃないの？
トランザクションスクリプトってのは、サービス層でDBアクセスも全部世話して、呼び出した
メソッド一つで全部やってしまうようなもんだろ。
プレゼンテーション層 -> サービス層（薄い） -> ドメインモデル（モデルを基準に分割／ORマッピングもする） ->DB
が
プレゼンテーション層 -> サービス層（薄い） -> ドメインオブジェクト（サービスを基準に分割） -> 薄いモデル（ほぼORマッピングだけする） -> DB
になっただけなんじゃないの？ どっちみちサービスの連鎖の開始ポイントとして、Facade的な
薄いサービス層は現れてしまうし。
で、薄いモデル部分がドメインモデルと比べて明らかな貧血症だから騒いでるだけだろ。
俺にはデータアクセスをドメインモデルから外に出して、分割の基準を変えたように見える。
0270デフォルトの名無しさん
NGNG結局サービス層のことをドメインと呼んで、その前に置いたコントローラー的な層をサービス層と呼んでるんじゃない？
で、実際にドメインになる部分が薄くなって、「ドメインモデル貧血症」になってるからどうこう言ってるんじゃないの？
いや、よくわからんのだけど。
0271デフォルトの名無しさん
NGNG0272デフォルトの名無しさん
NGNG学生ですか？
機能拡張とか仕様変更とか、手作業でトランザクション制御する手間とか
納期とか考えたことある？
0273デフォルトの名無しさん
NGNG> メソッド一つで全部やってしまうようなもんだろ。
いや、ドメインモデルを構築する代わりに全部１つの流れでやりましょうっていう形。
だから、ドメインモデルと置き換わるはず。
で、もちろん１つのメソッド・ひとつのオブジェクトで完結する必要はないと思う。
サービス層は、適切なトランザクションスクリプトを呼び出す層ということになるんじゃない？
0274デフォルトの名無しさん
NGNG> 手作業でトランザクション制御する手間
トランザクションが必要で、それがAOPで実現されてるならインターフェイスを使うしかないね。
で、機能拡張とか仕様変更とかの話だと、ソース追う手間が増えることを考えると、一概に言えるのかなぁ。
ソース追う手間は、無視してしまえる程度にしか増えないものなの？
0275デフォルトの名無しさん
NGNGいままでのクラスと同じ名前でインターフェイス作れば、ソースは変更しなくていいし、オブジェクトの生成はDIでやってるわけだからそこ書き換えるだけじゃないかなぁと。
0276デフォルトの名無しさん
NGNGこれなんか読んでると、別にトランザクション・スクリプトでもいいじゃん、という気になる。
おれ、ドメインモデルってモデル間が密結合しすぎのような気がするんだけど。
0277デフォルトの名無しさん
NGNG0279デフォルトの名無しさん
NGNG複雑な業務ロジックだと、トランザクションスクリプトには
向かないというのはなぜ?
別にトランザクションスクリプトはどうでもいいんだけど、
コンポーネント分割でDIで組み立てるやり方なら、
逆に複雑な業務ロジックに向いてると思うけど、
理由は、それぞれのコンポーネントは小さいから。
ドメインモデルは、複雑なロジックになればなるほど、
クラスは大きくなる。
0280デフォルトの名無しさん
NGNG複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ？
なにか説明するにしても、ファウラーの言葉の引用になりそう。
とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。
で、複雑な業務ロジックの場合は、オブジェクトが状態を持ったほうが好都合なんじゃないのかなぁ。
0281デフォルトの名無しさん
NGNG0282デフォルトの名無しさん
NGNG複雑なロジックを単純な役割に分割してそれぞれの役割にコンポーネントを
割り振るからだろう。
それぞれの役割は単機能だから小さい。
ドメインモデルだとデータに対して振る舞いを割り当てるから、
複雑になればなるほど、やらなければならない役割が増える。
0283デフォルトの名無しさん
NGNG> >>279
> 複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ？
> なにか説明するにしても、ファウラーの言葉の引用になりそう。
引用は別に良いと思うけど、理由を説明できなければ意味はない。
ファウラーたんも盲目的に信じて欲しいとは思ってないと思うけど。
> とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。
そんなことどっかに書いてある?
0284デフォルトの名無しさん
NGNG0285デフォルトの名無しさん
NGNG> そんなことどっかに書いてある?
そうじゃないの？
0286デフォルトの名無しさん
NGNG>>282に書いてあるじゃん。分割単位が役割じゃなくてモデルだからだろ。
0287デフォルトの名無しさん
NGNG0288デフォルトの名無しさん
NGNG0289デフォルトの名無しさん
NGNGトランザクションスクリプトはいくらでも分割できるだろうけど、そのとき大きなドメインのモデルよりいいかどうかは疑問に思える。
杞憂なのかな？
0290デフォルトの名無しさん
NGNGORマッピングで、１つのテーブルをいくつかのオブジェクトにマッピングできるものもあるわけだし。
0291デフォルトの名無しさん
NGNGいいたいのか、大して変わんないんだからドメインモデルでいいじゃんといいたいのか、
言ってることに利点など何もない、問題は存在しないといいたいのか。
0292デフォルトの名無しさん
NGNGデマルコの「構造化分析とシステム仕様」は、「構造化」の原典のひとつだと思って引っ張ってきたんだけど、違ってる？
0293デフォルトの名無しさん
NGNG分割統治せよは、昔から言われている真実。
大きいより小さいほうが中身がわかりやすいのは当たり前。
複雑なドメインロジックの場合、データと役割は単位(大きさ)が
かみ合わないことのほうが多いので適切に分割できない。
たいていの場合、1つのデータに多くの役割が集中する。
なぜかっていうとそのデータに関する役割を集めるからね。
必然的にそうなる。
0294デフォルトの名無しさん
NGNGドメインモデルが分割できないときに、細切れのトランザクションスクリプトをばらまいても、問題を複雑にするだけということはないだろうか？と。
0295デフォルトの名無しさん
NGNG考えるからさ、「この機能、どこにおいてもぴったりしない」とかいうことがあるよねえ。
で「社員Util」とか変なのがいつのまにか作られてたり。
俺はサービスを分割基準に置くのは悪い考えではないと思うし、それによってオブジェクト指向的な
利点を無効にしてしまうこともないと思うよ。
モデルの役割をモデル内データの管理とその永続化だけにしようって考え方も、とてもオブジェクト
指向的だとおもうけど。
0296デフォルトの名無しさん
NGNGんん？ 単にモデルにはモデルの役割だけさせて、ビジネスロジックはモデルの役割じゃないから
サービスとして分割しようって言ってるだけだと思うんだけど。
サービスとして分割してしまえば、分割の自由度は上がる。でも意味もなく細切れにしたら混乱する
のはあたりまえ。「ここは分割しなきゃ」と思ったときに、ドメインモデルだと分割しにくいけども、
サービスだけならきれいに分割できることがあるってだけ。
0297デフォルトの名無しさん
NGNG間違ってないよ。
なんか構造化は悪いものだとか、オブジェクト指向とはかみ合わないとか
勘違いしているやつが多いのか。
0298デフォルトの名無しさん
NGNG実際、ここにはドメインモデルがいいとは書いてあるけど、トランザクションスクリプトがダメな理由は書いてないね。
だから、どっちも疑問といえば疑問なんだけど。
ただ、モデル化は視点の問題だと思ってるので、片方のモデルで適切に分割できないのに片方のモデルでは適切に分割できる、というのが、にわかに信じれない。
複雑なものを細切れにすると、単純なものが複雑に散らばるだけなんじゃないかと。
それよりは、大きな複雑なものがあったほうが、見通しも良くていいんじゃないかと思うわけです。
そのとき、それぞれの部品の単純さを主張しても、意味のある主張になるのかなぁと。
実際に上記のサイトのグラフで線が入れ替わるところのような複雑なものは、単純に例示できないだろうから、難しい話だとは思うんだけど。
0299デフォルトの名無しさん
NGNGそう。
だから、なんでヒガさんが構造化だと言われたことを誤解だと斬って捨ててるのか、疑問。
0300デフォルトの名無しさん
NGNG適切って言葉をどう捉えるか。くーす的なのは「いかに維持しやすいか」が視点だろう。
そのかわりドメインモデルの明快な美しさは失われるが、それはビジネスだから諦める。
理屈ではドメインモデルってみんな好きなんだよ。でも仕事で使ってみると
世の中明快に割り切れるものなんてないし、たとえうまく設計できたとしても
システムは完成した瞬間から陳腐化するから維持運営に結構苦労する。
サービス分割って考えは希望が持てる。業務とコードが対応してるから直すときに躊躇がいらない。
将来一部業務に大変更が発生しても、ほかへの影響なしにそこだけ手を入れられるってのはステキだ。
0301デフォルトの名無しさん
NGNGそれはそれでかまわないと思ってる。でも実際には、そのモデルＡの役割というよりは、モデルＡ
とBとCをつかってほにゃららする、という機能が結構あるんだよ。
結果としてＡがB、Cを保持したりして実現するわけだ。
それがＡというモデルの機能なのか？という疑問というのが１点ある。B、Cでないとどうして
いえるのか？ またＡでもBでもCでもなく、ＡＢＣと取りまとめる別のモデルの機能ではないか？
さらに、その機能のためにＡはB、Cを保持してるわけで、結局は「複雑に散らばってる」わけだ。
大きな複雑なモデルってのは、「大きなものがひとつあって、そこだけ見ればなんとかなる」んじゃ
なくて、細切れのモデルが一つのモデルの中で絡み合ってごちゃごちゃになってて、結局全部の
モデルを理解していないと「大きな複雑なモデル」を理解できない。だから「ドメインモデルは全体を
理解してないと使えない」と言われるわけ。さらにモデルが永続化も担うので、役割過剰と言われ
ても仕方がないと思う。
サービス分割も同じ問題ははらんでるよ（あるサービスが別のサービスと絡み合うとかね）。
ただサービスが一つのビジネスロジック上の役割で分割されているので、触るときに影響範囲が
見えやすいし、「あ、これは別の業務だな」と思ったら躊躇なく分割できる。結果として細切れの
サービスができかねないのは事実なんだけど、細切れのものが業務単位でまとまってるので、
多少はまし、といったところか。
0302デフォルトの名無しさん
NGNG0303デフォルトの名無しさん
NGNGとりあえず前提条件おさらい。
どうやって計ったかはしらないけど、トランザクションスクリプトだと天井つきぬけるくらいコストがかかるとファウラーが主張するくらいビジネスロジックが複雑なときの話。
で大きいまま分割できないドメインのモデルがある。
そのとき、そのドメインのモデルは、その大きさのままが維持しやすいことになるんじゃないのかなぁ。
将来そのモデルのかかわる一部業務に大変更が発生しても、いろいろなところを追わずに、そのモデルだけ修正すれば済むわけで。
もちろん、分割できないモデルだから、そのモデル全般に影響が及んでるだろうけど。
縁がありそうな程度の複雑さのビジネスロジックでは、>>300に賛成。
0304デフォルトの名無しさん
NGNGうーん、なんか逆な気がするな。
大きく複雑なモデルは仕事をいろんなモデルに移譲しまくってるので、「業務」単位でみると、
一つの業務追加・変更で複数のモデルに影響がでるよ。
モデルの分割単位はあくまで「なんらかのビジネス上の概念」であって、業務ではないからね。
で、たいていの業務では、「なんらかのビジネス上の概念」が複数絡まってるもんだ。この複数
絡まってる機能をどこにおく？という話じゃないか。
0305デフォルトの名無しさん
NGNGいや、そのとき、ドメインモデルだと細切れのモデルが絡み合っててごちゃごちゃになってて結局全部のモデルを理解してないくらい複雑なのに、サービス分割だと影響範囲が見えやすく業務単位でまとまってるってことはないんじゃないのかな、と。
サービスを、躊躇なく分割したり業務単位でまとめれるなら、ドメインモデルも同じように分割して業務単位でまとめれる可能性が高いんじゃなかろうか。
0306デフォルトの名無しさん
NGNGもちろん、複雑じゃない業務ロジックの話で、ドメインモデルよりサービスでの分割がいいというのは、同意できる。
0307デフォルトの名無しさん
NGNGそうだね。でもそのようにドメインモデルを分割したら、それはドメインモデルじゃないんじゃない？
ドメインモデルはそのモノが担うべきものだけを提供すべきで、業務的な必要性から関係ない機能を
追加するもんじゃないからさ。理想としては、もし業務要件が複数のモデルが絡み合うものなら、
複数のモデルを直すべきなんだよね。
業務要件で勝手にまとめてどっかのモデルに押し込んじゃったりしたら、ドメインモデル特有のオブジェ
クト指向的美しさは台無しじゃないか？ でもビジネスはそんな美しさは関係ない訳で、そこに軋轢があ
るんじゃないか。
サービスだと、そもそも業務単位でまとめるもんなんだし、分割しやすいしまとめやすいってことじゃ
ないかと。まあ業務要件があって仕事があるという現実に即した分割方法じゃないかな？
0308デフォルトの名無しさん
NGNGまずどういうシステムを対象にどのように測定したのか知りたい。
同じシステムをそれぞれのパタンで作って比較したのか、
それとも色んなシステムを比較したのか。どこかにどのように
調査したのか書いてるのある？
0309デフォルトの名無しさん
NGNGその意見が、非常に複雑な業務ロジックで成り立つのかが疑問なんです。
まあ、その解を得ることに、「>>308の図が読み解ける」という以上の意味はないんだけど。
というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
もちろん長い年月ソフトウェアに関わって、いろいろな開発をみてきて、実際の測定もしてきたわけだから、それなりの根拠があることは間違いないんだけど。
0310デフォルトの名無しさん
NGNGありがちなのは飛行機工場の生産管理とかかな？
0311デフォルトの名無しさん
NGNG0312デフォルトの名無しさん
NGNG0313デフォルトの名無しさん
NGNGトランザクションスクリプトは、任意の単位に分けられるから
機能単位に分ければ良いが、
ドメインモデルは、意味のあるデータ単位に振る舞いを持たせるから
機能単位に分割できないという話でしょ。
0314デフォルトの名無しさん
NGNG> というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
禿胴
0315デフォルトの名無しさん
NGNGファウラーのいっているトランザクションスクリプトは、
1つのクラスでメソッド分割するイメージなんだと思うな。
それだったら、複雑になればなるほどクラスが大きくなるから
その維持は大変になる。
ドメインモデルは、複雑とはいっても複数のクラスに処理が
分散されているからましということなんじゃないだろうか。
そういう前提なら、http://www.nri-aitd.com/tips/image/g-patern_4.gifも
まぁ、そうかなという気もする。
くーすでいっている役割分担によるコンポーネント分割方式なら、
複雑になっても、それぞれのコンポーネントの役割は明確で、
小さいから維持は、ドメインモデルよりしやすいだろう。
0316デフォルトの名無しさん
NGNGいや、それで、トランザクションを分けたときに、業務単位にまとめれたり、影響範囲がみえやすかったりするのだろうか、と。
ドメインモデルでは、複雑でごちゃごちゃに絡み合ってそれ以上分割できず、全体をみないといけないのにだよ？
0317デフォルトの名無しさん
NGNGなんで、単純比較してしまうとなあ。
0318デフォルトの名無しさん
NGNG業務単位に最初からクラスを作れば良いんだから分けられるに決まってる。
影響範囲が見やすいといっているのは、本来独立した複数の業務が
交差することはないためでしょう。
0319デフォルトの名無しさん
NGNGうん、だから、単純な業務ではドメインモデルじゃないほうがいいというのは共通認識になってると思う。
>>318
いちおう、>>303あたりの前提条件みてください。
0320デフォルトの名無しさん
NGNGだから、複雑で分割できないと思っているのは、
データを中心に見ているからでしょう。
データに関連する振る舞いを全部持たせようとするとそうなる。
複数のモデルに関連する振る舞いをどれかのモデルに持たせればそうなる。
機能を中心に見ればそんなことはない。
どんな複雑な機能だって、シンプルな機能に分解できる。
0321デフォルトの名無しさん
NGNG0322デフォルトの名無しさん
NGNG0323デフォルトの名無しさん
NGNGなくて、データの管理と永続化は外に出しちゃって、ビジネスロジックは機能で
分割しましょう」って話じゃないのか？
0324デフォルトの名無しさん
NGNG>というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
PofEAAによるとそれは「nonscientific graphs」らしいよ。
ファウラーたんの感覚的なものに過ぎないんじゃないかな。
0325デフォルトの名無しさん
NGNGだから、機能がシンプルなものに分割できることはわかってるんだけど、そのつながりが複雑になるんじゃないの？と。
で、そういう話をしているときに、単体のシンプルさを主張しても、あまり意味がないんじゃない？
って、だいぶ前に書いた気がする。
0326デフォルトの名無しさん
NGNG萎えた
0327デフォルトの名無しさん
NGNGま、そんなもんなんだろう。
とりあえず、ファウラーたんを信用ことにするよ。
感覚的なものを極端に書いてると思っておく。
ただ、いつもどおり目の青い人の国でのお話だから、日本で鵜呑みにはできんけど。
0328デフォルトの名無しさん
NGNGそういうことか。
どんなに複雑な組み合わせでできたコンポーネント群でも
特定のコンポーネントを見れば、自分と直接関連のある
コンポーネントだけとしか関係を持たないから
つながりも複雑になることはない。
0329デフォルトの名無しさん
NGNG0330デフォルトの名無しさん
NGNGMartin Fowlerのスレッド
http://pc5.2ch.net/test/read.cgi/prog/1099814095/l50
0331デフォルトの名無しさん
NGNG0332デフォルトの名無しさん
NGNG業務機能とソースコードのバランスをどうとるか、って噺はあんまり聞かないから。
0333デフォルトの名無しさん
NGNGDomain Model＝DOA的OO
ってことでいいのか？
http://www.nri-aitd.com/tips/g-patern.htmlの
それぞれの特徴を見てるとそんな気がしてきた。
0334デフォルトの名無しさん
NGNG話が、ファウラーたんもびっくりレベルの複雑な業務ロジックだったときに、果たしてそういえるのか。
特定のコンポーネントだけをみて、自分と直接関係のあるコンポーネントだけをみて、用が足せるのか。
甚だ疑問。
0335デフォルトの名無しさん
NGNGまたまたスレ違いの質問なんだけど、DOAの原典的な本とか、始祖的な人ってどこらへんになるんだろう？
一度中途半端に調べてみたんだけど、わからなかった。
0336デフォルトの名無しさん
NGNG疑問に思うのは自由だけど、それで用は足せる。
DIでは、自分の直接の知り合いとしか話しないから。
相手を探しにいくことはないんですよ。
コンテナが必要な人をDIしてくれるんだから。
0337デフォルトの名無しさん
NGNG0338デフォルトの名無しさん
NGNGべつにここでDIを出してくる必要はないと思うんだけど。
それと、DIでオブジェクトが組み立てられて、個々のオブジェクトが単純で、少ない数のオブジェクトとしかやりとりしないからといっても、本質的な複雑さが解消できるものではないと思うよ。
本質的な複雑さというのは、系が閉じているときは一定なので、モデリングのやりかたで複雑さがかわるものでもないし。
0339デフォルトの名無しさん
NGNG業務サービスベースで考えるので、そもそもの実装が「なんらかの特定業務に
関連した情報を返す」ということがモデリングのスタート地点になってる。
ドメインモデルは「おれのモデルでできることはここまでだよ。他の処理はほかの
モデルがやるんだろ？ おれは知らんよ」という構成になっているので、各モデルの
位置づけを理解した上で、さらにそれがどうつながってるか理解しないと、何を
やろうとしているのか（何の業務を解決しようとしているのか）分からなくなる。
サービスベースでもサービスが増えればややこしいのは事実。DAOも含めると、３０
近いクラスが絡み合ってることもあるよ。
でもこの複雑さは、おれたちが普通に関数なりメソッドを呼ぶときに「あ、ここはちょっと
別のprivateなメソッドにでも分けるか」とかやってメソッド一つずつをシンプルにして、
１メソッド3000行とかならないようにするのと似てる。つまり機能が複雑になってきたし、
重複しそうだから、一部機能を＿機能として＿分割してるわけで。
おなじ絡み合っているのでも、つながりが追いやすいんじゃないかな。
0340デフォルトの名無しさん
NGNG業務が複雑になったときには、ドメインモデルを構築してないと、「なんらかの特定業務」すらどこで行っていいかわからなくなると思う。
でも、ドメインモデル構築自体の複雑さが問題にならなくなるような複雑なシステムはそれほどない、と。
たぶんシステムの多くを占めてる、流通系とかお店のシステムだと業務がそれほど複雑じゃなくて、商品・サービスの移動と「なんらかの特定業務」がリンクしやすいしね。
0341デフォルトの名無しさん
NGNGでも悪くない気分
0342デフォルトの名無しさん
NGNG0343デフォルトの名無しさん
NGNG0344デフォルトの名無しさん
NGNG変えるのが先だと思う。それとも英語で書く時と日本語で書く時に
使い分けるつもりなんだろうか？
ほんと気分悪い。
0346デフォルトの名無しさん
NGNG誰もファウラータンを禿なんてよんでないよー。
0347デフォルトの名無しさん
NGNG,-､二、 ｰク / 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
ﾟ ﾟ ﾟ ﾟ `ｰ" ｰ' 〔 /￣／ '", //／ ,.
0348デフォルトの名無しさん
NGNG学級会的道徳観の持ち主の方がすんごい気持ち悪い。
おえー。
0349デフォルトの名無しさん
NGNG本人の前で言わないようなことしてたら同じ穴の狢
他人に腹が立つのは大抵そこに自分を見るかららしいぞｗ
0350デフォルトの名無しさん
NGNGドメインモデルってMVCモデルのMを具現化したものだろ。でもくーすってMVCじゃなくて、
ヤコブソンのBCEを具現化したものだろ。Boundary-Control-Entityって用語を使ってる
ところからして。
BCEってMVCの問題点を解決するものとしてあげられてるんだし、MVCなドメインモデル
から見て矛盾があるのはいわば当然じゃないかな。
0351デフォルトの名無しさん
NGNGファウラーのMVCモデルは、ウェブプレゼンテーション層の中だけの話。
アプリケーション全体をMVCにして、UI以外を全てMに押し付けるモデルは、EJBが重すぎて崩壊してしまったのを見ればわかるように、実際には使い物にならない。
0352デフォルトの名無しさん
NGNGあとEJBが重すぎるのはリモートコールを多用するからじゃないか？
ローカルコールで動かすと、悪名高いEntityBeanですらそれなりの速度で動くぞ。
0353デフォルトの名無しさん
NGNGそれと、蒸し返すといっても、少なくともこのスレでMVCという言葉は出てきたことがないのだが。
0354デフォルトの名無しさん
NGNGじゃあ、蒸し返すのでなく次の話題ってコトでどうだろうか.....
0355デフォルトの名無しさん
NGNG0356デフォルトの名無しさん
NGNGでも、ファウラーのMVCでは、Vはドメインモデルとやりとりしない。
MVCmodel2とファウラーのモデルは対応しない。
というか、MVCmodel2で、やんちゃなV(JSP)と、たよりないC(Servlet)を与えられて、「あとはMです。ご自由に」と広大な空き地をおしつけられても、ねぇ。
0357デフォルトの名無しさん
NGNGMVCmodel2としてVに渡されるMは、ドメインモデルとは別のものでVが必要とするM。
ドメインモデルのMからMVCmodel2としてのMへの翻訳が必要。
おれはかならずこの翻訳を意識している。
翻訳しないケースがあれば、それはたまたま両者が一致しているという特殊ケースと位置付ける。
0358デフォルトの名無しさん
NGNGそのMVC Model2のモデルとドメインモデルの変換コストの話が
http://d.hatena.ne.jp/higayasuo/20041207#1102379088
http://d.hatena.ne.jp/higayasuo/20041220#1103516338
で、ドメインモデルが工数がかかるという根拠になってるみたい。
結局話題がリンクしてる?
0359デフォルトの名無しさん
NGNGkusuが対象とする開発は20-50人の中規模と思うのだけど、
開発者にDIについての認識を強要するのは酷な話。
少なくとも、開発者全員が一読するという代物ではない。
であれば、kusuって開発の方法論であって開発標準ではないよね。
この規模の方法論って他にもあるのに、なんであえて提唱したのか
よくわからないんだよなぁ。
0360デフォルトの名無しさん
NGNG翻訳といっても、その幅は広いよね。
インスタンスへのリンクを渡すだけのファサードな場合もあれば、ドメインモデルの全プロパティをコピーするDTOな場合もある。
357の意図してるのはどちら?
0361デフォルトの名無しさん
NGNG同じ規模のものが他にあっても、提唱しない理由にはならないでしょ。
ほとんど同じものが他にあるなら別だけど。
0362デフォルトの名無しさん
NGNGhttp://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アプリへの最適化によるものだ、と言ってみるテスト。
0363デフォルトの名無しさん
NGNGDIスレと分けた意味はあるんだろうか？
0364デフォルトの名無しさん
NGNGWebじゃなくても、基本的には変わらんと思うが。
0365デフォルトの名無しさん
NGNG他のものとどこが違うか、よくわからない。
Seasarに依存するってとこ？
0366デフォルトの名無しさん
NGNGPofEAAの解説にしかみえないのは、俺だけ？
0367デフォルトの名無しさん
NGNGいや、比嘉氏は既存の中規模システム開発用の開発標準にでは
満足いかなかったのではないかと思う。つまり、RUPを軽くした
国内開発者向けの標準を作らなければならないという危機感が
あったのではないか、と、そんな気がする。
kusu本を出すなら、その辺の経緯も記してもらいたい。
0368デフォルトの名無しさん
NGNG0369デフォルトの名無しさん
NGNG自分の技術レベルが低いと思ったら使えばいいんじゃないの。
037044
NGNG>話を簡単にするために常にデータと振る舞いを一緒にするというのは、
>それはそれでOK。
>
>ただし、機能が増えるにしたがって役割多すぎなクラスになる
>危険性があるということです。最初は、データと構造を一緒に
>しておいて、機能が増えてきたらリファクタリングすればいい
>という考えもあるかもしれません。しかし、それは、
>リファクタリングではありません。利用する側から見て
>インターフェースが変わってしまうからです。
インターフェース/クラスの内部でExtract Classしたクラスへ対して委譲すればいいだけでは?
そうすればインターフェースは変わりませんよね。
037144
NGNG>「データ構造を公開することによる疎結合性を妨害」という点では、
>永続化されるようなデータの構造は、もともとpublicですから特に
>問題にはならないと思います。
何に対してpublicなのでしょうか?
また、データ構造をクラスの外へ公開することによるデメリットとして、修正箇所がアプリケーション中に分散してしまうことなどがあると思いますが、publicであることはこのことに何か解決策をもたらしているのでしょうか?
037244
NGNG0373デフォルトの名無しさん
NGNG>修正箇所がアプリケーション中に分散してしまうことなどがあると
あっちこっち直すことになるかもしれないが、
どの業務機能から使われてるかが分かるから影響範囲が明確になる、とも言える。
これは高度に抽象化をおこなわないことによるメリットかな。
修正が難しいのはデータを「変更」する処理だろうが、それって分散して存在することは稀。
SeasarならS2Daoでエンティティ単位の管理ができるから、そんなに大変ではないだろう。
主として影響を受けるのは大抵は入力・表示関係。そしてそれはUI層の問題だから別の話になる。
0374デフォルトの名無しさん
NGNGだれか分析してくれ。
0375デフォルトの名無しさん
NGNGバウンダリはなんだ？
0376デフォルトの名無しさん
NGNGパンダに熱くなったほうがいいのにね。
0377デフォルトの名無しさん
NGNGひがたん
0378デフォルトの名無しさん
NGNGとりあえず、以後、他人に意見するのは止めることですね。
0379デフォルトの名無しさん
NGNGパンダに意見するのはOKですか？
0380デフォルトの名無しさん
NGNG「易しさと優しさ」とか言ってたのに、あとは、自分でやれってことか？
0381デフォルトの名無しさん
NGNGとりあえず前半部分は技術者の意見とは思えない。
後半は俺が読み違えてるのかもしれないので確認したいんだけど、
public属性の影響を受けるのは、値を設定するところじゃなくて
むしろ単純読込の方が量が多くて問題になる。
たとえばその属性の型が変わったり、setXXの時に小数点2桁で丸めたい、
という変更があったときに、アクセッサ経由で統一されている方が楽。
そのモデルのサブクラスを作って変数をオーバーライドしちゃうと
ベースクラス側でのメソッドの中でアクセスしてる変数と別物になっちゃうので
スマートな形でサブクラス化できないこともある。
膨大な繰り返し処理の速度を速くしたくてわざとpublic属性にすることは
あるけど、そういうのは基本を踏まえた上での小手先のテクニックとして
ソースにコメントをつけながらやることであって、できるだけ基本は
守っていた方がいい事が多い。
ひがさんはOOPのメリットをあまり理解できなかった側の人だと思うので、
44さんはもう突っ込まないであげればいいと思う。DI自体は悪くない技術だし、
彼らのモチベーションが高い方がseasarがいい方に行くと思うから。
逆にseasarが好きで変な方向に行って欲しくないからこそ、ひがさんにいろいろ
突っ込みを入れてるのかもしれないけど
0382デフォルトの名無しさん
NGNGそこはスローガンなんだからそんな言い方するこたあないだろ。
「削除も作ってほしいなあ」とか言えば気分良く作ってくれる人が
いるかもしれないのに。
0383デフォルトの名無しさん
NGNG0384デフォルトの名無しさん
NGNGうーん、何が言いたいのかよくわからんわ。
> たとえばその属性の型が変わったり、setXXの時に小数点2桁で丸めたい、
> という変更があったときに、アクセッサ経由で統一されている方が楽。
だったらそうすりゃいいじゃん。
>>381はフィールドをpublic属性にする話をしているように読めるのだけど...
永続化データがpublicだという話をそう読んだわけ？
永続化されるようなデータはそもそも構造が公開されてるもんだと
いう意味で、publicだと言ってるだけだと思うけど。
S2Dao使ったって結局各データにはアクセッサ使ってアクセスするんだし、
プロパティとして扱ってるから、アクセッサ経由だし。
0385デフォルトの名無しさん
NGNG何だくれくれクンか
0386デフォルトの名無しさん
NGNG何でパンダなんだ？
0387デフォルトの名無しさん
NGNG> 膨大な繰り返し処理の速度を速くしたくてわざとpublic属性にすることは
> あるけど、そういうのは基本を踏まえた上での小手先のテクニックとして
> ソースにコメントをつけながらやることであって、できるだけ基本は
> 守っていた方がいい事が多い。
すまん、膨大な繰り返し処理って具体的にはどんな業務ロジックなんだ？
想像できんので教えてくれ。
0388デフォルトの名無しさん
NGNG>>381に伝わらなかったってだけじゃないの。
ttp://www.martinfowler.com/bliki/PublishedInterface.html
まあﾏﾀｰﾘ行こうや。>>387
0389デフォルトの名無しさん
NGNGNHKみてなかったの？かわいかったのに。
「NHKスペシャル地球大進化 生命の巨大化」の枠でやってたから、巨大化ってパンダのことかーっ、と思いながらみてますた。
0390デフォルトの名無しさん
NGNG0391デフォルトの名無しさん
NGNGmethod.getReturnType().isAssignableFrom(List.class)
↓
List.class.isAssignableFrom(method.getReturnType())
じゃないか？
0392デフォルトの名無しさん
NGNG比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても影響ないってことだろ。
039344
NGNG>もともと永続化されるデータ、テーブルで管理されるようなデータ
>というのは、その構造は、ER図などで外部に対して公開されています。
>
>一般的に言われるようなカプセル化の話は当てはまりません。
外部の意味が曖昧なので推測で。
ここでい言う「外部」が
>>392
>比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても
>影響ないってことだろ。
ということであれば、それでもなお、カプセル化の話は当てはまると思います。カプセル化さえされていればクラスの内部で、Extract Classした先への委譲でも、Replace Type Code with State/Strategyでも、なんでもやりたい放題できますから。
また、「外部」が外部システム等であったとしても、若干の不自由は強いられるかもしれませんが、それでもなお上記の理由でカプセル化する利点は存在すると考えます。
0394デフォルトの名無しさん
NGNGこのスレ荒らしてあげて下さい。
ウイルス貼りまくっていいですよ。
歓迎します。
039544
NGNG>補足しておくと、ドメインモデルは、もともとデータを持ってる
>クラスに振る舞いを持たせたほうが良いという観点なはずです。それが、
>
>public class Employee {
> private PayCaluculator calculator;
> ...
> public BigDecimal caluculatePay() {
> return calculator.calculatePay(this);
> }
>}
>
>という形だということは、役割でクラス分割するのと実質同じです。
Extract Classは以下のように行うので
http://www.refactoring.com/catalog/extractClass.html
PayCaluculatorクラスができることはありませんです。
0396デフォルトの名無しさん
NGNG> すまん、膨大な繰り返し処理って具体的にはどんな業務ロジックなんだ？
> 想像できんので教えてくれ。
業務ロジックかどうかは微妙だけど java.awt.Point数万個を使うようなグラフィック処理。
あと、石油埋蔵量予測システム。(どっかで読んだ)
0397デフォルトの名無しさん
NGNGサンキュ。そういうやつか。俺の仕事では出会うことは無さそうでほっとした。
0398デフォルトの名無しさん
NGNGMAIN─Seasar─dicon
│
├クラスＡ
├クラスＢ
├クラスＣ
└クラスＤ
「SeasarとはクラスＡ－Ｄの纏め役で、どれを使うかdiconに
書いておけば、そのクラスを返してくれるもの。」
という理解で合ってる？ドキュメントを１ヶ月ほど読み耽って
やっとこ辿り着いた答えがコレだったんだけど・・・・・・
0399デフォルトの名無しさん
NGNG0400デフォルトの名無しさん
NGNGひがさんが問題としていることは、OOSEでも取り上げられているから。
0401デフォルトの名無しさん
NGNG0402デフォルトの名無しさん
NGNG0403デフォルトの名無しさん
NGNG>その原因は、過度なデータ中心のクラス設計にあると私は考えています。
>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。
OOSEのP120~P129はその答えとなりませんか?
0404デフォルトの名無しさん
NGNGちょっとコードを書けばすぐにわかると思うんだけどね。
最近はドキュメント読んだだけで済ませようとする人が
多いのでびっくりだ。
0405デフォルトの名無しさん
NGNG>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。業務アプリケーションなどはとくそうで、
>直接関係のない機能が1つのエンティティに押し込まれやすくなります。
そうなった場合に適宜リファクタリングしてやれば解決する問題だと考えます。
>また、複数のデータにまたがるような機能は、そもそも適したクラスに
>振る舞いを割り当てるのが難しくなります。
複数のデータにまたがるような機能が全てそうだとは言いませんが、どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ割り当てれば良い、と古のOOSEに記されています。そのことには異存ありません。
# UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが
データと振る舞いをひとつのクラスにまとめる。責務が多くなりすぎたらクラスを分割してやる。振る舞いを割り当てるのに適したクラスが無い場合はコントローラクラスとする。これでも駄目なのでしょうか?
0406デフォルトの名無しさん
NGNG読む人のせいにする筆者
0407401
NGNG最新版のドキュメントは、昔と較べると段違いに充実していると思う。
# S2JSFのドキュメントがないのは、正式公開前だし、しかたないだろう。
まさたかさんの入門記事も参考になる。
http://d.hatena.ne.jp/masataka_k/searchdiary?of=15&word=%2a%5bseasar%2dtutorial%5d
（もしかすると若干記述が古くてハマるかもしれん）。
俺はS2財団の人ではない。単なるファンだ。
だが、煽りが出たらごめん。> やすを氏ほか。
あと技術的な話をしているところを、側面的なネタで汚してすまん。
0408デフォルトの名無しさん
NGNGそうですか・・・・・・やっと、やっとここまで辿り着きました(;´д⊂ヽﾋｯｸﾋｯｸ
>>404
ぶっちゃけその通りです＞ドキュメント読んだだけで済ませようと
「Seasar = フレームワーク」と勘違いして、「クラスを切り替えられるのは分かったから、それ
で最終的にはどうなるんだ？」という明後日な視点でドキュメントを読み続けてました。
髭剃りを他の何かだと頑なに信じ込んでしまってる人が、説明書を見ながら「髭が剃れるのは
分かったから、最終的にどうなるんだ？」と途方に暮れてる姿を想像してもらえれば近いので
はないかと・・・・・・
勿論、結論は「だから髭が剃れるんだよ」というものなんですが、見てる方向が違うと辿り着け
ないんですね、これが＿|￣|○|||
最後に、とりあえず現在のところドキュメントに不満はありません。
目は何も見てはいない、見ているのは脳。という言葉をちょっぴり実感した年末でしたｗ
0409デフォルトの名無しさん
NGNG>複数のデータにまたがるような機能が全てそうだとは言いませんが、
>どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ
>割り当てれば良い、と古のOOSEに記されています。
>そのことには異存ありません。
> # UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが
余談ですが、昨今の、ロバストネス分析で導出されたコントロールクラスは設計モデルでそのままストレートにクラス化すべし、という風潮はあまり好きになれないです。
某オブジェクト指向本も読んでみたんですが、ドメインモデル貧血症推奨な感じで、なんだか。
RUPの人もICONIXの人も、分析段階でのコントローラクラスの責務はバウンダリかエンティティに割り当てる、もしくはコントローラ自体をクラス化する、と言ってるように思うんだが。
というか、スリーアミーゴはICONIXの人よりもきつい言い方をしてて
「コントロールクラスを実現するのに別々の設計クラスを用意するのは
適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」
と言ってるのだが。
0410デフォルトの名無しさん
NGNGS2Daoもここのところリリースが多かったですが、追加したあのテーションとかも
ちゃんとドキュメントに反映されてるし。
0411デフォルトの名無しさん
NGNG>「コントロールクラスを実現するのに別々の設計クラスを用意するのは
> 適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
> 実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」
原文を知らないので良くわからないのだけど、それってStrutsで言えば、
Action内で直接エンティティにアクセスするってことかな？
0412デフォルトの名無しさん
NGNG0413デフォルトの名無しさん
NGNG0414デフォルトの名無しさん
NGNG0415デフォルトの名無しさん
NGNG> blogに、これまでのオブジェクト指向の批判を書くのは、
> 私にとってはものすごくリスクの高いことです。なにを
> 言われてもおかしくないですから。現にいろいろ言われ
> ているわけですが、それでもあえて書いているのは、こ
> れまでのオブジェクト指向がなぜうまくいっていないの
> かを考え直すきっかけになればと思っているからなのです。
「これまでのオブジェクト指向」の定義と
「うまくいっていない」とする根拠を明確に示さないとただの
戯言．今までにない自分が始めて見つけた設計方法と認識して
いるならば非常に痛い．自らの失敗経験や知りえる範囲での失
敗を踏まえた程度ではないのか．
0416デフォルトの名無しさん
NGNGOO厨ｷﾀｰ！
0417デフォルトの名無しさん
NGNG同じコトをファウラーﾀｿにも突っ込んでやってくれ。
http://www.nri-aitd.com/tips/image/g-patern_4.gif
は根拠が薄弱すぎるとひが氏なんかよりも罪深いぞ。
特に線の交差するところは重要じゃないか？
SQLのあまりにもな例といい結構ファウラーﾀｿも危ういと感じる。
0418デフォルトの名無しさん
NGNGいいんだけど、ファイル名が怪しい
0419デフォルトの名無しさん
NGNGムリだってことがハッキリしたと思う。
これ以上ソフトウェア開発を効率化しようとするなら、
例えば業務会計ソフトなら、会計ソフトをプラグインで柔軟に変更可能にするとか、
そのAPIをソースコードごと公開するとか、
そういう、実装が伴ったものになると思う。
EJBのようなアプリケーション固有の実装を伴わないフレームワークは必要無い。
0420デフォルトの名無しさん
NGNG0421デフォルトの名無しさん
NGNGわからん
前提があるからどうなんだ？
0422デフォルトの名無しさん
NGNGDI + II まだー？
0423デフォルトの名無しさん
NGNGフレームワークやパターンや開発手法を共有するしかない、ということ
0424デフォルトの名無しさん
NGNGPhotoshopやEclipseはどうなんだ？
プラグイン毎にソフト作り直すのが現実的なのだろうか
業務ソフトだってその考え方をもっと進めなきゃいかんと俺は思う
0425デフォルトの名無しさん
NGNG未だ存在しないから、せめてムダなフレームワークを使わず
ただシンプルに作り抜くことが、今できることなんだろうと思うけどね。
0426デフォルトの名無しさん
NGNG原文読め
自分がネタにマジレスってことに気付くから
0427デフォルトの名無しさん
NGNGベースを作ればあとは付加機能でしかないという分野以外で、同じようにプラグインの仕組みを考えるのはナンセンスだと思うが。
やっても意味がないという結論がでるようなことがらについて考えを進めても意味がなさげ。
0428デフォルトの名無しさん
NGNG> 手を変え、品を変え、オブジェクト指向は説明されてきましたが、情況はそれほど好転しているように思えません。
続く文章も、手を変え品を変えたオブジェクト指向の説明に見えるので、状況がそれほど好転しない気がする。
0429デフォルトの名無しさん
NGNG確かに、同じようなプラグインの仕組みは、やるだけムダなのかもしれないし
けど、うまく設計すれば、うまくいくかもしれない。
設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。
S2やEJBは何の解決にもならないのは確か。
ならシンプルな技術基盤で作りたいね。
Javaを使ったウェブプログラミングがめんどくさいからいろんなフレームワーク
がでているわけで、なら別のプラットフォームを選ぶのがいいと漏れは結論した。
結果を出せるのはスクリプト言語だなと思ってる。
0430デフォルトの名無しさん
NGNG>設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。
なんだよ、他人事かよ・・
0431デフォルトの名無しさん
NGNG何か新しい業務が埋め込まれたら、既存の業務に必ず変化があるし。
Plugableにするために工程とかプログラムの部分部分がちょっとでも複雑になるなら、普通にシンプルに作って、わかりやすく変更できるようにした方がよさげ。
0432デフォルトの名無しさん
NGNGプラグイン機構を持ったソフトを売るか、それ自体を使ったソリューションビジネスを始めようってんでも
ない限り、そういう先を読んだ拡張性を重視するのは、危険だな。
You aren't gonna need itの原則だ。
まさに、普通にシンプルがよさげ。
まぁ、プラグイン機構を持つのに向いている分野もあれば、向いてない分野もあると思う。
向いている分野も結構あると思うんだけどね。
0433デフォルトの名無しさん
NGNG0434デフォルトの名無しさん
NGNG皆さんネタ厨に餌を与えないでください。
0435デフォルトの名無しさん
NGNG多分、無知だからだと思うんだ。
だから、スクリプト言語によるウェブシステム構築よりSeaserで作ったほうがイイ点、
勝ってる点を教えてください。
0436デフォルトの名無しさん
NGNG規模とか開発の人数によるよ。
スクリプト言語よりもJava+Seasarの方が、均質なコードを書くための労力が少ない。
均質なコードを書く労力が問題なければ、スクリプト言語でいいと思う。
0437デフォルトの名無しさん
NGNG0438デフォルトの名無しさん
NGNG0439デフォルトの名無しさん
NGNG感じだったような。今はどうであれ、先の事はわからない。
0440デフォルトの名無しさん
NGNG0441デフォルトの名無しさん
NGNG>440
だから、それはなぜかを示してほしい
0442デフォルトの名無しさん
NGNGJavaプログラマは素人。
よって、Javaプログラマには基幹系は無理。
以上。
0443デフォルトの名無しさん
NGNG二番目が根拠無し
0444デフォルトの名無しさん
NGNG別のとこでやってくれ。
0445デフォルトの名無しさん
NGNG0446デフォルトの名無しさん
NGNG均質っていうけどなぁ、
均質にするのは方法論であって。
その方法論を実現するのには、コンパイルに依存しない
弱い結合が必要だっていうから、Seaserがあるわけでしょ。
コンパイル依存をなくしたいと思って行きつくところは、
動的なスクリプト言語ってことにならないだろうか？
それに、O/Rマッピングとか、ソフトウェアを複雑にする要因を
増やしてもしょうがないと思う。
0447デフォルトの名無しさん
NGNG実装との依存性はなくしたいだけど、
仕様(interface)との関係は明確にしたい。
仕様に合致してるかどうかはコンパイラにチェックして欲しい。
O/Rマッピングは関係無いと思うけど。
S2Daoの話なら別に複雑じゃないよ。
0448デフォルトの名無しさん
NGNGしかし、キャスト要らずのコードにするために、
あのdiで書かれた設定ファイルが必要になるわけで、
どっちにしろ動かしてみるまで分からないのは一緒だと
思うのだけど、どうだろうか。
それに、あのdiファイルってすごく冗長で書くの辛いしツール要るしで、
なんか本末転倒感が強い。
0449デフォルトの名無しさん
NGNG0450デフォルトの名無しさん
NGNGプラグイン機構を持ってもしょうがない、
ってな話あるけど、必ずしも、
そうでもない気がする。
ERPソフトの全てがネタだとは思わないし、
適切なインターフェースさえ定義して
そのインターフェースAPIの意図を素早く読み取って
プラグイン作る人さえそろえば、
少ない労力で結果として効果の高いソフトが作れると思うよ。
0451デフォルトの名無しさん
NGNGS2は特にそうだ。
0452446,448,449,450 ◆iKwMOjCT4s
NGNG言語本来備わっている名前空間機能ではいかんのか？
と思うわけだな
0453デフォルトの名無しさん
NGNG0454デフォルトの名無しさん
NGNG> 適切なインターフェースさえ定義して
> そのインターフェースAPIの意図を素早く読み取って
> プラグイン作る人さえそろえば、
> 少ない労力で結果として効果の高いソフトが作れると思うよ。
そうだな。早く藻前がそれを作って公開すればみんなそれがどれくらい素晴らしいか理解できると思うよ。
とっとと作れ。
0455デフォルトの名無しさん
NGNGまた、使ってないやつがコメントしてるのか。
S2は自動バインディングがほんとだから
DIについてはクラスの登録以外はあまりすることがない。
Springの設定ファイルについて文句あるなら、
Springすれでどうぞ。
0456デフォルトの名無しさん
NGNG0457デフォルトの名無しさん
NGNGビジネスモデルも柔軟性があり、いい発想だ。
しかし、ドメイン分析をまともに出来る奴がいねーのは問題だわな。
巷にはノウハウ本が溢れているが、だーれも読んでねーってことだ。
読者がアホなのか、執筆者がアホなのか。
まぁ、後者だろう。
0458デフォルトの名無しさん
NGNG> 読者がアホなのか、執筆者がアホなのか。
> まぁ、後者だろう。
○ージス総研と○蔵に通報しますた。
0459デフォルトの名無しさん
NGNGつうか、日本でドメイン分析をまともにやったプロジェクトはないだろ。
あるなら教えてくれ。
まぁ、未経験者の執筆した本でも趣味でやってる奴には楽しめるかもしれん。
0460デフォルトの名無しさん
NGNGもし仮に、diconをポトペタできる様なRADツールを作るとして、実現可能性はどれくらい
あるか？
または既にそういったツールが有るのか否か、情報提供キボーン
0461デフォルトの名無しさん
NGNGこんな年の暮れに何をかいとんねん。
もう新年だけど。
diconをぽとぺたする意味が良く分からん。
ツールならKijimunaはけっこう良くできてるよ。
0462デフォルトの名無しさん
NGNGなにはともあれ、今年もIT屋さんとしてがんばっていこうではありませんか ;-)
0463デフォルトの名無しさん
NGNG自動バインディングのために、クラスに定数定義したり、
やっぱりxml書かなきゃいけなかったりする。
そこまでする理由ってのが、どうにも見つからないんだな。
結局、Javaプラットフォームがプログラミングしづらいから、
なんとかカバーしようとしているだけとしか思えない。
0464デフォルトの名無しさん
NGNG0465あなたの運勢は 【ぴょん吉】 ですから!!残念っっ!!
NGNG0466デフォルトの名無しさん
NGNGいや、漏れが一番知りたいのは、
Seaser作る人使う人が
ウェブ／データベースプログラミングをJavaでやると選択した理由なんだよ。
漏れの知らない深い理由があるのではないかなと。
0467デフォルトの名無しさん
NGNG・CGIは力不足
・mod_{perl,ruby}は挙動が怪しいときに追うのが辛い
・PHPは言語仕様が糞
あとは別ﾇﾚでどうぞ
0468デフォルトの名無しさん
NGNGモチツケ
0469デフォルトの名無しさん
NGNG実は俺>>391なんです。
Kijimunaの存在自体知りませんでしたorz
ただ、それはそれとして、設定ファイルを書くのが面倒という意見が多いんで
工夫できないものなのかな？工夫する為のツールは存在しないのかな？存
在はしてるけど認知度が低いのかな？認知されてるけど機能が足りてない
のかな？等々、現状どうなってるのか不思議に思ったものでネタ振りしたつ
もりだったんですが・・・・・・スベっちゃいました。
「手書きが面倒」という感覚は、ある種の人達(例えばLinux畑の人達とか？)
にはどう説明しても理解してもらえないんで、もしかしたらSeasar使いの人達
もその類の人達なのかと思ったんですが・・・・・・
実際のとこ、どうなんでしょう？
0471デフォルトの名無しさん
NGNG積極的に選ぶ奴もいれば仕事上仕方なしに使う奴もいるさ。
理由はそれぞれ。Javaを使うと決まったときに少しでも楽するために
S2を使うだけだ。気にしないでキミは自分の道を行くのが良かろう。
0472デフォルトの名無しさん
NGNG手書きが面倒だからといってVBみたいになれば楽かというとそうでもなかろう。
少なくともKijimuna使ってる分にはそんなに苦労はしてない。
0473.net厨のお年玉は 【1519円】 でした
NGNG0474469
NGNG「そんなに苦労はしてない」この言葉にはとても多くの意味があって・・・・・・
例えば、Linuxのlilo.confは手書きです。これは設定ファイル自体が非常に
単純で、GUIエディタを作るまでもないというのがLinux畑な人達の言い分な
んだと思うんですが、一方でグラフィカルなブートマネージャに対する人気
は凄く高いという側面もあります。
決して批判してるわけではないんですが(批判できるほどSeasarを理解でき
てませんorz)、使いこなしてる人ほど見えなくなる部分みたいなんで一石を
・・・・・・MSはそういうとこ上手いと思う。
て言うか、俺自身が更にSeasarやEclipseを学んで、ポトペタdiconプラグイン
for Eclipseとかを作れる様になればいいんですけどね・・・・・・遠いなぁ（´д｀；）
0475デフォルトの名無しさん
NGNG> mod_{perl,ruby}は挙動が怪しいときに追うのが辛い
これは、例えば、どういうとき？
0476デフォルトの名無しさん
NGNG私は手書き派ですが、diconファイルをクラスごとに用意してます。それでパッケージ単位でインクルードしたdiconファイルを用意していて、サブシステム単位でそれをインクルードして、さらに全てをインクルードしてます。
で、GUIでこれを出来たら楽という考えを持っています。その一方で、テスト用のdiconファイルを作っているのでそれを任意に出来るようなGUIが想像できないです。そこら辺のイメージが湧かないとGUIの評価も出来ません。
システムは多数の人間で開発するものですので、自分の変更がほかの人に迷惑をかけないようなファイル分割や、チェック方法や、排他方法を望みます。
それが可能ならGUIでもいいんですが。
0477469
NGNGごめんなさい。書き込み内容の1/10も理解できませんorz
イメージとしては、GraphEdit(DirectShowFilterの接続をグラフィカルに
設定するMS製ツール)なんですが・・・・・・
dicon用GUIエディタをGraphEditの様なUIで表現可能なのかどうかが
先ず分かりませんorz^256
0478デフォルトの名無しさん
NGNG十分に存在価値はあると思うんだけど。intercepter機能を一切使わなくてもね。
PHPはもうちょっとオブジェクト指向面で実績ができてからかなあ。
あと何でも連想配列でなんとかしていくのも俺は気持ち悪い。
Bean書く手間をかけても、そっちのほうがいい。それが俺のJavaを選んだ理由かな。
0479デフォルトの名無しさん
NGNG完全クラス名を取得して自動的にdiconひな形作成して、GUIでプロパティ設定とか、
コンストラクタ設定とか、インターセプターとか設定できるようにすると面白そうだと
思う。
実現可能性（誰が作るのかとか）をとっぱらって考えると、こういうツールは敷居を
下げてくれるし、重要な要素だと思うよ。手書きで間に合ってる人はいらんだろうけ
ど、手書きXMLに敷居を感じる人間もいるわな。すそ野を広めようと思えば考慮す
る価値はあるよね。
俺はdicon手書きでもkijimunaでそれほど困ってないけど、正直GUIツールがあったら
便利だと思うね。チームの連中にdiconの概念を説明する手間が若干省けるし。
0480469
NGNG寧ろintercepter機能(S2AOPの事ですよね？)が使いたくてSeasarを追
っかけてます。まぁ、逃げられっぱなしなわけですがorz
例えば、今は単純なベタテキストのログを出力してるけど、将来的には
XMLで出力したい、いやいっそSYSLOGdへ出力したい、まてまてHTML
で出力してWEBブラウザで見るのも捨て難いぞ等と考えた時、それ用
のクラスを書いてdiconを編集するだけで、色んなログの出力が実現で
きるのだとしたら、とても便利そうだぞと、思ったんですが・・・・・・・
もっとも、この発想自体が間違ってる可能性も大アリなんですが（´д｀；）
0481デフォルトの名無しさん
NGNG読み込み順とかも重要だから難しいかなぁ。
0482デフォルトの名無しさん
NGNGその発想は間違ってないけど、すでにApacheのLog4Jで実現されてるので
そっち使った方が早い。Log4JはSeasar自身も使ってるし。
0483デフォルトの名無しさん
NGNG0484デフォルトの名無しさん
NGNG＞Seasar3はJ2EE Development with EJBなのです。
( ´_ゝ`)ﾌｰﾝ
Seasarいらねじゃないの？
結局EJB最強ってことか
0485デフォルトの名無しさん
NGNG0486デフォルトの名無しさん
NGNG漏れはアンチSeaserだが、
バージョン間の互換性問題はどこの世界にもある話。
PHPは本当に酷かった。
0487デフォルトの名無しさん
NGNGだから、リファクタリングの原則だ。
これができてればバージョン上げるくらい楽勝だ。
0488デフォルトの名無しさん
NGNGバージョン間の互換性というより、根本的に考え方が違う。
-Seasar3がでたらSeasar2どうなる。メンテナンスするの？
-今開発中のS2*シリーズは影響受けないのか？
あたりが気になる。
ttp://d.hatena.ne.jp/higayasuo/20050102#1104650907
のコメントを見ると、取り巻き達もこの件は知らなかったの？
S2マンセーな方々がどういう反応するかな？
0489デフォルトの名無しさん
NGNG0490デフォルトの名無しさん
NGNG売りであるS2Daoが全然変わっちゃいそうだから
リファクタリングというより作り直しになっちゃいう。
0491デフォルトの名無しさん
NGNG＞Seasar3は、Seasar2とは全くコンセプトが異なるので、基本的に互換性はありません。
＞でも、Seasar2を使われている方は、心配する必要はありません。
＞Seasar2は、今後も開発を続けます。J2SE5にも対応します。
＞今後も主力は、Seasar2 + S2ファミリーということになります。
あ～やっぱり。そうなるとS2/S3の２系列になる。それも悩ましい。
0492デフォルトの名無しさん
NGNG0493デフォルトの名無しさん
NGNGドメインモデルもビジネスモデルもちゃんとした定義なんてないと思うよ。
もしかして、DDDの定義がちゃんとした定義だと思ってるとか。
0494デフォルトの名無しさん
NGNGドメインモデルもシステム化対象となる問題領域を捉えるためのモデル
という理解ではだめか？
0495デフォルトの名無しさん
NGNGそれは、それで違和感ないけど、みんないってること違うからね。
いまのところしょうがないんじゃないかな。
ファウラーたんがきちんと定義してくれたらそれがデファクトになるかもね。
ただドメインモデルの定義も
http://martinfowler.com/eaaCatalog/domainModel.html
でいいのかなぁって気も。
0496デフォルトの名無しさん
NGNGつまりSeasar3が作られたとしても、使うメリットは少ないってことだな。
Seasarという名のもとに違うコンセプトのものが語られて、開発リソースの分散と混乱をまねくだけまねいてあぼん、か。
先が見えたな。
0497デフォルトの名無しさん
NGNG藻前は、Seasar2もつかってないんだろうから、Seasar3も使わなくて良いよ。
ちなみに、Seasar2がでたときも、Seasar1と全く違うコンセプトのものだったよ。
0498デフォルトの名無しさん
NGNGひがさんの言ってるビジネスモデルは「業務フロー」(ビジネスフローとでも言えばいいか)。
業務フローのなかで特有のモデルがドメインモデル。
常識的な範囲で、ビジネスモデルは儲ける方法のことだし。
煽り抜きで、ちょとがっかりした。
0499デフォルトの名無しさん
NGNGそのときは、Seasar1を捨ててSeasar2に移行したわけだろ。
まるっきりコンセプトを変えた新版を出して、旧版はそのまま継続って、そしたら新版使う理由なんかないよ。
開発リソースも限られてるわけだし、どっちかに偏らざるを得ない。
S2に偏るならS3は縮小していくし、S3に偏るなら移行のタイミングを与えられないままS2の利用者も減っていく。
違うコンセプトで同じ名前の２つのプロダクトを、混乱しないようにプロモーションする力があるようにも思えないし。
0500デフォルトの名無しさん
NGNG>ビジネスモデルとは、実際におこなっている業務、あるいは
>これからおこなおうとしている業務の形態・仕組みを指すこととします
といっているから、別に業務フローじゃないんじゃないの。
http://d.hatena.ne.jp/habuakihiro/20050103#1104733873
でいってる前者ってやつかな。
それによるとやはりちゃんとした定義はないということだけど。
それにしても、自分の考えと少しでも違うとまちがってると
いうやつが多いね。
2chだからそんなものだが。
0501デフォルトの名無しさん
NGNG0502デフォルトの名無しさん
NGNG0503デフォルトの名無しさん
NGNG禿胴。S3なんてことしなくてもS2EJB3でいいじゃんと技術に疎い漏れが逝ってみるﾃｽt
0504デフォルトの名無しさん
NGNG> 開発リソースも限られてるわけだし、どっちかに偏らざるを得ない。
> S2に偏るならS3は縮小していくし、S3に偏るなら移行のタイミングを与えられないままS2の利用者も減っていく。
これはSeasarの開発陣の少なさを考えると杞憂とは言い切れんな。
取り巻き/応援団は結構多そうだが、実質開発リソースは１人だからな。
まぁ二兎追うものは(ry
0505デフォルトの名無しさん
NGNGところ）だけ物理的に別サーバに写そうと思ったらどうしたらいいのかな。
EJBだとJNDIとRemoteHomeとでリモートでのメソッド呼び出しに対応できそうだけど、
たとえばStruts+S2で稼働してたとして、負荷が高くなってきたのでS2で作ったサービス
層を複数サーバにして、合わせてStrutsのプレゼンテーション層と物理的に分離しよう
としたとする。どういう方策があるだろうか。
おれがちらと考えたのは、Struts -> EJB -> S2 というように、間になんかリモート呼び出し
に対応した層を挟むしか思いつかないんだけど。
0506デフォルトの名無しさん
NGNGそこでS2Remotingですよ。
0507デフォルトの名無しさん
NGNG一向にリリースの気配がないようだけど。
0508デフォルトの名無しさん
NGNGWebコンテナごと横に並べればいいじゃん。
0509デフォルトの名無しさん
NGNGプレゼンテーション層とサービス層とDBを物理的に分離したい、と言われることは
十分あり得ることだろう。というか別件で言われたんだよ。そういうときS2ならどうなる
のかな、と。
0510デフォルトの名無しさん
NGNGS2がDI+AOPで生まれ変わったのは素晴らしかったと思う。
S3はDI+AOPを捨てさるような新しい何かを考えてるんだろうか。
漏れにはどうもS2の作り直しにしか見えないので不安だ。
0511デフォルトの名無しさん
NGNGそこまで分離したほうがいいシステムって、
どういうもんかなと思ったんだが。思いつきで言ってるというか、
システム派手にしたいだけな臭いがしてくるんだけど。
Rubyのtuple spaceの実装例はけっこう感動した。これを使えば
物理的にネットワークに繋げれば自動的にサーバ同士が連携して処理速度上げたり
クラスタリングのやり始めたり、というカッコイイことも可能だ。
そんなことやったほうがいいような機能を求める顧客には、会った事はないが！
0512デフォルトの名無しさん
NGNGハードをたくさん売るために決まってるだろｗ
0513デフォルトの名無しさん
NGNGで、顧客は次にこういうのだ。
「ハード一台で済むシステム作れないかな。台数少ないから、予算は前の1/4で」
こういう素人を超えたITオンチが今のシステム屋を支えているのだ
なんのために生きてんだろ！
0514デフォルトの名無しさん
NGNGDBさえ多重化していれば良いという程度のシステムばかりではないんですよ．
0515デフォルトの名無しさん
NGNGはぶのいうことは話半分で聞いたほうが良いよ．
ttp://www.atmarkit.co.jp/aig/04biz/businessmodel.html
0516デフォルトの名無しさん
NGNGはぶ氏のも曖昧な中のひとつの自説ということじゃないだろうか。
0517デフォルトの名無しさん
NGNG0518デフォルトの名無しさん
NGNGそこまで戻って話をせにゃならんのか？
でもまぁ、身のある話をするにはそうなのかもしれないな。
でかい声で言ったもん勝ち、それを分かった気になったもん勝ちな業界だし。
0519デフォルトの名無しさん
NGNG0520デフォルトの名無しさん
NGNG0521デフォルトの名無しさん
NGNG「別系列」ってゆーけど、S2=前Version=時代遅れ、と認識する人が多いだろう。
しかも、順調に行けばGW明けにそうなる。
そーゆーS2をこれからもメンテする献身的な人がどれだけいるか疑問だ。
http://d.hatena.ne.jp/habuakihiro/20050104#1104805780
＞Tiger対応とS2JSFリリースは、S3に関係なく最優先でお願いしたい事項です。
本音だろうな。他に頼む人いないし。
＞この辺は主としてマーケティングの話になってくるんでしょう。
ぷっ。
0522デフォルトの名無しさん
NGNGそれが技術的なものかどうかは知らないが。
0523デフォルトの名無しさん
NGNGEJBは分散技術だし。
EJBが提案されたときは、分散システムが主流になると思われてた。
実際には、分散が必要になるシステムは、非常に限られていたってことだ。
0524デフォルトの名無しさん
NGNG0525デフォルトの名無しさん
NGNGbusinessという英語を外来語として日本語化したときに、胡散臭さが付け加えられてしまったからな。
システムとかエンジニアとかSEとかマネージメントとかDIコンテナとか、似たような例はたくさん。
0526デフォルトの名無しさん
NGNGまああってるかもしれん。
0527デフォルトの名無しさん
NGNG0528デフォルトの名無しさん
NGNG0529デフォルトの名無しさん
NGNG「J2EEにフィードバックすること」なのかな。
0530デフォルトの名無しさん
NGNG0531デフォルトの名無しさん
NGNG毛唐のやつらは 複雑なこと VS. 簡単なこと
をポリシーなく立場を入れ替えながら争うのがそもそも好みですから．残念
0532デフォルトの名無しさん
NGNG0533デフォルトの名無しさん
NGNGもしくは
人の仕事というのは趣味の延長でしかない
0534デフォルトの名無しさん
NGNG誤爆か？
0535デフォルトの名無しさん
NGNG誘爆かと。
ttp://d.hatena.ne.jp/habuakihiro/20050105#1104915865
0536デフォルトの名無しさん
NGNG0537デフォルトの名無しさん
NGNG0538デフォルトの名無しさん
NGNGの図を妄想してる輩はBloglinesを知らないんだろうか。
まさか。
0539デフォルトの名無しさん
NGNGスレと関係ないことまでいちいち書き込むあたりが怖いってことだろ。
>>533がストーカーかかまってくんか追っ掛けか知らないけどな。
0540デフォルトの名無しさん
NGNG彼はNIFTYのフォーラムにはまっていた頃からはったり雑学やろうでくちばっかりの
男でした．
>> 某スレ
酔うと伝票めくりをしていた時代からの成り上がり話をぐたぐた話すのは
いつもの十八番だ．たしかにうざい．
0541デフォルトの名無しさん
NGNG句読点までこだわるとは、
手の込んだことをおやりになる。
0542デフォルトの名無しさん
NGNG一緒に飲んでるんだw
その場で説教してやれ
はぶｦﾁでｽﾚと関係ない
こと書くなｳｻﾞｲ
0543デフォルトの名無しさん
NGNGだれか適当な聞き役をあてがって、その場を去るのが無難だね。
0544デフォルトの名無しさん
NGNG0545デフォルトの名無しさん
NGNGS2周りの人大変だな。
0546デフォルトの名無しさん
NGNG0547デフォルトの名無しさん
NGNGまだしょぼしょぼだから仕方ないのかも知れんが、現状のS2AOPの程度では、
お子ちゃまみたいなログ取りインターセプタか、トランザクション管理
くらいにしか使えない。
AOPはその程度でいいんだ、っていうならそれでいいんだけど・・・
0548デフォルトの名無しさん
NGNG0549デフォルトの名無しさん
NGNGその程度で済ましとかないと保守不能になる。
0550デフォルトの名無しさん
NGNGどこでなにが起きるか把握するだけで疲れそう。
0551デフォルトの名無しさん
NGNGttp://www.theserverside.com/articles/article.tss?l=AspectWerkzP1
0552デフォルトの名無しさん
NGNGどう強化されたらどんなことに使える?
0553デフォルトの名無しさん
NGNG読みながら、コワイコワイと思った。
0554デフォルトの名無しさん
NGNG必要な時にdiconを開いてみるだけで済みそうに思うんですが・・・・・・
大した使い方してないからそう思うのかもしれないけど・・・・・・
0555デフォルトの名無しさん
NGNG0556デフォルトの名無しさん
NGNG詳細ｷﾎﾞﾝ
0557デフォルトの名無しさん
NGNGねたにつられるなよ。
トランザクション制御は、AOPに向いてる代表的な機能の1つなんだから。
0558デフォルトの名無しさん
NGNGある処理で何が起こるか正確に把握するために、diconファイルのすべてに目を通す必要が出てくる。
0559デフォルトの名無しさん
NGNG0560デフォルトの名無しさん
NGNGttp://arton.no-ip.info/diary/20050103.html#p01
0561デフォルトの名無しさん
NGNGどこでどのオブジェクトにアスペクト仕込まれてるかわからなくなるから。
自分だけでコーディングするなら問題ないけどね。
0562デフォルトの名無しさん
NGNG適切にdiconファイルを分けておけば、「すべて」を見る必要はないような…？
まあ、あとはドキュメントとかコメントで対応するとか（アテにならん場合が多いけど）
0563デフォルトの名無しさん
NGNGオートインジェクションとか考えると。
適切に分けられてるかどうか確認しないといけないし。
ドキュメントは、コードがドキュメント通りになっているかの確認が。
自動的になにかするようなコードから追えないものは、オートインジェクションも含めて、コードを追うのが難しい。
0564デフォルトの名無しさん
NGNG管理手法の確立とそれの徹底をすればいいんだろうが、それだとコードとは
別なところに、全面的ではないにしろ大きく依存することになるわけだから、
それほそれで面倒な問題を孕むしな('A`)
管理とか保守をするのにソースコードとdiconファイルからインジェクションされてる
対象とその内容が簡単に視認できるようなツールがあるといいよなあ
まあ、漏れは今のところkijimunaで間に合ってるけど、AOPを非機能要件以外
のあれやらこれやらに使いたかったりするなら、保守の難しさが軽減されるような
何らかの仕組みなりモノがないとさすがにやってられないだろうな
0565デフォルトの名無しさん
NGNG> 保守の難しさが軽減されるような
> 何らかの仕組み
それは、Seaser非依存OOPプログラミングだ
0566デフォルトの名無しさん
NGNG現状に満足してるなら、別にそれでいいと思うよ。
0567デフォルトの名無しさん
NGNGなツリー状になる？
メンテナンスが大変な事になってるdicon一式(実際の場面に即したdiconなら
擬似サンプルでも良くてclassとかの本体は不要)公開してもらえないですか？
0568デフォルトの名無しさん
NGNGいまの時点でSeasarを使い込んでる人って、いろんなことをちゃんとわかってやってるだろうから、メンテナンスが大変なことになってるdiconってないんじゃなかろうか。
0569デフォルトの名無しさん
NGNG0570デフォルトの名無しさん
NGNG「巨大なツリー状」と「メンテナンスが大変なことになってる」が、つながらないんだけども。
0571デフォルトの名無しさん
NGNG「巨大なツリー状」と「メンテナンスが大変なことになってる」が、つながらないんだけども。
0572デフォルトの名無しさん
NGNGもう一層上で対応するのが自然だと思うが。
やるんなら、０、１のフラグだけだと使えん。
通常はnull値で、削除すると日時で更新されるようにならないと。
がんばってください。
0573デフォルトの名無しさん
NGNGそんな、革命的なものじゃないように見えるけど
モアベター程度に見えるし、ほとんどの人は普通のJSPや普通のJSFで充分な気がする。
0574デフォルトの名無しさん
NGNG「多くの人が実際の能力以上のことができると思い違いをしている。
誰でも、ポップスター、高裁判事、有能なテレビ司会者に
なれるかのように教師が教えているからだ」
チャールズ英皇太子
0575デフォルトの名無しさん
NGNG大したスキルもないくせにひが君と同等の立場で
語りたがるアンチへの嫌味ですか。
そうですか。
0576デフォルトの名無しさん
05/01/26 14:10:33必要な sql_quote がかかっていなくてsqlとして実行できないんだな。
sql がおかしいのかと思ってしばらくはまっちゃったぞ。
デバッグしにくいから、誰か気づいた人quote かけとくれよ。
おねげーしますだ。
0577デフォルトの名無しさん
05/01/26 17:30:36sql_quoteって何。
文字列ならシングルコーテーションで囲まれていた気はするけど。
0578デフォルトの名無しさん
05/01/26 20:20:510579576
05/01/27 13:41:56sql_quote ってのはあれだ、文字列の中にシングルクォートがあったら、
クォートしてくれるってことだ。
hoge'hoge -> hoge''hoge
そうしないと、sqlエラーになっちゃうだろ？
insert fuga(hoge) values ('hoge'hoge'); => era-
insert fuga(hoge) values ('hoge''hoge'); => ok-
0580デフォルトの名無しさん
05/01/27 15:07:19era-ってかわいいね
0581デフォルトの名無しさん
05/01/27 21:20:51バインド変数(/*hoge*/みたいな)を使えば関係ないんじゃないの。
0582デフォルトの名無しさん
05/01/27 23:19:300583デフォルトの名無しさん
05/01/28 08:02:30仕様をがんばって作って、しょぼい実装ができそうなことだけわかったけど。
0584デフォルトの名無しさん
05/01/28 21:34:06http://pc5.2ch.net/test/read.cgi/cg/1059565585/
0585デフォルトの名無しさん
05/01/29 02:12:15あ、それなら使ったことあるよ。
0586デフォルトの名無しさん
05/01/29 18:36:52関係が分からない。
関係者の方々説明たのんます。
0587デフォルトの名無しさん
05/02/03 21:56:06S2JSFってHTMLを売りにしてるけど
あれって拡張子が.htmlなだけで厳密にはHTMLじゃないよね。
サンプルで普通のHTMLまで変換されてたのが気になって．．．
あれは拡張子htmlでいいのか？
0588デフォルトの名無しさん
05/02/04 10:19:490589デフォルトの名無しさん
05/02/05 19:59:16普通のHTMLが変換されたらなんか問題あるの？
0590デフォルトの名無しさん
05/02/06 18:57:03http://pc5.2ch.net/test/read.cgi/tech/1092044210/571
>多少、建設的なネタを。ひが君 「cglib 遅せーから Javassist 使う」 とか言ってないで
>直接 ASM 使えよ。まー、バイトコードライブラリ作者は使う側のスキルはアテにしてないと
>思うけどな。
>
> 性能： ASM ＞ Javassist（初心者向け） ＞ cglib(初心者向けASMラッパー)
> ＞ BCEL ＞ SERP
で、実際にASM使ったら３割程度しか変わらんかったそうな。
0591デフォルトの名無しさん
05/02/07 23:06:040592デフォルトの名無しさん
05/02/08 23:02:21何もしないメソッドなんて動的コンパイル後実際に呼び出されているかどうかすら怪しい。
0593デフォルトの名無しさん
05/02/08 23:10:50ちょっと思い当たらないんだけど。
0594デフォルトの名無しさん
05/02/09 11:58:58べつに、純粋な呼出速度計らなくていいだろ。
比較できればいいんだから。
0595デフォルトの名無しさん
05/02/09 13:09:55>>592は、アスペクト有る無しで15倍違うという結果は怪しいってだけで本題じゃないんだ。
（とは言っても、Sunのクライアントコンパイラはそこまでやらないはずなので
以下のオーバーヘッドを除けば、まず正しいと思う。）
で、本題のCGLIBとASMの比較。
コンパイル前(1)、コンパイル(2)、コンパイル後(3)、全部纏めて測定しているのはどうだろうか。
俺は3だけ欲しい。が、これは体感値だと言われればぐうの音も出ない。
そこまで望むなら自分でやれと言われれば、いやあ御尤も。
0596デフォルトの名無しさん
05/02/14 21:56:300597デフォルトの名無しさん
05/02/14 21:57:010598デフォルトの名無しさん
05/02/15 10:36:16なんでSeasarプロジェクトで開発してるんだろう…
将来的にS2JSFの代わりに使うことを考えてるのかな？
そういうところがSeasarとMayaの関係がよくわからないという
状況を生み出しているような気がしないでもない。
0599デフォルトの名無しさん
05/02/15 12:04:05なにか開発してて、開発が進んでるらしくて、HTML吐くあたりで動くらしいということしかわからない。
まるでジンジャー
0600デフォルトの名無しさん
05/02/15 20:14:26>>584
0601デフォルトの名無しさん
05/02/15 23:03:410602デフォルトの名無しさん
05/02/16 03:51:57極度に乱暴に言うとTapestryのHTMLテンプレート部分+JSPのTaglib資産継承かな。
詳しくはまさたか氏のBlog(ttp://d.hatena.ne.jp/masataka_k/)の去年の11月末前後をチェックすべし。
0603デフォルトの名無しさん
05/02/19 10:41:060604デフォルトの名無しさん
05/02/19 17:08:580605デフォルトの名無しさん
05/02/19 19:00:20でも革命の初期ってそんなもんだろ？
俺はひがたんを信じているぜ！！！
0606デフォルトの名無しさん
05/02/19 21:00:040607デフォルトの名無しさん
05/02/19 21:14:560608デフォルトの名無しさん
05/02/20 02:20:42くーすはさらにミもフタもない。
ひが氏の英語はさらにミもフタもない。
0609デフォルトの名無しさん
05/02/20 02:49:59そういえば最近くーすってブログに書いてないね。
0610デフォルトの名無しさん
05/02/20 17:34:00なにもないよりは多少おかしくても英語情報があったほうがましだと思う。
日本のユーザも大切にして欲しいとは思うけどね。
0611デフォルトの名無しさん
05/02/20 18:51:590612デフォルトの名無しさん
05/02/20 18:58:57ミはなくないんだ。
0613デフォルトの名無しさん
05/02/20 20:09:43ここでの問題は、単に英語の練習というだけで情報が英語だけになったってことだ。
0614デフォルトの名無しさん
05/02/20 20:52:06MLには日本語でアナウンスすることになったから安心汁。
0615デフォルトの名無しさん
05/02/20 21:07:09練習だったんだ…。そりゃ失礼。
0616デフォルトの名無しさん
05/02/20 21:37:27MLに情報流しログも見れるからサイトには情報いらない、という考え方？あいかわらず。
0617デフォルトの名無しさん
05/02/20 22:06:48サイトって？
0618デフォルトの名無しさん
05/02/20 22:25:50で、そこから公式にリンクが張られてるseasar wiki。
最近のwhat's newには日本語での情報がない。
0619デフォルトの名無しさん
05/02/20 22:43:52614に書いてないだけ。
seasar wikiも日本語でアナウンスするらしいよ。
0620デフォルトの名無しさん
05/02/21 00:05:230621デフォルトの名無しさん
05/02/21 00:38:45「あとからゆっくり」のソースは？
0622デフォルトの名無しさん
05/02/21 00:40:500623デフォルトの名無しさん
05/02/21 01:20:34過去のはあとからゆっくりじゃなくてもう日本語にならないんじゃね？
明日以降、過去のが日本語化されたら622のおかげ。
0624デフォルトの名無しさん
05/02/26 23:49:100625デフォルトの名無しさん
05/02/27 00:10:45よくわからない。
TapestryともS2JSFとも違う、なんかのプレゼンテーション層フレームワークらしい
ことは分かるんだが。
0626デフォルトの名無しさん
05/02/27 01:09:04なんか、面白い機能を試すのにSeasar2が必要だし、Seasar2単体で試しても面白くないしで、壁が高い気がする。
0627デフォルトの名無しさん
05/02/27 01:21:320628デフォルトの名無しさん
05/02/27 01:59:50Jasperに相当するテンプレートエンジンだとか。
JasperはJSPを処理するけどMayaはHTMLを処理するのが違いだとか。
TapestryやS2JSFとの違いは、Mayaはテンプレートエンジンだけで
フレームワークではないということだと思ってる。
だから色々なフレームワークと組み合わせて使うことが出来るのだとか。
>>626
MayaはS2とは独立に使えることになってるはず。
WebWorkと組み合わせて動いたってレポートがあった。
どこかにSpringとも組み合わせられるとも書いてあった。
>>627
Webデザイナと協業しないとかWebデザイナがJSP大丈夫な場合はそれでいいかもね。
0630デフォルトの名無しさん
05/02/27 13:06:17そりゃSeasarの壁じゃなくておまいの「好奇心の低さ」と言う壁だべさ
0631デフォルトの名無しさん
05/02/27 14:00:55別にそれでもいいけど。
Seasar2自体には興味はないし。
他に同じようなことができるものがあるなら、そっち試すだけで。
0632デフォルトの名無しさん
05/02/27 16:37:090633デフォルトの名無しさん
05/02/27 16:45:27↓
おまえがクズ
↓
めんどう
↓
来なくていいよ
っていう流れ、好きだなぁ。
0634デフォルトの名無しさん
05/02/27 21:20:210635デフォルトの名無しさん
05/02/27 21:35:440636デフォルトの名無しさん
05/02/27 22:31:350637デフォルトの名無しさん
05/02/27 22:49:09もう公開されてるよ
早くなった実感がない
0638デフォルトの名無しさん
05/02/27 23:01:270639デフォルトの名無しさん
05/02/28 00:02:190640デフォルトの名無しさん
05/02/28 13:24:52宗教みたいになってきたな。
0641デフォルトの名無しさん
05/02/28 17:47:320642デフォルトの名無しさん
05/03/01 02:43:490643デフォルトの名無しさん
05/03/01 11:37:36無理。S2が必要。
0644デフォルトの名無しさん
05/03/01 13:06:48じゃあ、これ、どういうこと？
この文章見ると、S2JSFだけ使うなら、Tomcat4.1なら(他のライブラリなしに)動作するとも読めるんだけど。
というか、そう読んだんだけど。
0645デフォルトの名無しさん
05/03/01 14:13:39EA7まではJSP2.0に対応したWebコンテナ(例えばTomcat5.0)が必要だったけど
その制限が緩くなったってことじゃないか？
「S2JSF自体は」と書いているのは、組み合わせるJSF実装なんかに制限される
場合もあるからだろうね。
いくらなんでも「他のライブラリなしに」は補完しすぎw
0646デフォルトの名無しさん
05/03/01 14:39:14Tomcat4.1なら動くっていうのも、じゃあ動かないのは？って考えてJSP1.1で動かないのはどうでもいいし、JSP2.0では動かないってことか？とか。
いままでJSP2.0で動いててJSP1.2で動くようになったなら「JSP1.2でも」だろ、と。
というか、「S2JSF+Tomcat4.1+なんかcommons系」くらいでSeasar2なしで動くようになったのかと期待してみた。
0647デフォルトの名無しさん
05/03/01 15:11:07それくらい補完しなよ。
>というか、「S2JSF+Tomcat4.1+なんかcommons系」くらいでSeasar2なしで動くようになったのかと期待してみた。
それならMayaに期待しなよ。
つーか、そんなにS2外したいのか？
0648デフォルトの名無しさん
05/03/01 19:01:22それで補完したのが「他のライブラリなしに」だったのさ。
>>647
> つーか、そんなにS2外したいのか？
選択肢としてね。
0649デフォルトの名無しさん
05/03/01 19:41:560650デフォルトの名無しさん
05/03/01 20:15:40いや、選択肢のひとつとしてね。
S2JSFだったりMayaだったりNirvanaだったりJSPだったり、それをS2と組み合わせたりSpringと組み合わせたり、コンテナ使わなかったり。
いろんな選択肢を考えれるようにしときたいし。
S2必須なら、S2JSFが他に比べて卓越してない限り、S2を使う前提でしか選択肢にならないから。
0651デフォルトの名無しさん
05/03/02 01:15:27普通にS2が無いと動かないJSF実装を出すってのはどうなんだ。俺はダブルスタンダードに思えて
釈然としないんだが。
0652デフォルトの名無しさん
05/03/02 01:32:10S2JSFのアプリはPOJOだからS2に依存しないと思うよ。
0653デフォルトの名無しさん
05/03/02 01:46:35Maya使えば？
0654デフォルトの名無しさん
05/03/02 02:01:47S2JSFに依存するのはOKなのか。
0655デフォルトの名無しさん
05/03/02 02:15:41HTMLに独自属性を埋め込むページテンプレートはS2JSFに依存するけど。
0656デフォルトの名無しさん
05/03/02 07:31:08有名にさえなれば、類似プロジェクトとの比較なんてJava系雑誌がくどい位やってくれるだろうに
0657デフォルトの名無しさん
05/03/02 09:24:080658デフォルトの名無しさん
05/03/02 14:00:10POJOだから依存しないっていうのがねぇ。
POJOだから依存しないっていうのは、ソースコードレベルの話だけだ。
結局それなしでは動かせない。
0659デフォルトの名無しさん
05/03/02 17:14:12それを言い出すときりが無くない？
コンテナが無ければ動かせない、そもそもJavaのランタイムが無いと動かせないサーバが無etc.etc...
どのレベルまで依存を許容できるか、ってだけの問題にしかならない。
具体的にどうして欲しいのか言ってみなさいよ。
Struts→JSFのときみたいに実装と仕様を分けろってこと？
（S2の仕様だけ分離して、いろんな人が実装する…あ、それは面白いかもw）
または、Springでも動く(ってぐらい依存度の低い)S2JSFを期待してるのかしら。
それとも単にいちゃもん付けたいだけなのかな。
0660デフォルトの名無しさん
05/03/02 17:23:06何をいまさらｗ
0661デフォルトの名無しさん
05/03/02 21:16:36> どのレベルまで依存を許容できるか、ってだけの問題にしかならない。
いや、その程度の問題なんだが。
S2が無いと動かないってのはどうなんだ？っていう答えがPOJOだからS2に依存しないっていうのが、的外れだってこと。
0662デフォルトの名無しさん
05/03/02 22:05:53最終的に動作する環境でいろんなものに依存するのは当たり前なの。
おまいはサーバも無いところにソースだけ納品してるのか？
いちいち「依存してる」って言葉について説明するのも馬鹿らしいんだけど、
ここで言ってる「依存しない」は運用時ではなくて開発時のことさね。
特定のライブラリに依存しないPOJOで作れると何がよいって、テストが楽だし安全でしょ？
あともう一つ勘違いしてるっぽいポイントは、
S2を利用するプログラム(例えばおまいさんが作る業務システム)が、
S2/S2JSFに対して依存度が低いって言ってるんであって、(←しつこいけど開発時のことね。)
S2JSFがS2に依存しない何て話は出てないし話題にする必要も無い。
S2プロダクトシリーズであるS2JSFが、S2と密接に関連するのは当たり前だろう。
おまいはどんな世界を夢見てるんだい？
0663デフォルトの名無しさん
05/03/02 22:40:05>>651の答えとして>>652の「POJOだから」が適当なのかという話をしてるわけだが。
なに逆切れしてんの？
0664デフォルトの名無しさん
05/03/02 22:42:18だから>>651の意見が出てくるんだろ。
それで、POJOだから依存しないって、なんかおかしいんじゃね？
0665デフォルトの名無しさん
05/03/02 22:50:23> それで、POJOだから依存しないって、なんかおかしいんじゃね？
どうおかしいんだい？
0666デフォルトの名無しさん
05/03/02 22:57:030667デフォルトの名無しさん
05/03/02 23:05:31技術的なことを真剣に考えて言ってるわけじゃない。そもそもS2に依存するのが嫌なら最初からS2ファミリーには興味持たない。
0668デフォルトの名無しさん
05/03/02 23:23:27「これだとSpringに依存しちゃいますから！残念！！」みたいな発言は
たとえばSpringのDataSourceUtilsとか、ApplicationListenerなどを利用させるような開発手法についての批判だった気がする。
だからPOJOだから大丈夫という回答になるんだと思うけど
S2JSFがS2が無いと動かないという話とは別物のような気がするけどな。
例えるなら、「SpringのMVCフレームワークがSpring無しで動かないのはおかしい」みたいな話になるのでは？
0669デフォルトの名無しさん
05/03/03 00:05:02S2/S2JSFのアプリはPOJO
↓
SpringのAPIを使ってない
↓
Springでは動かない
↓
結局S2/S2JSFに依存してる
↓
POJOだから依存しないって、なんかおかしいんじゃね？
ということか？
それで咎められるべきはS2やS2JSFじゃないと思うぞ。
0670デフォルトの名無しさん
05/03/03 00:44:44別にとがめるとかではなくて、そこでPOJOだからっていうのは理由になってないんじゃない？って言いたいだけ。
「依存してるけどPOJOだからロジック部分は再利用可能」
だったらわかるけど。
>>667
> そもそもS2に依存するのが嫌なら最初からS2ファミリーには興味持たない。
S2JSFは面白そうだと思うんだけど。
S2に依存するのが嫌なら興味持たなくていい程度の、他と大差ないしくみなの？
0671デフォルトの名無しさん
05/03/03 01:00:14>>668読めば、「POJOだからっていうのは理由になって」るのが分かるぞ。
0672デフォルトの名無しさん
05/03/03 01:05:26他って具体的に何よ。半端な釣りすんなよ。
0673デフォルトの名無しさん
05/03/03 01:11:28その、別物の方の話を>>651はしてるんじゃないの？
まぁ、>>651に関しては、S2Daoとかもすでにあったわけでいまさら言うことじゃないと思うけど。
0674デフォルトの名無しさん
05/03/03 01:12:30Mayaとかちょっと上で話題に出てるんだけど・・・
0675デフォルトの名無しさん
05/03/03 01:13:460676デフォルトの名無しさん
05/03/03 01:21:14つまりもなにも、いまさら言うことじゃないと書いてるわけで。
「そこでPOJOだから」はないんじゃないの？って言いたかっただけだ。
>>668の前後入れ替えればいいだけで、意図はわかったからもういいけど。
0677デフォルトの名無しさん
05/03/03 09:20:40途中から「POJOだからはないんじゃない」と言いたかっただけだと
すりかえておきながら変な奴が混ざってるとかいってる藻舞も変なﾔｼｗ
0678デフォルトの名無しさん
05/03/03 15:10:07そりゃ、途中で「POJOだから依存しない」って言われたからさ。
0679デフォルトの名無しさん
05/03/03 15:13:32変なやつというのは、「釣り」だとか「言いがかり」だとか、被害妄想的な煽り文句入れてるやつね。
0680デフォルトの名無しさん
05/03/04 00:00:150681デフォルトの名無しさん
05/03/04 01:12:09POJOであれば、ソースコード的には依存しないわけで。
そこには価値があると思う。
0682デフォルトの名無しさん
05/03/04 02:04:25俺はSpring使ってるけど
0683デフォルトの名無しさん
05/03/05 12:09:28すべてコンテナから取得するわけではないとどっかに
書いてあった気がしたんですが。うるおぼえですみません。
0684デフォルトの名無しさん
05/03/05 19:59:240685デフォルトの名無しさん
05/03/06 20:53:52プレゼンテーション層だけ、と限定しても未だにWebObjectsが最強だと思うんですけど。
仕事ではStrutsでいらいらするけど。
0686デフォルトの名無しさん
05/03/06 22:25:060687デフォルトの名無しさん
05/03/06 22:42:310688デフォルトの名無しさん
05/03/06 23:23:42S2JSFからS2をはずそうという発送が出てくること自体凄いよなあ。
そしたらS2JSFじゃないじゃんｗ
つーか、そんなことをココで聞く前に自分でソースでも見てれば、そんなくだらない疑問はすぐに解決してこのスレが荒れることは無かったのに。
つーか、オープンソースなんだから。。。
ソース見ればすぐに分かるようなことを、クレクレしてくる奴はどうかと思うけどね。
0689デフォルトの名無しさん
05/03/06 23:25:31すぐわかったあなたはえらい
自分で作ってみるまで良さがぜんぜんわからなかった…
0690デフォルトの名無しさん
05/03/07 02:31:27来月のJavaWorldで特集組まれるみたいだし、最近JavaWorldはS2プッシュしてるね
0691デフォルトの名無しさん
05/03/07 16:53:40S2をいじるのは初めてで、S2JSFうんぬん以前に
あまりにあっけないんで、逆にすんごい不安になってしまった。
今の出向先の自社謹製フレームワークがもうしんどくてしんどくて。
早いところ自社に帰ってS2で仕事したい。
0692デフォルトの名無しさん
05/03/07 17:40:53全く誰にも気づかれずに未だにポツンとあるのが
ちょっと笑った。元気が出た。
0693683
05/03/07 23:32:11BCEのEはgetter,setterのみが幾つかあるようなものだと
思っているのだけれども、Eをコンテナから生成しても
意味なくないですか？
0694デフォルトの名無しさん
05/03/08 00:00:46S2Daoって知ってるか？
0695デフォルトの名無しさん
05/03/08 19:26:17Aと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にどういう風に書けばいいんでしょうか？
0696デフォルトの名無しさん
05/03/08 19:34:23メーリングリストでききなよ
0697デフォルトの名無しさん
05/03/08 19:48:10漏れみたいなお馬鹿Qは投げにくいんだもん．．．．．
0698デフォルトの名無しさん
05/03/08 22:27:120699太田＠下宿
05/03/09 07:33:39http://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;
のみを定義するとうまくいくと思います。
0700デフォルトの名無しさん
05/03/09 19:24:240701695
05/03/10 11:00:19>>699
ありがとうございます。
頂いたサンプルでは、SQLファイルを用意しているようですが、
SQLの自動出力は難しい、ということでしょうか。
0702デフォルトの名無しさん
05/03/11 02:38:02多種RDBMSに同一ソースで対応したいっていうなら話は別だけど。
0703695
05/03/11 10:02:41そうなんですか！
僕は寧ろ、できるなら自動でやる方が好ましいのかと思って、
がんばってSQLファイル削減してるところでした＿|￣|○
今後は躊躇無くSQLファイルを使っていきたいと思います。
ありがとうございました。
0704デフォルトの名無しさん
05/03/12 01:11:56これができるのって、あとはiBatisくらいしかないんじゃないか。
逆にSQLを徹底的に隠す方向のO/Rマッピングなら、Cayenneくらい徹底的に隠して
ほしい。
HibernateのHQLってそういう意味でなんか中途半端なイメージがあるんだよね。
クエリでSQLもどきをかくなら、もうSQL書かせてくれたらいいから、とか思ってします。
0705695
05/03/12 11:16:42他のO/Rマッピングツールを使ったことが無かったので分からなかったのですが、
S2Daoの秀でている点というものが激しく納得できました。ありがとうございます。
といってるところにMLにタイムリーな話題が^^;
0706デフォルトの名無しさん
05/03/19 14:34:01seasar.orgにはみつからん。
0707デフォルトの名無しさん
05/03/19 15:01:20国粋主義者以外はSpringかEJB3.0だろ。
0708デフォルトの名無しさん
05/03/19 15:43:290709デフォルトの名無しさん
05/03/19 22:03:25Kijimunaも良いけど、SpringIDEはもっとすごいね。
0710デフォルトの名無しさん
05/03/20 00:00:570711デフォルトの名無しさん
05/03/20 01:44:14オートインジェクションが便利だよ。
0712デフォルトの名無しさん
05/03/20 02:06:130713デフォルトの名無しさん
05/03/20 14:14:45ttp://lists.sourceforge.jp/pipermail/seasar-user/2005-March/001578.html
みたいな返答を見るとバージョンアップに躊躇してしまう。
0714デフォルトの名無しさん
05/03/20 14:46:27話なくなったのかなあ
0715デフォルトの名無しさん
05/03/21 00:05:37作ってみようと思ったんですが、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>
どこが悪いのかわかる方お願いします。
0716デフォルトの名無しさん
05/03/21 01:24:290717715
05/03/21 02:41:19public void setTheFile(FormFile theFile) {
this.theFile = theFile;
}
FormFileは「org.apache.struts.upload.FormFile」で、UploadFormクラスは
StrutsUploadのサンプルからもらってきたものなんです。
StrutsUploadの方だと、アップロードしたファイルやその情報をFormFileに
格納して、setTheFileからセットしてくれるんですが、POJO型のActionじゃ
それは無理なんでしょうか。
0718デフォルトの名無しさん
2005/03/21(月) 13:22:43Object型でうけてみて
何の型できているか確認してみたらどうでしょう
0719デフォルトの名無しさん
2005/03/21(月) 13:23:27ラ・ロシュフコー
0720デフォルトの名無しさん
2005/03/22(火) 00:15:27なるほど！
ありがとうございました。
0721デフォルトの名無しさん
2005/03/25(金) 02:15:18Kijimunanaにはがんばってもらいたい
Java Worldのseasar特集はこれから読みまつ(｀･ω･´)
0722デフォルトの名無しさん
2005/03/25(金) 13:25:27SpringIDEはプロパティ名やクラス名の補完をしてくれないから
実際はそれほど役に立たない｡
バリデーションはしてくれるけど｡
仕事でSpringを使っているひとで、SpringIDEを使っているって
あまりきいたことない。
あの意味のないグラフィック表示が使ったことのないやつには
すごいように見えるのかもしれんが｡
0723デフォルトの名無しさん
2005/03/26(土) 03:05:11そうなのか…(´･ω･｀)
とりあえずS2JSF正式リリースおめ
これで次のプロジェクトに使えるよー
0724デフォルトの名無しさん
2005/03/26(土) 03:16:04Springのほうが上を説得するのはやりやすいのが実情。
ほっとくと「なんか有名なんでEJBでよろしく」とかなっちゃうんでねえ。
もうちょっとメジャーになってくれるとやりやすいんだが、それはこれから
の活動次第か。なんとかJavaWorldを見せることはできるようになったわけで。
0725デフォルトの名無しさん
2005/03/26(土) 12:25:070726デフォルトの名無しさん
2005/03/26(土) 20:31:27S2JSF必須ライブラリのためにseasar2にクラスパスは通しておくだけ。
0727デフォルトの名無しさん
2005/03/27(日) 11:56:510728デフォルトの名無しさん
NGNG> 今回のセミナーでは、魅力的なS2JSFの機能を紹介するだけではなく、
> マニュアルでは触れられていないような、でも知っているとS2JSFのことを
> より深く理解できるような、一歩踏み込んだトピックもお話します。
とあるんですけどS2JSFのマニュアルってどこかにあるんでしょうか？
サンプルの解説しか見たことないんですけど。
0729デフォルトの名無しさん
NGNG0730デフォルトの名無しさん
2005/04/03(日) 17:38:34S2.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)
0731デフォルトの名無しさん
2005/04/03(日) 18:44:580732デフォルトの名無しさん
2005/04/06(水) 12:05:520733ひが
2005/04/06(水) 23:26:44探さないでください・・・。
0734デフォルトの名無しさん
2005/04/07(木) 02:05:010735デフォルトの名無しさん
2005/04/07(木) 13:12:37がんばれひがたん
0736デフォルトの名無しさん
2005/04/16(土) 23:16:57ビューとロジックを完全に分割できます、すごいでしょ
なんて言ってるから日本人は仕様にかかわれないんだよ
0737デフォルトの名無しさん
2005/04/16(土) 23:31:240738デフォルトの名無しさん
2005/04/17(日) 14:18:250739デフォルトの名無しさん
2005/04/17(日) 17:11:140740デフォルトの名無しさん
2005/04/17(日) 17:27:040741デフォルトの名無しさん
2005/04/17(日) 17:41:500742デフォルトの名無しさん
2005/04/17(日) 18:04:45そういうもんだろう。
Springの定義の継承とくらべてそれほど特殊なコトやってるかな？
0743デフォルトの名無しさん
2005/04/17(日) 18:56:34インクルードされる側にインクルードする側での定義が影響するというのは、特殊なことだと思う。
0744デフォルトの名無しさん
2005/04/17(日) 19:07:350745デフォルトの名無しさん
2005/04/17(日) 19:16:200746デフォルトの名無しさん
2005/04/17(日) 19:16:230747デフォルトの名無しさん
2005/04/17(日) 19:17:190748デフォルトの名無しさん
2005/04/17(日) 19:17:22親で定義されているコンポーネントは子では見えないからオートインジェクションされない。
0749デフォルトの名無しさん
2005/04/17(日) 19:46:25設定ファイルの依存関係という話だから全く無関係でもないと思うが。
子のBeanFactoryに読み込まれる設定ファイルからは親のBeanFactoryが
読み込んだ設定ファイルが見える、つまり依存する(かもしれない)わけだろ？
設定ファイルの依存関係がわけわからくなるのはむしろSpringじゃね？
0750デフォルトの名無しさん
2005/04/17(日) 20:02:310751デフォルトの名無しさん
2005/04/17(日) 20:06:07それはBeanFactoryに親子関係を持たせるときの話で、定義ファイルの分割とは別の話。
ごっちゃにして考えるもんじゃない。
0752デフォルトの名無しさん
2005/04/17(日) 20:23:01それって全部依存しあうってことだよね。いいことなのかな？
0753デフォルトの名無しさん
2005/04/17(日) 20:34:35話の発端は設定ファイルの依存関係だろ？
一つのコンテナに読み込まれる定義ファイルの分割だけに
話を限る必要はないと思うが。
0754デフォルトの名無しさん
2005/04/17(日) 20:39:18名前空間という点ではちょっと問題。
0755デフォルトの名無しさん
2005/04/17(日) 23:25:05ThreadDataInterface _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>
と定義。パスは天地店名に誓って間違ってない。なんだろう……
0756デフォルトの名無しさん
2005/04/17(日) 23:37:28/tmpをクラスパスに入れてcreate("test.dicon")とか。
0757デフォルトの名無しさん
2005/04/17(日) 23:38:30create(String path)に渡すpathは、クラスパスをルートとしたパス名だぞ。
俺の予想では、/Users/tetsuyak/Desktop/EORelationshipDISample/ ってのがクラスパスの
指してるところなんだろう。
なんで/tmpが無視されてんのかはよくわからんけど、「tmp/test.dicon」（頭の/がない）だったら、
/Users/tetsuyak/Desktop/EORelationshipDISample/tmp/test.dicon を探しにいくと思う。
名前からしてWebObjectsか....
0758755
2005/04/18(月) 00:07:53>>(/Users/tetsuyak/Desktop/EORelationshipDISample/test.dicon)が見つかりません
この部分は正しくは、(/tmp/test.dicon) が見つかりません
です。別のウィンドウからコピペしちゃったものでした（恥
>>757
>>create(String path)に渡すpathは、クラスパスをルートとしたパス名だぞ。
ありがとうございます。もうちっと試してみます。
>>名前からしてWebObjectsか....
思いっきりバレバレです。ごめんなさい。
0760デフォルトの名無しさん
2005/04/18(月) 21:44:59図らずも Java ってダメさ具合を明確なものにしてるんだよね。
型を気にして無意味なクラスを作る気持ち悪さ、生産性の低下、これを実感できる。
Seaserも全く同じで、これもまた図らずも、Javaでのウェブ／データベースプログラミングの
向いて無いことを証明してる。なんでこんな複雑なもの覚えても、実際には
スクリプト言語で見通しよく書かれたコードのほうが、よほど生産性が高くて堅牢だよね。
0761デフォルトの名無しさん
2005/04/18(月) 22:29:590762デフォルトの名無しさん
2005/04/19(火) 01:25:280763デフォルトの名無しさん
2005/04/19(火) 01:52:23なんか出来上がりが自作PCみたい(CLASSがパーツでDICONが配線)
になってしまったんだけど、使いどこ間違ってる？
将来拡張するかもしれないと思われる部分にだけ、ピンポイントで使う
のが正しい？それとも、もうあらゆる部分を全部個別部品として作って
最後にDICONで繋いで完成とするのが正しい？
Seasarの使い方ではなく使われ方？上手く言えないけど、こういう例
ではこう使え！って感じのノウハウ集とかってのはないかな？
0764デフォルトの名無しさん
2005/04/19(火) 04:45:13Springのほうか？
それとも、SeasarもSpringも使わないやつらか？
0765デフォルトの名無しさん
2005/04/19(火) 04:51:51そうだね。だから君はこのスレに来る必要はないと思うよ。
0766デフォルトの名無しさん
2005/04/19(火) 07:07:22誰もこの疑問に反論はできないし、それでも、生産性が上がることをアピール
したいために、作者は一生懸命に作ってるのも分かるのだけど、
でも、老婆心だけど、ここは、引き返す勇気を呼び起こすときだと思う。
やりたきゃやっていいけど、根本的な間違いがあるが故に、
やった結果何も残らないのだとしたら、なんかもうかわいそうだ。
0767デフォルトの名無しさん
2005/04/19(火) 07:42:29DIコンテナを「複雑なもの」と思ったんなら、老婆心だけど、ここは、転職する勇気を呼び起こすときだと思う。
なんかもうかわいそうだ。
0768デフォルトの名無しさん
2005/04/19(火) 07:54:03ちょっと前に流行ったSWTのごとく。
0769デフォルトの名無しさん
2005/04/19(火) 08:11:21自分ではプログラムもできずに、
大規模プロジェクトに下請け派遣で入ってるだけの可哀想な人。
こーゆー可哀想なのにも半端仕事あてがってやれよw >> ISID
0770デフォルトの名無しさん
2005/04/19(火) 08:12:57画面一つ作るのに 1人月以上かけて、しまいにゃ実装をオフショア発注しちゃう、ダメダメ現場かｗ
0771デフォルトの名無しさん
2005/04/19(火) 08:13:500772デフォルトの名無しさん
2005/04/19(火) 08:46:16> メタ議論で煽ってるのは荒し。
どれをメタ議論といってるのかわからんが、その発言自体がメタ議論であることは確かだな。
ということはつまり、>>769はISIDに半端仕事くださいといってるわけか。
0773デフォルトの名無しさん
2005/04/19(火) 09:13:410774デフォルトの名無しさん
2005/04/19(火) 09:41:19お前のせいじゃないから気にするな
心配しないでここから去れ
0775デフォルトの名無しさん
2005/04/19(火) 09:43:360776デフォルトの名無しさん
2005/04/19(火) 10:23:26というか、いまどきSWTに明確な実益があるとか言いきってる時点で情報収集能力に疑問がでてくるね。
0777スレ違いとかそんなもんいいだろ
2005/04/19(火) 17:17:43>SWT の明確な実益は、Swingの高速化で不明確な実益になった。
まぁ、Swingも悪くは無いんだけど、JFaceのContentProvider, LabelProvider, Decorator あたりの
アーキテクチャはモダンだと思ったし、やっぱりまだ SWT のほうが速いし、ウィンドウシステムに
対して忠実であるのはSwingとの明確な違いとしてあると思う。
0778デフォルトの名無しさん
2005/04/19(火) 21:43:00JDK1.4.1くらいまでなら、それでもデメリットに目をつぶれるような速度差があったけど、今はそこまでの速度差がない。
しかも、メモリやらリソースやら食うから、SWTの方が遅いこともありえるような気がする。
0779デフォルトの名無しさん
2005/04/20(水) 10:35:44ｽﾚﾁｶﾞｲｳｻﾞｽ
ところで、S2JSF(だけに限らずSeasar2全般)のリファレンスマニュアルって作る気ないのかな。
皆あの中途半端な「サンプルの解説」だけで満足できるの？
俺一人なら、ソース読むなり何なりするのでいいんだけど、
チーム全員にそれを強要するのは、うちのチームじゃ無理だね。
本気でS2を普及させる気があるなら、バージョンアップより先に詳細なマニュアルを早く作ってくれろ。
0780デフォルトの名無しさん
2005/04/20(水) 11:09:44立ち読みしたけど、連打対策とか戻るボタン対策とかの話まであって
かなり実践寄りでよさげだった。
マニュアルとういか、これのS2JSF/S2Dao/S2バージョンを
書いてくれないかなあ。
0781デフォルトの名無しさん
2005/04/20(水) 11:14:280782デフォルトの名無しさん
2005/04/20(水) 12:46:38「サンプルの解説」がダメなのにリファレンスなら大丈夫って
珍しいメンバーだね。
リファレンスだけあっても～ならありがちだけど。
0783デフォルトの名無しさん
2005/04/20(水) 13:57:03サンプルでは機能が網羅してないってことだろ。
網羅してたとしてもリファレンス性も悪いし。
0784デフォルトの名無しさん
2005/04/20(水) 15:18:28違う違う。サンプル解説がだめなわけじゃないって。
サンプル解説のおかげで、
「S2JSF使えばどういうことが出来るのか」って言うのはよく分かったよ。
それはいいのよ。確かによく分かったしありがたいこってす。
でもね、いざ新しい物を作ろうと思うと、どういう部品がどういう風に絡み合ってるのか、
新しい部品を作るにはどうしたら良いのか、そういうことが全然わかんなくて、すぐ壁にぶち当たりまくり。
「どういうことができるか」はとってもよく分かるけど、
「どういう風に作ればよいのか」が全然わかんない。サンプルの解説だけじゃね。
ちょいと誤解してるようだけど、リファレンスだけあれば良いっつってんじゃないよ。
サンプルの解説も、リファレンスも両方（できればチュートリアルもｗ）欲しいって言ってるの。
>>781
ごめんね。100%完璧に理解してるわけじゃないからこそ、
リファレンス等のドキュメントが欲しいのよ。
俺必死だなw
0785デフォルトの名無しさん
2005/04/20(水) 15:55:26>>784
確かに資料、情報は多いに越したことはないもんな。
多くの人に普及させたければ必要なことだろうと思う。
ただ、こういうのって必要と思った人が用意するって文化を推奨してる
から。君がぶち当たった壁をWikiなりなんなりで公開すると
みんなウハウハ・・と。実際はそんな理想的にならないんだろうけど。
作者の周りには人が集まっているようで、いろいろ仕事割り振って
うまく回っていると俺は思っているんだけど、プログラマがあまりしたがらない
全体の統一的なドキュメント化のような部分をやってくれる人が多数
参加するようになるともっと良いのかもしれないね。
それにはもう少し時間が必要なんじゃない？
0786デフォルトの名無しさん
2005/04/20(水) 20:20:34リファレンスの必要性自体を感じてないような気もする。
日本語情報が多いっていうのがひとつの売りということだったけど、koichikさんのSpring入門記の方がSeasarのドキュメントよりも充実してる気がするし。
ってか、サンプルとかその解説とかは部外者にも書けるんだけど、リファレンスは開発者じゃないと書けないんだよね。
0787デフォルトの名無しさん
2005/04/20(水) 20:40:25バージョンの依存関係がわけわかめ。
0788784
2005/04/20(水) 20:56:30確かに協力してく気があるなら、
リファレンスは無理にしても、
「こんなのにぶちあたっちゃったの」は公開していくべきでしたね。
でも正直、ぶち当たりすぎちゃって既に嫌になってる部分もあったり…＿|￣|○ ﾓｳS2Strutsﾃﾞｲｲﾓﾝ
「ドキュメント不足」っていう理由のせいで、
S2JSFから人が遠のくなんてことは、実に寂しいことだと思うのです。
まずは人を惹きつけて…卵が先か、の話にはなっちゃいますけどね。
>>787
1行目は何言ってるのかわかんないけど、2行目は禿同。
その辺も、Seasarの敷居が高くなってる原因の一つだと思う。
0789デフォルトの名無しさん
2005/04/20(水) 20:59:500790デフォルトの名無しさん
2005/04/20(水) 21:49:37漏れはプロモーションのセンスあると思うよ。
残念ながらSeasar は役立たずだけど、それでも雑誌の記事に載せるところまでは
到達できたのはたいしたもの。
Seasarのコミュニティがなかなか出来上がらないのは当然のことで、
もともとSeasarは実はあまり意味のない代物だから、分かってる人にしてみればスルーするだけだし
逆に、リテラシーの低い初心者が「分からないからドキュメントくれ」 が群れてくる。
いいプロダクトなら、リテラシーの高い人がチカラを貸すよ。カネになるってもそうだけど、
ちょっと頑張るだけで世界が変わるのを実感できる。
Seasarじゃ何も変わらないってのが、リテラシーの高い人には見えちゃうんだよ。
0791デフォルトの名無しさん
2005/04/20(水) 21:51:33開発されているものの価値を見出した人の中から広告塔になってくれるような
人が現れる流れがあると、自分らも楽しいと思わない？夢物語かなぁ。
作る才がある人が作ることにのみ集中できて、
その他の事をうまく分散できるといいのに。とか思ったりする。
0792デフォルトの名無しさん
2005/04/20(水) 21:58:27Seasarが価値があるものならそれは人は現われるけど、そうではないのだから、どうしよもない。
0793デフォルトの名無しさん
2005/04/20(水) 22:02:28的を射ているのかもしれない。
フレームワークなのだから、既にしっかりしたノウハウを持っている人の目には
今更…のように写ったりしそう。ただ、作成される多くのものが
そのフレームワークの作法に従うことで統一感が生まれて保守効率が
上がるような可能性はあるよね。それでは世界を変えるまではいかないけど。
プロジェクトとして推す時に「ここに詳細な情報があります」って言えることは
かなり大事じゃないかな。誰それのブログ端から読んでよってのはどうかねぇ。
情報は統一されていないと探しづらいと思うのだ。
これは、狙っている層がJavaの業務アプリだから特に思うこと。
0794デフォルトの名無しさん
2005/04/20(水) 22:03:49雑誌の記事に載せるくらいでプロモーション力あるというなら、プロモーション力の敷居はかなり低いんだな。
0795デフォルトの名無しさん
2005/04/20(水) 22:05:27MLのログもありますよｗ。
0796デフォルトの名無しさん
2005/04/20(水) 22:14:18作法には価値があると思う。
だから、Seasarはだめでも、「くーす」はなかなか、広める価値のあるものだと思ってて。
コントロールはステートレスとか、分かってる人にしてみれば、当たり前だろみたいなことだけど、
学習中はその徹を踏んでしまうかも。
オブジェクト指向プログラミングって、深い理由がわからなくても、ＯＯ的にデザインされた
ライブラリを使うことで自然に生産性上がるのを体感して意味もわかってくるみたいなこと
あるけど、ウェブ／データベースプログラミングにおいては、いまいち実感しづらいところもあって、
Seasar使えば分かるんじゃないかみたいな人いると思うんだけど、残念ながら、
これはいくら使っても体感できないんだよね。
作法は作法として覚えるしかないと思う。フレームワークが解決することとも思えない。
Javaはウェブ／データベースプログラミングには向いてないし。
ホントに原理がシンプルで扱いやすいフレームワーク／言語も含めたプラットフォームの
分かりやすいものだけが生き残る。
0797デフォルトの名無しさん
2005/04/20(水) 22:17:21雑誌って基本的にアホで、特にソフト開発者向けの雑誌ってさらにアホなんだけど、
それでも載せるってのは、あほだからこそでもあるけど、そう簡単じゃないぜ。
0798デフォルトの名無しさん
2005/04/20(水) 22:36:34自分とは思想が逆みたいなんだけど、面白いのでしつこく食い下がってみる。
作法はできる限りフレームワークで吸収してやる部分じゃないかな。
例を挙げちゃうと焦点がぶれたりする可能性があるので
逆にまずいかもしれないけど、StrutsなんてFrontControllerだよね。
これをFrontController知らない人でも強制的に使わせてるよなと。
覚えること、考えることを減らすためにフレームワークやライブラリは存在
すると思う。オブジェクト指向については流すよ。哲学論争になりやすいし。
＞ホントに原理がシンプルで扱いやすいフレームワーク／言語も含めたプラットフォームの
＞分かりやすいものだけが生き残る。
これには同意。特に多人数開発ではキーになる考え方だろう。
わかりやすくて、しょぼい開発者がいてもちゃんと動く仕組みが宜しいかと。
そういう意味ではJavaもDIもそんなに的外れではないかなと思ってる。
0799デフォルトの名無しさん
2005/04/20(水) 22:43:44> しょぼい開発者がいてもちゃんと動く仕組みが宜しいかと。
> そういう意味ではJavaもDIもそんなに的外れではない
フレームワークに関しては、漏れは、
ホントにいいものなら、無いよりはマシくらいの位置づけで、
たぶん、ほとんどの人はそうでないか。
フレームワークでしょぼい開発者が救われるのかといえば、少しは寄与するかしれんが、かなり嘘で、
そんなもん、ただ開発プロセスの中に学習・フィードバックの仕組みが機能してるかどうかだけにかかってる。
だから、もうSeasarとかJ2EEとかSpringやらに騙されるな、近寄るなと漏れは知らせたいんだよ。
そっちのほうがはるかに社会的だと思わんか。
0800デフォルトの名無しさん
2005/04/20(水) 22:46:19Javaはもともとウェブ／データベースプログラミングに向いてないし、
Seasarとか評価してみたけどやっぱり使わないほうがマシなんだよ。
0801798
2005/04/20(水) 22:47:13>>793の「作法」はソースコードの統一感としての作法で
>>796以降の「作法」はもう少し価値の高いある種パターンのような
分野にまで発展した考えで論じられているね。
特に訂正は無いんだけど、確認のため投稿。
0802デフォルトの名無しさん
2005/04/20(水) 22:53:22>793の「作法」はソースコードの統一感としての作法
まさかとは思ったけど、こういうのをフレームワークで縛れるとか思ってる人がまだ結構いるんだよね。
現実に目の当たりにすると、腹の底から軽蔑しますよ。
ホントにヒドイと思う。
0803デフォルトの名無しさん
2005/04/20(水) 22:58:04> だから、もうSeasarとかJ2EEとかSpringやらに騙されるな
> 近寄るなと漏れは知らせたいんだよ。
> そっちのほうがはるかに社会的だと思わんか。
最後のこの部分しか読んでないが、この意見がアホなこといってることはわかる。
0804デフォルトの名無しさん
2005/04/20(水) 23:01:20優等生的に答えると、フレームワークは設計の再利用だよね。
これは実装の再利用であるライブラリと対になっていると思う。
無ければ自分でその時作るだけ。だけどある程度良い設計、実装が
既に提示されているのなら利用した方が良いぞと。
既存フレームワークで救うのはしょぼい開発者の中でも
駆け出しの設計者になるだろう。あと、熟練者でもわざわざ0から
フレームワークを構築しなくて良くなるので時間の節約になるよね。
ドキュメント書かなくても良いし、既にそれを知ってる人はいきなり使うだけだし。
＞フレームワークでしょぼい開発者が救われるのかといえば、少しは寄与するかしれんが、かなり嘘で、
＞そんなもん、ただ開発プロセスの中に学習・フィードバックの仕組みが機能してるかどうかだけにかかってる。
教育の仕方をどうするかって話で解釈合っているかな。
もう少し上のレベルに話が広がってしまいそうなので流します。
0805デフォルトの名無しさん
2005/04/20(水) 23:11:08＞そっちのほうがはるかに社会的だと思わんか。
いろいろ書こうと思ったけど、まとまらなかったので質問してみる。
>>799の開発ではどんなフレームワークを使っているの？
もし良かったら書いてみてくれないかな。その方が話がわかりやすくなりそう。
>>802
うーんと、言わんとしているところが良くわからなかった。
ソースコードの統一感って言うのは見た目の問題だから
「Strutsで作ってるよ」「あー、じゃぁActionクラスを継承すんのね」
みたいな部分という意味で書いたんだ。もう少し書いてみてくれないか？
0806デフォルトの名無しさん
2005/04/20(水) 23:12:51自分はここ以外はそれほど的外れでも無さそうに思ってる。
0807デフォルトの名無しさん
2005/04/20(水) 23:25:02Seasar使うくらいならPure Servletのほうがいいよ。
シンプルにやりゃいい。
Struts使うことでAction使うことが自明になるとしても、それが？ って感じでしょ。
何の役にも立たない。なら使わないほうがいい。
ウェブインターフェースのアプリケーションなら、
Rubyが最適だと思いますよ。文字列処理が高機能、コードも短くて済む。
いい実装例だなと感じてるのは
http://www2a.biglobe.ne.jp/~seki/ruby/divip.html
バックエンドとの分離も簡単シンプル、台数並べれば並べるほど比例して処理を分散する
みたいな仕組みも作れる。そのプログラミングも贅肉なしのライブラリが使えるし。
0808デフォルトの名無しさん
2005/04/20(水) 23:35:47えーと、プロジェクトの中でみんなServlet開発をしているって意味かな。
それは開発のスピードが遅そうに感じるんだけど、自分だけだろうか。
StrutsのActionの話は、そういう部分を合わせないと理解が遅い人が
いるよねって話。逆にこんなもん合わせるだけでルーチンワークに
乗せられたりするものだったりもする。
自分は今までの話を「多人数で開発する」ということを念頭に書いてる。
これは、Seasarみたいなものが狙っているターゲットがそうだから。
紹介してくれたアプリも多人数で開発するようなものでは無さそうだね。
ちなみに、個人で使うなら今のS2を使わないってのは自分もそうだと思うよ。
一人でWEBサイト構築するならRUBYは触ったこと無いのでPHPかな。
共通部をまとめてるうちに結局自分用フレームワークできちゃうけど。
0809803
2005/04/20(水) 23:44:20あ、ほんとだ。
ってことはあれだね。
正しい意見を述べておいて、結論だけは正しくない意見にしておけば、正しくない意見を正しいと思わせることができるっていう高等技術。
0810デフォルトの名無しさん
2005/04/20(水) 23:45:51Strutsは単にフォームへの入力をBeanに格納してくれるただのライブラリだ。
0811デフォルトの名無しさん
2005/04/20(水) 23:52:585年かもっと前のJavaみたいなもんで、ユーザとか元請けのSIerから
止められるのが普通じゃない？ ちっちゃいところはいいかもしれんけど。
Rubyできるやつサクッと集められるとも思えないしね。
だから、ここでRubyが最適とかいわれても逃避にしか見えない。
Javaでどうするか、DIでどうにかなるのか、って所でスゲーやつの
話が聞きたいです。
0812デフォルトの名無しさん
2005/04/20(水) 23:57:13いや、大抵は>>803みたいに最後だけ見て「こりゃだめだ」って切り捨てられる罠。
そろそろ筆置きます。
長文連発すまなかった。＞スレの人々
あと、S2から凄く離れてしまってすまん。
長々付き合いありがとう。>>807
0813デフォルトの名無しさん
2005/04/21(木) 01:35:17>>787が1行目で言いたいのは、
メジャーなリリースと、マイナーなバージョンアップを分けてほしいということかと。
0814787
2005/04/21(木) 01:51:04いや、S2StrutsとかS2JSFとか、全部含んでSeasar2.x.xとして出して欲しいってことです。
S2JSFのこのバージョンはSeasar2.1.8じゃないと動きませんよ、とか、でもS2XXXはこのバージョンでは動きませんよとか、わけわからん。
0815デフォルトの名無しさん
2005/04/21(木) 10:33:20んだけど、十分に単純で便利だと思うんだが・・・・・・
なんでここでは否定的な意見の方が多いんだろう？
0816デフォルトの名無しさん
2005/04/21(木) 10:41:59そんな感じじゃないですか。
eclipseからJava始めた人はクラスパスとか
判ってなくてけしからん、とか。
俺は知らなくてもできるんならそれでいいし
トラブルになったらその時に調べて
覚えりゃいいと思うんだがなあ。
0817デフォルトの名無しさん
2005/04/21(木) 10:53:27この理解で概ね合っていると思っていいよな？駄目だったら頭いい人突っ込んでくれ。
AbstractFactoryにしたくなるような生成部分を統一的な方法で提供しているって
理解なんだけど。
0818デフォルトの名無しさん
2005/04/21(木) 11:11:31それならSpringの方が日本語の資料も多くて便利
0819デフォルトの名無しさん
2005/04/21(木) 11:22:28ここで小難しいこと言ってSeasarだめ論(もっと言うとJavaだめ論)を展開してる人って、
案外そういう簡単なことが分からないのかもね。
難しく考えすぎと言うか。
>>818
それは好みの問題でしょう。
0820デフォルトの名無しさん
2005/04/21(木) 11:34:14Seasarの説明に、次世代どうのこうのとか小難しく書いてあるから。
0821デフォルトの名無しさん
2005/04/21(木) 11:45:14S2とS2Daoと、あと戦略商品としてS2JSFをバンドルしてくれればいい。
個人的にはS2Strutsも。
0822デフォルトの名無しさん
2005/04/21(木) 11:59:000823デフォルトの名無しさん
2005/04/21(木) 12:09:22> Seasar使うくらいならPure Servletのほうがいいよ。
> シンプルにやりゃいい。
シンプルっていうよりサンプルしか作ったことないとか？
まともに開発したことあるやつとは思えない。
> バックエンドとの分離も簡単シンプル、台数並べれば並べるほど比例して処理を分散する
> みたいな仕組みも作れる。そのプログラミングも贅肉なしのライブラリが使えるし。
後ろが分散できたってしょうがないだろ。なんか素人くさい。学生？
0824デフォルトの名無しさん
2005/04/21(木) 12:13:42標準セットパッケージみたいな感じだよね。
これ一個でとりあえず美味しい汁を吸えますみたいな。
0825デフォルトの名無しさん
2005/04/21(木) 12:14:32まぁまぁ、そう反応しなさんな。
見てる切り口が多分全然違うのだよ。
0826デフォルトの名無しさん
2005/04/21(木) 12:26:10Strutsすら必要ないなら、Seasarも使わずServletに処理ベタ書きの方がいいってことじゃない？
仕事にはいろんな規模のものがあるんだから、それはそれでいいかと。
0827デフォルトの名無しさん
2005/04/21(木) 12:27:54S2JSFがSeasarのコンテナ機能を使わずUtilだけ使ってるんだったら、UtilをわけてS2+S2DAO+Util/S2JSF+Utilというふたつのパッケージでもいい。
0828デフォルトの名無しさん
2005/04/21(木) 12:37:09普通にjsf.diconとかあるけど
0829デフォルトの名無しさん
2005/04/21(木) 15:57:26もちろんそれはそれで良いと思う。
けど、だからつって物知り顔で「誰にとってもフレームワークひいてはS2イラネ」って言うのはどうかと思う。
あんだけ自信満々で言われちゃうと、漏れみたいなお馬鹿チンは「本当にいらないのかな…」って不安になっちまう。
自分は今有効に使えてるのにね。
0830デフォルトの名無しさん
2005/04/21(木) 16:23:42残念だけど、その取捨選択は君がするしか無いと思うよ。
人の言っていることを盲目的に受け入れるべきなのかそうでないのかって
ことだから。ここの人は自分が思うことを好き勝手に書いているだけだし。
>>790->>807みたいにちゃんと突っ込んだ話をしないとその根拠が
明白にならないからなかなか判断しようが無いのだけれど。
で、自分は彼の話がごく一部しか捉えていないようだと判断した。
＞自分は今有効に使えてるのにね。
これを根拠に「自分には必要だ」でも良いんじゃない？
0831デフォルトの名無しさん
2005/04/21(木) 20:39:58日本語資料の多寡は「好みの問題」ではありません。
0832デフォルトの名無しさん
2005/04/21(木) 21:57:180833デフォルトの名無しさん
2005/04/21(木) 22:53:58JAVAはフレームワーク多すぎ！て言うか、なんでもかんでもフレームワーク
って呼びすぎ！
俺のこれまでの知識では、「フレームワーク＝湯の張られた鍋」と理解してた。
具材を入れていくと料理になるという、そんなイメージ？
でも、JAVAでは制御の反転が絡むと全部フレームワークって呼びやがる。
Seasarでどんな料理が出来上がるのか、10日も探し回っちまったじゃねぇ～か！
当然、それだけでは料理になんかなるわけねぇ～！そもそも、鍋ですらねぇ～！
どっちかっつぅ～と、やかん？とにかく、俺の馬鹿＿|￣|○|||
0834デフォルトの名無しさん
2005/04/21(木) 22:57:07最初からIoCコンテナ(DIコンテナ)としか言ってないような。やかんどころかコンロですな。
0835デフォルトの名無しさん
2005/04/21(木) 23:04:07コールバックを含むライブラリのことをフレームワークと呼ぶのだよ。
0836デフォルトの名無しさん
2005/04/21(木) 23:04:50分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は
ある。て言うか、変な人ほどフレｄｊさｋｌｊｆｓぢｊｆさいｊふぉいｊ
やかんの心は、冷たい液体から温かい液体を生成するファクトリー
0837デフォルトの名無しさん
2005/04/22(金) 00:11:45> >>834
> 分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は
JARの名前がs2-framework～である件について
0838デフォルトの名無しさん
2005/04/22(金) 00:24:17Avalonは(Jamesみたいな）サーバアプリケーションを作成するためのフレームワークと銘打ってるけどね。
0839デフォルトの名無しさん
2005/04/22(金) 00:39:32Seasarの場合は、S2Daoとか周辺を含まずにフレームワークなわけで。
0840デフォルトの名無しさん
2005/04/22(金) 00:49:59Avalon Frameworkだって周辺も何も含まずにフレームワークを名乗っていた。
あれはコンテナとコンポーネントのコントラクトを規定しただけのライブラリ。
Avalon Excaliburがコンテナの実装、Avalon Phenixになるとサーバ
アプリケーション用のフレームワークという位置づけになっていたかと。
Marlinはよーわからんがそうやって発散してお亡くなりに…
0841デフォルトの名無しさん
2005/04/22(金) 01:18:27分類の根拠がなんなのか位は抑えておいてもいいだろうけどな。
0842デフォルトの名無しさん
2005/04/22(金) 10:52:460843デフォルトの名無しさん
2005/04/22(金) 10:53:490844デフォルトの名無しさん
2005/04/22(金) 21:10:010845デフォルトの名無しさん
2005/04/22(金) 21:57:18俺も学習用につくってみてもいいか？
0846デフォルトの名無しさん
2005/04/22(金) 23:45:49それは文字通りのフレームワークだと思う。
ファンクタを要求する単体のオブジェクトはどうなんだろう？
IoCを伴ってはいるけど、これをフレームワークと呼ぶのに
は激しく抵抗を感じる。
>>845
いいんじゃない？
DIコンテナという言葉こそ出てこないけど、JAVAの格言に
は、抽象ファクトリーパターンと動的クラスローディングの
組み合わせ例として、iniファイルを利用したDIコンテナが紹
介されてる。
0847デフォルトの名無しさん
2005/04/23(土) 02:17:41いいよ。
AOPまで実装すれば、とりあえずSeasarの対抗馬としてプロモーションできるし。
ドキュメントとメディアの取り込みさえできれば、すぐ広められる。
ただし、そういうプロダクトを運営するのには、結構手間がかかるし、覚悟がいる。
0848デフォルトの名無しさん
2005/04/23(土) 02:32:29SeasarやSpringと張り合おうなんて気は毛頭ないから安心してくれ。
あくまで学習用だからきれいでシンプルな実装をしたい。
0849デフォルトの名無しさん
2005/04/23(土) 10:43:19俺はそういう取り組みの繰り返しが将来の技術力を養うと思う。頑張れ。
0850デフォルトの名無しさん
2005/04/23(土) 11:24:16そしたら、機能的にはPicoContainerとかをまず見てみるといいかも。
0851デフォルトの名無しさん
2005/04/23(土) 11:42:02おいらはいい加減おっさんだが35歳で限界を迎えないように精進するよ。ありがとね。
>>850
Spring、Seasar、PicoContainerあたりの実装は確認済み。
PicoContainerのシンプルさは好きだね。
で、CgLibとjavassistの比較してるサイトとかしらん？
0852デフォルトの名無しさん
2005/04/23(土) 22:31:40>で、CgLibとjavassistの比較してるサイトとかしらん？
ここらへんってちょっと前にSeasarでも話題になってたし、はてなでもいって探せば
参考になるサイトとか出てくるんじゃねー
0853デフォルトの名無しさん
2005/04/24(日) 01:43:13AbstractFactoryが必要な部分ってシステムのコアに相当する部分で、
ここは自由にプログラミングできてしかるべきところを、
言語の非標準機能を使ってまで、統一的にする意味あんのかってあたりが微妙で、
テストしやすいとかいってるけど、これも結構あやしいと思う。
要するに、モックオブジェクトを返したいってことなんだろうけど、
冷静に考えて、それを作りたいシーンって、ホントにシステムのコアに相当する部分で、
ごく一部であって、そこをフレームワークにまかせてどうにかなるってことも、
無い気がする。有効なシーンがあれば教えてほしい。
0854デフォルトの名無しさん
2005/04/24(日) 02:39:08もうフレームワークって呼ぶな。話が無駄に混乱する。
有効なシーンも何も、幹と枝葉の相関を切りたいという要求は
普通にと言うより普遍的にあるはずだが・・・・・・
0855デフォルトの名無しさん
2005/04/24(日) 02:57:19切りたい欲求はそんなに無い、あったとしても、
そこはそのアプリケーションに合った適切な切り方をしたほうが
DIコンテナ機構を使うよりいいってこと思うんだけど
0856デフォルトの名無しさん
2005/04/24(日) 21:42:58> そこはそのアプリケーションに合った適切な切り方をしたほうが
「アプリケーションに合った」部分をDIコンテナは侵食しないぞ。
あなたの設計だと、Factory部分のコードがアプリケーションによって変わってくるのか？
かなりひどい設計だと想像するけど。
0857デフォルトの名無しさん
2005/04/24(日) 22:57:32>>856
どう言っても無駄だと思うぞ。
変な話だが、円滑なコミュニケーションにデザパタがどれほど大き
く寄与してるか実感した。
JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
からコンパイルへの依存を排除できる点」だよ。
で、説明は終わりなんだよな。
多段に積み重なった知識の最上段のみを対象に会話を進めていく
って行為は、モードの違う相手とはチャンネルが合わないんだなとｗ
0858デフォルトの名無しさん
2005/04/24(日) 23:44:32> JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
> からコンパイルへの依存を排除できる点」だよ。
> で、説明は終わりなんだよな。
使ってるやつはそれで説明が終わりと思ってて、使ってないやつにとってはそれでは説明になってないと思う。
0859デフォルトの名無しさん
2005/04/25(月) 00:10:03SeasarにしてもSpringにしても使うのちとめどい・・・
Picoのほうが個人的には好きなのだが、それほど使われてない模様
SeasarにコアのDI以外にも便利な機能って何が入ってるのさ
S2Strutsはそれほど便利でなかったし、
JDBC連携もDbUtilsとかで代用できんの？
ともかくXMLの設定とかめどい
0860デフォルトの名無しさん
2005/04/25(月) 02:07:250861デフォルトの名無しさん
2005/04/25(月) 02:24:32>Factory部分のコードがアプリケーションによって変わってくるのか？
ソフトウェアの核になる部分って、やっぱり
キャッシュを解放するタイミングとか、ログの取り方、バックアップの取り方、パフォーマンスの計測とか
いろいろやることがあって、変わるに決まってると思うのだが
0862デフォルトの名無しさん
2005/04/25(月) 02:56:030863デフォルトの名無しさん
2005/04/25(月) 14:14:53XMLがめんどいというやつは、Springをちょっと使って、
Seasarを使ってないやつに多い｡
Picoがいいというやつは、最近あまりみたことないが、
PicoよりはSeasarが簡単だろう｡
同じようにコンストラクタによるAutowireができて、
classを登録するだけですむんだから｡
APIをじかにたたく分には、SeasarもPicoもあまりかわらない。
0864デフォルトの名無しさん
2005/04/25(月) 18:17:21ファクトリーは生成のパターンだから構造や制御とは無関係だよ。
0865デフォルトの名無しさん
2005/04/25(月) 19:03:38頭がツルツルなのがきたら、スルーでおっけ
0866デフォルトの名無しさん
2005/04/25(月) 19:08:27factory method数≒全クラス数
ただしfactory methodは大抵singletonを返す
ってのが居た。あの類だろｗ
0867デフォルトの名無しさん
2005/04/26(火) 00:15:33フツーにnewするのがナニが不満なのか。
なんでもないところにAbstractFactory用いる意味は無い。
もしAbstractFactoryを導入する価値のある個所があるのだとすれば、
それはシステムのコアであるから、どっちにしろ、ここは自由にプログラミング
できないと無意味である。
0868デフォルトの名無しさん
2005/04/26(火) 00:21:47なんて、１日の試用でわかるんじゃねえの？ EJB使った上で、DIなんて無意味非効率めんどくせえ、
とかいうやつがいたら、どっかいかれてるとしか思えん。
0869デフォルトの名無しさん
2005/04/26(火) 00:58:12て言うか、十中八九こいつVBプログラマだｗ
0871デフォルトの名無しさん
2005/04/26(火) 01:54:49あれだね。
EJBを必要と思わなかったら、まったく意味のない比較だね。
めちゃくちゃめんどいEJBがめんどいDIになっただけということ？
0872デフォルトの名無しさん
2005/04/26(火) 02:44:31そりゃそうだろ。DIコンテナが生まれてきた経緯を考えると、EJBへのアンチテーゼ
そのものなんだし。解決しようとしてる土俵で比較するのが筋じゃないか？
めちゃめちゃしんどいEJBが楽なDIコンテナに変わったってことだろ。
EJBはめんどいけど、コンテナのインスタンス制御機能（つまりファクトリとしての機能）や、
コンテナ制御のトランザクションなんて機能自体は必要なんだよ。そのために苦労して
EJB使うわけで。
DIコンテナはその両方を簡単に解決するじゃん。DIコンテナよりも簡単にEJBの機能を
提供してるものがあるんだったら、おれはすぐにでもそっちに乗り換えるよ。
0873デフォルトの名無しさん
2005/04/26(火) 03:30:160874デフォルトの名無しさん
2005/04/26(火) 04:05:050875デフォルトの名無しさん
2005/04/26(火) 04:14:520876デフォルトの名無しさん
2005/04/26(火) 05:00:17XMLはツールとの相性のよさってのがあって、
人間にも読めて機械にも読めるフォーマットとして意味があると思うんだけど、
なんつーか、DIコンテナなんつーものは、
本来はプログラミング言語が兼ね備えているべきレベルでの単純すぎるオブジェクト生成
にしか使えなくて、フツーにnew するのと変わらん。そんなのに意味あるか。
むしろそういうことなら、Eclipseのプラグインアーキテクチャにおけるxmlによる、
読み込むクラスの定義のほうが、価値があると思う。
0877デフォルトの名無しさん
2005/04/26(火) 05:46:20XMLでの定義がいやなら、アノテーション。
0878デフォルトの名無しさん
2005/04/26(火) 06:58:170879デフォルトの名無しさん
2005/04/26(火) 09:33:51＞本来はプログラミング言語が兼ね備えているべきレベルでの単純すぎるオブジェクト生成
＞にしか使えなくて、フツーにnew するのと変わらん。そんなのに意味あるか。
このあたりが何を言いたいのかもう少し知りたい。
それと、どんなアプリを作る人なの？
この辺の違いがわかると話が噛み合ってくると思う。
0880デフォルトの名無しさん
2005/04/26(火) 18:29:17正直、EJB3は全く追いきれてないんだが、DIコンテナ＋AOPという小さな
機能部品としてのSeasarには需要が残り続けると思う。
0881デフォルトの名無しさん
2005/04/26(火) 18:41:16>読み込むクラスの定義のほうが、価値があると思う。
いや、それがDI(Dependency Injection = 依存性の挿入)でしょ？
コンパイルへの依存性を排除できるって、そういう事だと思ワン？
「価値があると思う」って、思いっきり認めちゃってるみたいだけど・・・・・・
えと、どういう事？DIコンテナは認めるけど、Seasarは駄目って話？
て言うか、スレが進むうちに段々DIコンテナの利点が分かってき
たんじゃないか？別に無理繰り否定する必要はないんだぞ？
0882デフォルトの名無しさん
2005/04/26(火) 19:36:20それを一般アプリケーションに広げる価値はないといってるのでは？
0883デフォルトの名無しさん
2005/04/26(火) 20:19:59もっと楽な方法が出てきそう
0884デフォルトの名無しさん
2005/04/26(火) 20:22:20DIをするための方法として、一般的にDIコンテナと呼ばれている物の
方法は良くないと言いたいのかねぇ。
あ、違うよ。きっと彼はプラグインがDIだってわかってなかったんだ。
むしろそういうことなら、こんな不毛な議論なんかやめて
別の話したほうが、価値があると思う。
0885デフォルトの名無しさん
2005/04/26(火) 23:39:22「AとBを結びつけるときに、その結びつきがAやBの中に直接埋
め込まれているのではなく、Cがその仲介をしてあげてくれると
AとBの実装がお互いに依存しなくて嬉しい」
っていうのがDIのありがたみだと思うのだけれど、これ自体には
異論はないのかな。
それともこれ自体に異論があるのか？
で、DIコンテナは上記のCにあたるところを一括して面倒みてく
れるのだけれど、その方法として「AやBの生成を請け負う」とい
うやりかたをしているため、その副作用として「生成したものを一
定の方法で改ざんできる（＝AOPを適用できる）」というメリットが
出てきていて、そこが個別にAbstractFactoryを用いるのとは決
定的に異なるのかなと。
0886デフォルトの名無しさん
2005/04/27(水) 01:09:19あらたにCを導入して依存関係を複雑にしてるだけにも読めるが。
ともあれDI使ったところでAとBは依存するし、使わなくても実装が依存しないようにできるし。
0887デフォルトの名無しさん
2005/04/27(水) 01:17:550888デフォルトの名無しさん
2005/04/27(水) 01:58:33つーかスレ違いだ。DIスレでやれ
0889デフォルトの名無しさん
2005/04/27(水) 02:28:03インターフェースに対しても同じ様な反応があるな。
AクラスとBクラスがそれぞれCインターフェースに依存してる。依存関係を複雑にしてる
だけなのではないか？と・・・・・・
「インターフェースに対してプログラミングする事でクラス間の依存性を排除できる」とい
う教科書的な説明は、間を省略し過ぎてて実は説明になってない。
インターフェースに対してプログラミングする事で直接的に排除できるのは特定のクラス
型に対する依存性で、これを排除しようとするモチベーションはJAVAが多重継承をサポ
ートしていないという点から湧いてる。
例えば、スレッドの実現にそのサブクラスである事を要求されたら？コールバックを実現
するのに特定のクラス型を要求されたら？インターフェイスを用いてクラス間の依存性を
排除するとはこういう事を指してる。
DIについても同じ視点から考察してみてほしい。教科書的な説明よりも、もう少し詳細な
視点で、DIが本当に排除してる依存性とは何なのかと、俺なりの視点については明日の
晩にでも書くつもりだけど、先ずは自分なりに考えてみてほしい。
0890デフォルトの名無しさん
2005/04/27(水) 05:05:20コンパイル依存排除が目的っていうなら、それは無意味だ
拡張するためのアプリケーションで、拡張方法が明確に定義されているときのみ、
xmlでインスタンス化する対象を定義する意味があるのであって、
一般的なアプリケーションでわざわざxmlを書いてインスタンス化するもの
決める必要な無い。
>>889
Javaにインターフェースがある理由って、ハッキリ言わせてもらうと、型が合ってないと
コンパイルエラーで実行前に知らせてくれるっていう、それ以外にありえない。
インターフェース無くして、実行時にメソッドの有り無しのみでポリモーフィズム
やっても、問題は無いでしょ。
デメリットはコンパイルエラーが無くなってちょっとエラー発見が遅れることなのであって。
0891デフォルトの名無しさん
2005/04/27(水) 08:01:16http://pc8.2ch.net/test/read.cgi/tech/1099827125/
0892デフォルトの名無しさん
2005/04/27(水) 09:22:490893デフォルトの名無しさん
2005/04/27(水) 11:02:17それぞれ別スレでやるべきですね。
0894デフォルトの名無しさん
2005/04/27(水) 11:10:36InterfaceはSeasarとは無関係です。
初心者はSeasarとは無関係です。
さすが、閉鎖的なことで定評のあるSeasarです。
0895デフォルトの名無しさん
2005/04/27(水) 12:17:080896デフォルトの名無しさん
2005/04/27(水) 13:04:420897デフォルトの名無しさん
2005/04/27(水) 13:53:590898デフォルトの名無しさん
2005/04/27(水) 14:53:250899デフォルトの名無しさん
2005/04/27(水) 15:30:510900デフォルトの名無しさん
2005/04/27(水) 20:37:36>>896
そういう無意味な煽りが、余計にウンチを産んでるのをいい加減分かれよ。それともおまいもアンチSeasar/DI？
で、>>890 >>インターフェースがある理由
理由はそうであれ、そこを原点にして様々なメリットが生まれてる。
あと、遅れるのは「ちょっと」どころではないぞ。規模が大きくなればなるほどね。
テスト段階でも発見できなくて、稼動後に発見なんて可能性も大いにある。これは大問題だ。
0901デフォルトの名無しさん
2005/04/27(水) 22:25:540902デフォルトの名無しさん
2005/04/27(水) 22:40:38EJB3は素敵ですよ
Seasar2はS2Daoが素敵ですがS2JSFはいうほどではありません。
0903デフォルトの名無しさん
2005/04/27(水) 22:41:46ttp://220.111.244.199/otakara/idol/050427a1.jpg
0904デフォルトの名無しさん
2005/04/27(水) 22:43:49チンパンジーのアイちゃんが
書き込んでいます（はぁーと
(霊長類研)
-----------------------------------
0905デフォルトの名無しさん
2005/04/28(木) 02:03:160906デフォルトの名無しさん
2005/05/02(月) 22:13:23非常に分かり易くDIについて書かれてる。
これくらい噛み砕いてあると、非JAVA脳な人にはすんなり入ると思う。
0907デフォルトの名無しさん
2005/05/03(火) 07:53:380908デフォルトの名無しさん
2005/05/03(火) 14:27:05局所化してデバッグしやすいとかいって、
DIのメリットとオブジェクト指向プログラミングのメリットを
すり替えしてんじゃん。
こんなネタに騙される奴なんか顔も見たくないよ。
0909デフォルトの名無しさん
2005/05/05(木) 22:48:43>局所化してデバッグしやすいとかいって、
>DIのメリットとオブジェクト指向プログラミングのメリットを
>すり替えしてんじゃん。
禿同。
最近そこんとこを勘違いしてる人が多いよね。
まあ、勘違いであろうがなかろうが、テスタビリティの高い(=高凝集で疎結合な)プログラムが作られることは大歓迎。
0910デフォルトの名無しさん
2005/05/05(木) 22:57:46アンケートとったんかよ、わりゃ（激笑
0911デフォルトの名無しさん
2005/05/05(木) 23:49:06周りがよっぽど優秀か、
それとも業務以外に興味がないかどちらかですね
0912デフォルトの名無しさん
2005/05/06(金) 00:13:44はやくOO抜きでAOPできるようにならんと、
またOOの二の舞になる予感がする (判ってないのがデタラメを広める)
0913デフォルトの名無しさん
2005/05/06(金) 00:14:400914デフォルトの名無しさん
2005/05/06(金) 00:28:060915デフォルトの名無しさん
2005/05/06(金) 11:42:57OOの二の舞ってことは、すごく普及して当たり前になるってことか。
0916デフォルトの名無しさん
2005/06/02(木) 01:47:530917デフォルトの名無しさん
2005/06/02(木) 01:59:55まあ本家にもこれといった動きは無かったしな。
0918デフォルトの名無しさん
2005/06/02(木) 04:13:390919デフォルトの名無しさん
2005/06/02(木) 04:20:54なんかいろいろあったみたいよ。なんかいいたそうだよ。
すなあそびとか決まったときにいろいろ人に言えない話が決まったんじゃないの？
0920デフォルトの名無しさん
2005/06/02(木) 08:49:01ナニを露出したんだ？
0921デフォルトの名無しさん
2005/06/02(木) 19:49:510922デフォルトの名無しさん
2005/06/02(木) 21:59:140923デフォルトの名無しさん
2005/06/02(木) 22:40:440924デフォルトの名無しさん
2005/06/02(木) 23:12:580925デフォルトの名無しさん
2005/06/03(金) 03:25:400926デフォルトの名無しさん
2005/06/03(金) 04:17:47http://www.seasar.org/publication.html
0927デフォルトの名無しさん
2005/06/03(金) 07:04:44でもリソースからたどれねぇですよ。
0928デフォルトの名無しさん
2005/06/03(金) 07:06:540929デフォルトの名無しさん
2005/06/03(金) 07:10:400930デフォルトの名無しさん
2005/06/04(土) 00:58:20修正しますた
0931デフォルトの名無しさん
2005/06/04(土) 15:40:15乙
0932デフォルトの名無しさん
2005/06/04(土) 21:16:530933デフォルトの名無しさん
2005/06/04(土) 21:17:15http://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
0934デフォルトの名無しさん
2005/06/11(土) 08:13:41getComponent(Class)とgetComponent(String)のほうが自然な気がするのですが。
0935デフォルトの名無しさん
2005/06/12(日) 23:37:08引数としてはどうせ定数かリテラルしか使わんだろうし、分けた時のメリットもデメリットも余り無いってのもあるかと。
0936デフォルトの名無しさん
2005/06/13(月) 23:47:17結構好き
0937デフォルトの名無しさん
2005/06/13(月) 23:54:28あんな所でマターリとオプソ開発したかったな
0938デフォルトの名無しさん
2005/06/13(月) 23:55:17何かイベントがあったの？
それとも内輪のミーティング？
0939デフォルトの名無しさん
2005/06/14(火) 00:12:55ISID（電通国際情報サービス）の評価は？
http://science3.2ch.net/test/read.cgi/infosys/994954074/l50
こんなスレもあるんで、会社ってより
個人の力量も相当あると思われます。
0940デフォルトの名無しさん
2005/06/14(火) 00:21:40福岡のイベントなんジャマイカ？
0941デフォルトの名無しさん
2005/06/14(火) 00:43:36public 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じゃなくてスレに書いてみる。
0942デフォルトの名無しさん
2005/06/14(火) 00:52:36親と子でTABLEアノテーションが変わるのは
違和感があるけどなあ。
あーでも最近は継承テーブルとかいうのもあるんだよな。
0943デフォルトの名無しさん
2005/06/14(火) 06:56:25福岡のJavaセミナー
0944デフォルトの名無しさん
2005/06/23(木) 14:35:440945デフォルトの名無しさん
2005/06/23(木) 15:17:050946デフォルトの名無しさん
2005/06/23(木) 15:26:190947デフォルトの名無しさん
2005/06/23(木) 15:34:40随分な粘着っぷりだな（藁
0948デフォルトの名無しさん
2005/06/23(木) 15:40:010949デフォルトの名無しさん
2005/06/23(木) 15:43:18漏れも叱られてみてぇ～
じゃ、ずばり言うわよ ！！！
（ﾄﾞｷﾄﾞｷﾄﾞｷﾄﾞｷ
0950デフォルトの名無しさん
2005/06/23(木) 15:46:00同時接続数を１にしてどうすんねん
0951デフォルトの名無しさん
2005/06/23(木) 16:24:11その話題には全然参加してないけど、自分に言われてるみたいで反省＿ノフ○
0952デフォルトの名無しさん
2005/06/23(木) 16:28:39ｺﾚｶﾜｲｲ
＿ノフ○
0953デフォルトの名無しさん
2005/06/23(木) 16:38:430954デフォルトの名無しさん
2005/06/23(木) 16:39:09>>952
たしかに、＿ノフ○ なんかいい感じだな。
0955デフォルトの名無しさん
2005/06/23(木) 20:13:590956デフォルトの名無しさん
2005/06/23(木) 20:15:51影響力が強すぎる気がするな。
0957デフォルトの名無しさん
2005/06/23(木) 20:24:46放っておけばおとなしくなると思ったのに、ひが氏出てきてかえってややこしくなったような。
0958デフォルトの名無しさん
2005/06/23(木) 21:06:22連続投稿って掲示板だけでなくML上でも結構うざいんだってことはよく分かった。
それよりも、ｋ氏の親分とひがﾀﾝの関係がまずくなったりしないかな？と余計な心配をしてみる。
0959デフォルトの名無しさん
2005/06/23(木) 21:07:57(1)ただいまブレイク中のイチャモンＫ
(2)モデル・アイドル大好きオタクＫ
(3)理事か何かのとてもエライＫ
で(2)が(1)や(3)と意見がぶつかり気味。
コミッタ複数いて表面的には民主主義的だけど、
実際にはひがﾀｿとモデルおたくＫの思想・哲学に
かなり引っ張られている。もちろん彼らは優秀だと
思うけど。
0960デフォルトの名無しさん
2005/06/23(木) 21:22:05(5)hibernateのk
(6)mﾀｿのk
(7)読書会のk
(8).NETのk
(9)RMIのk
だいたいHとKでまわってるな。
0961959
2005/06/23(木) 21:33:300962デフォルトの名無しさん
2005/06/23(木) 22:04:020963デフォルトの名無しさん
2005/06/23(木) 22:07:53(11)mavenのk
(12)seasar wikiのk
0964デフォルトの名無しさん
2005/06/23(木) 22:18:29Kしかいないぞ
0965デフォルトの名無しさん
2005/06/23(木) 22:21:59(1)中心人物のh
(2)アニオタh
(3)アニオタ部下h
0966デフォルトの名無しさん
2005/06/23(木) 22:27:010967デフォルトの名無しさん
2005/06/23(木) 22:28:330968デフォルトの名無しさん
2005/06/23(木) 22:29:170969デフォルトの名無しさん
2005/06/23(木) 22:33:22元sourceforgeうp担当かな？
今は(2)の部下じゃなくなったはずだが…
0970デフォルトの名無しさん
2005/06/23(木) 22:35:240971デフォルトの名無しさん
2005/06/23(木) 22:36:34コード書かない奴はクソ
0972デフォルトの名無しさん
2005/06/23(木) 22:39:370973デフォルトの名無しさん
2005/06/23(木) 22:41:250974デフォルトの名無しさん
2005/06/23(木) 22:42:37ttp://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20041120/152861/
0975デフォルトの名無しさん
2005/06/23(木) 22:50:09kの(3)はすぐわかるからhの(3)の話じゃね？
0976デフォルトの名無しさん
2005/06/23(木) 23:37:34ばかぃやるぉう！
HBたんは殺伐としがちなSeasarプロジェクトのの「和み」担当じゃないかｯ！
0977デフォルトの名無しさん
2005/06/23(木) 23:52:35殺伐(2) Seasar-user:2050～ k(2)とk(3)
殺伐(3) Seasar-user:2215～ k(1)とk(2)とh(1)
全てk(2)絡みw
0978デフォルトの名無しさん
2005/06/24(金) 00:02:350979デフォルトの名無しさん
2005/06/24(金) 02:01:560980デフォルトの名無しさん
2005/06/24(金) 02:13:45豚の餌ほどの役にも立たないおまいより全然ましw
0981デフォルトの名無しさん
2005/06/24(金) 03:59:18四国乙
0982デフォルトの名無しさん
2005/06/24(金) 04:04:49ってか、k(1)だと名前どおりになる。
0983デフォルトの名無しさん
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
という感じ？
0984デフォルトの名無しさん
2005/06/24(金) 09:45:540985デフォルトの名無しさん
2005/06/24(金) 12:04:18k(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
0986デフォルトの名無しさん
2005/06/24(金) 12:32:310987デフォルトの名無しさん
2005/06/24(金) 12:40:51k(2)やk(3)は押し付けがましい
0988デフォルトの名無しさん
2005/06/24(金) 13:13:24k(3)は社長だからたっぷり稼いでる
k(1)もブランド漁るくらい稼いでる
k(2)くらいしか応援できん
0989デフォルトの名無しさん
2005/06/24(金) 13:42:280990デフォルトの名無しさん
2005/06/24(金) 15:15:220991デフォルトの名無しさん
2005/06/24(金) 15:35:570992デフォルトの名無しさん
2005/06/24(金) 19:24:40国産DIコンテナSeasarとくーす その４
http://pc8.2ch.net/test/read.cgi/tech/1119608621/
0993デフォルトの名無しさん
2005/06/24(金) 19:44:08「○○は俺の考えたようには（動かない、だから俺はこのようにソース変更して使っている」
その使い方に問題がある可能性は微塵も考えないんだろうか。
0994デフォルトの名無しさん
2005/06/25(土) 00:46:400995デフォルトの名無しさん
2005/06/25(土) 01:07:17＞# 表現が大切になると思います．
ﾃﾗﾜﾛｽwwww
0996デフォルトの名無しさん
2005/06/25(土) 01:58:530997デフォルトの名無しさん
2005/06/25(土) 02:09:35漏れはk(1)のほうを応援する
0998デフォルトの名無しさん
2005/06/25(土) 02:14:20k(3)は社長だからたっぷり稼いでる
k(1)もブランド漁るくらい稼いでる
k(2)くらいしか応援できん
0999デフォルトの名無しさん
2005/06/25(土) 02:17:181000デフォルトの名無しさん
2005/06/25(土) 02:17:371001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。