トップページ⇒tech
1001コメント376KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ?みんなもう使ってるの?
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。

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


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

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

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


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


関連スレ(なのか?)

Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
002515NGNG
いやゆるさん!
002614NGNG
。・゚・(ノД`)・゚・。ウワーン
002721NGNG
>>22
感激だっ。ありがとうひがさん....
0028デフォルトの名無しさんNGNG
見てるとは思うけど、お礼コメントしてきたらよいかも。
0029デフォルトの名無しさんNGNG
お礼だけのコメントは情報量ないから止めた方がよくないか?
お礼がズラズラと並んでる図は信者臭くてダサいし
0030デフォルトの名無しさんNGNG
お礼と一緒に喧嘩も売るとか
0031デフォルトの名無しさんNGNG
趣味悪いなー
0032デフォルトの名無しさんNGNG
「ひがたん、乙」とだけ書いてくればいいのではないか?
0033デフォルトの名無しさんNGNG
とっておきのエロ画像とか貼るのがいいのではないか?
0034デフォルトの名無しさんNGNG
蛯○友里の愛顧らなどがよろしいかと。
0035デフォルトの名無しさんNGNG
AOPをフルに使用したコラが良いと思われ。
0036デフォルトの名無しさんNGNG
最近大きな変化は無いね。

早く、事例集を作らないかなあ。
実績がはっきりしてナイト採用しないところもあると思うんだけどねぇ。
0037デフォルトの名無しさんNGNG
>>36

ネタに騙されてるよ
0038デフォルトの名無しさんNGNG
>>37
ネタ?
MLでの導入事例集作成のやり取りのことですか?
0039デフォルトの名無しさんNGNG
ひがさん仕事はやー。ちょっと追いかけるの休んでると、どんどん機能がリリースされてく。
つーかおれ、未だにAOPの使い方がよくわかんね。コンテナ機能だけでも便利だからいいけどさ。 orz
0040デフォルトの名無しさんNGNG
AOPつかわねーと意味ねーじゃん。
0041デフォルトの名無しさんNGNG
AOP使わないとS2Dao使えないし、自動トランザクション制御使えないし、
モックオブジェクト使えないし、デリゲートも自動でできないんだぞ。だめじゃん。
0042デフォルトの名無しさんNGNG
>>39
とりあえず、ドキュメントどおりにdiconファイルに記述すればOK
0043デフォルトの名無しさんNGNG
マジレスすると自分で考えてAOPを使うのが難しいってことだろ。
考えながら付属のやつを使ってりゃそのうちinterceptorを自作するようになるさ。
0044デフォルトの名無しさんNGNG
http://d.hatena.ne.jp/higayasuo/20041217#1103278289

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

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

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

どちらも何の問題もないように思いますが。
0045デフォルトの名無しさんNGNG
> これは、BeanMetaDataに多くの責任を持たせていたためです。
> SQLを自動生成したり、Beanからバインド変数を組み立てたり
> という役割は、メタデータを管理するというBeanMetaDataの
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。

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

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

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

例えば

BeanSchema.toXML

のようなメソッドはBeanMetaDataクラスに持たせるべき責務のように
思えます。
0046デフォルトの名無しさんNGNG
> 振る舞いを役割ごとに分割する、言い方を変えると振る舞いを
> モデリングするという考えは、重要ながらかなり見落とされている
> ことが多いのではないでしょうか。

よくわからないので、
具体的な例を挙げていただけませんか?
0047デフォルトの名無しさんNGNG
SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
べきだった、という話じゃないの?

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

その点についてはおれは反対する要素はないぞ。
0048デフォルトの名無しさんNGNG
>>47
> SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
> メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
> べきだった、という話じゃないの?
>
> で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
> するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。

うんにゃ、
ひがさんは BeanMetaDataには振る舞いを持たせるべきではない、と言っているよ。
0049デフォルトの名無しさんNGNG
>>46
ここではなくてblogのコメントに書いていただけませんか?
0050デフォルトの名無しさんNGNG
> 永続化されるデータに業務に応じた振る舞いを持たせるというのは、
> 1つのクラスに複数の役割を持たせることになります。

なりません。

データは何一つサービスを提供しません。
よって、データは責務を持ちません。
0051デフォルトの名無しさんNGNG
そりゃおかしいだろう。
S2Daoのソース読んだわけじゃないから詳しいことは分からんが、
少なくとも>>45には激しく同意。
Object指向としての理想的なモデリングは、SwingとかEclipseなんかが
参考になるとは思うんだが、その中にデータを表すってだけの
構造体みたいなクラスは見当たらんよね。ま、ドメインが違うじゃんって
いわれればそれまでだけど。
くーすはどうも退化としか思えないんだよね。
目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
柔軟性や多態性なんかが損なわれてる気がする。
005251NGNG
ごめん、51は>>48に対するレスね。
0053デフォルトの名無しさんNGNG
>>51
目先のお手軽さや便利さを求めちゃ何故まずいんだろう?

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

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

お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの?
005446NGNG
>>49
そんな度胸ありません!
0055デフォルトの名無しさんNGNG
>>51
> くーすはどうも退化としか思えないんだよね。
> 目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
> 柔軟性や多態性なんかが損なわれてる気がする。

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

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

必死で書き込んでる奴らは
ヒガ氏の掌で踊らされているだけだということを
自覚したほうがいいな(藁
0057デフォルトの名無しさんNGNG
44=46=48!=54ですが。

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

そのとおりですw
0058デフォルトの名無しさんNGNG
>>55
みなさんはいい部下をお持ちのようですね。
うちは素人だらけなので後ろ向きな方法論で結果を出すしかありません。
しかも、各自で技術力を向上させようとする前向きさも、センスもない連中が山ほどいます。まじで皆さんがうらやましいです。
005958NGNG
>>58
誤 後ろ向きな方法論で結果を出すしかありません
正 後ろ向きな方法論を利用してでも結果を出すしかありません

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

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

技術者ならくーすの技術面について話をしようぜ。
0061デフォルトの名無しさんNGNG
技術の世界でスキルのない人間使ってそれなりの成果物をあげることは、かなり
技術者よりの話題だと思うんだが。

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

で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
づけしたもんなんだし。
0062デフォルトの名無しさんNGNG
ひがさんの「BeanMetaDataには振る舞いを持たせるべきではない」という方針は
現場の事情で、その対価としてOOP的な「柔軟性や多態性なんかは損なわれて
いる」という結論でいいんですか?本当に?

アホでも素人でも妄想でも語れる現場話にしたい人は置いとくとして、エンジニア
の人達はこの結論でいいの?本当に?
006344NGNG
>>61
>で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
>呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
>づけしたもんなんだし。

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

ただ、的外れな指摘で「レガシーなオブジェクト指向」とかいうのはやめて欲しい。すごく迷惑。
0064デフォルトの名無しさんNGNG
要するに、
ヒガ氏の提唱しているのはビジネス的な視点での方法論で、
ここで書き込んでる人たちはビジネス的は視点としては理解はできるものの
技術的な視点で話をしたいと。

それじゃ、話が合うわけねーじゃん。
つーか、なんでそんな人たちがヒガ氏やらくーすやらに興味持ってるのかさっぱりわからん。
0065デフォルトの名無しさんNGNG
>>60
くーすの技術面?

くーす語るんだったら技術面じゃなくて
ビジネスでの有効性だとかそういう話じゃないの?
0066デフォルトの名無しさんNGNG
とりあえずハッキリしてるのは、ヒガ氏の実装で得られる利点と、損なわれる難点を
技術的に語れる人間はこのスレには居ないって事だ。

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


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

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

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

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

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

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

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

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

データと振る舞いをまとめるときに、「データと直結した振る舞いを持たせる」「データをつかった
ほげほげは別にする」というのはオブジェクト指向的には正しい判断じゃないか?
0069デフォルトの名無しさんNGNG
>>67
ああ、それ自体は技術の話題だ。
でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。
0070デフォルトの名無しさんNGNG
>>69
> >>67
> ああ、それ自体は技術の話題だ。
> でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
> 技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。


もしそうっだったとしたら、なぜひがさんは
従来のオブジェクト指向を「レガシー」と言って技術的に批判するの?
0071デフォルトの名無しさんNGNG
おれは言ってる事はともかくとして、「レガシー」という表現を使ったことについてはおかしいと思う。

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

ま、「レガシー」って言っちゃったのは失言でしたってこった。
どれだけ多くの人たちがあなたのBlogをチェックしてんのか忘れないでね。>>ひが氏
0073デフォルトの名無しさんNGNG
しかしまあ、正直言って「importって何の意味があるんですか」「java.langはimportしなくちゃ
いけないんですか」とか聞く奴が毎年量産されていることを考えると、そいつらと一緒に仕事
していく手法を身につけとかないといけないってのは切実な問題かもしれん。

だって毎年量産されるんだし...
0074デフォルトの名無しさんNGNG
いやぁ、くーすはともかくとして、Seasarは明らかにシステム構築の敷居を高くしているよ。
いろいろ覚えることあって大変だ。何がどういう役割を持っていてどう扱うのが正しいのか、
原作者にしか分からない理論(しかも、漏れ的には相当あやしい)を理解するのに何年かかるんだ。
そして覚えてそれで一体何になるのか。謎は深まる。
0075デフォルトの名無しさんNGNG
何年って、おれは使い始めて1ヶ月後にはチームの連中に説明してたが....
0076デフォルトの名無しさんNGNG
くーす周辺の「お客様」とか「現場」は、目の前の客と現場に部分最適化して、
将来の客と現場に対する思考を停止するためのエクスキューズ用語。
0077デフォルトの名無しさんNGNG
さらにチームの連中は「Struts覚えるより仕組みが簡単ですね」とか言ってたが....
0078デフォルトの名無しさんNGNG
独自の複雑なフレームワークを駆使した開発方法を
示して難解フレームワーク固有の知識で壁を構築するっていうのは、
よく見かける手ではあるけどね。

シンプルな解決法は他にいくらでもあるのに。
本当にいいものは分かってもらおうという迫力が文章やコードで示されてる
のだけど、Seasarは・・・、まぁ、しょうがないな。
0079デフォルトの名無しさんNGNG
>>68
なんか凄い自信家ですねw

>>それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
>>かなり微妙だし、俺も正直言って間違うよ。
この辺に自惚れさが見え隠れしているように感じられるのは気のせいでしょうか?
0080デフォルトの名無しさんNGNG
>>77

そうだな。Strutsよりはマシかもしれん。
Strutsも大いなるネタの代表例でさ、あれよりいいってうのは、
果たして。大差は無いように思う。
0081デフォルトの名無しさんNGNG
なんかわからんが、Seasarはファクトリ+AOPだし(というかDIコンテナは大体そうだわな)、
くーすはWeb開発ノウハウの集合体であって、別に独自のフレームワークや固有の知識だと
思った事ないんだが。むしろ「あーたしかにそんな感じでやってるよ」ってくらいで。

逆にその「まとめよう」というところに価値があると思ってる。
0082デフォルトの名無しさんNGNG
すごい勢いでレスがついてますね。
みんな比嘉さんにもてあそばれてるなあ。

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

しかし、Blogで2ちゃんのスレに煽りを入れて、
こんなにたくさんの人が踊らされるなんて、さすが比嘉さん。
0083デフォルトの名無しさんNGNG
むしろひが氏のネタの半端さがレスを呼んでるんじゃないの。
DIスレの213=332と同様。厨がいたほうが一見盛り上がってるように見える罠。
0084デフォルトの名無しさんNGNG
>>82

そうか。やっぱり、ネタだったのか。
くそー、悔しい。
まぁ、そりゃそうか。
でも、本当にイカンのはマジなトーンで
DIコンテナORマッピングAOPとか言ってるやつらだぞ。
思わず反応してしまう・・・
0085デフォルトの名無しさんNGNG
まあ自分の主張を目立つように書こうとしてつっぱしり過ぎたってとこだろう。
もし本気でレガシーって思って書いてたら、S2自体の価値が疑われかねないので、
調子のって突っ走ってしまったと思いたいね。

まあ一方で、データと振る舞いの組み合わせ方は微妙な判断が必要な問題だ
と思う。その判断を卒業したてのPGに任せたくはないが、やらせないと低能の
ままの奴と付き合い続けなければいけないというジレンマに...
0086デフォルトの名無しさんNGNG
>>84
ほんとにもてあそんぶためのネタとしてレガシーなんて言ったんだとしたら、S2に対する指示を
失いかねないネタだと思うぞ。

おれは勢い余ったんだと思うけどね。
0087デフォルトの名無しさんNGNG
指示=支持
0088デフォルトの名無しさんNGNG
とりあえず呼んどくか。

  ☆ ティン

       ☆ ティン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  ヒガタソ消火まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

DIスレをリスペクトして「ティン」だ。
0089デフォルトの名無しさんNGNG
結論:やっぱEJB。
0090デフォルトの名無しさんNGNG
>>89

EJBが実は最も壮大なネタで、
それよりマシなものなら「漏れにも作れる!」
と思う香具師、たくさんいるんじゃないかね。
しかし、EJBよりマシなものできたところで、
EJB自体がネタだから、どっちにしろネタなのだ。
0091デフォルトの名無しさんNGNG
似た方向を目指しててそれぞれ一長一短なモノなら、
メジャーな手法を使うのは当然だよな。
0092デフォルトの名無しさんNGNG
ふ〜ん
0093デフォルトの名無しさんNGNG
まあ、Java自体がネタだからね。
0094デフォルトの名無しさんNGNG
>>82
レガシーっていってるのは、1つのクラスが役割を複数持ってる
ような設計のことでしょう。
これまでのオブジェクト指向がすべてレガシーっていってるわけじゃない。

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

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

やっぱりね、Seaserに限った事じゃないけど楽になるだろうって思って
使うのは、全体的に見て楽になるかを見ないといかんね。
0096デフォルトの名無しさんNGNG
でも

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

だそうですから。
0097デフォルトの名無しさんNGNG
DIっつっても、DIで作られたクラス使う分にはただのファクトリなんだし
対して技術的に難しい概念ってことはないと思うが。
009895NGNG
>>97
>技術的に難しい概念ってことはないと思うが。
OOで一回でも作った事がある人は難しいとは思わんとだろうけど
お客はそうじゃないし。

DBAがプログラム中にSQLがあるのとO/Rマッパ使ってるときとで
インパクトが違うのとにてるんでないかなーと。
0099デフォルトの名無しさんNGNG
>>95
実装を意識する必要はないというやり方ですからね。
気にするのは、インターフェースであり実装ではない。
実装はブラックボックスで良いと思う。
010095NGNG
>>99
じゃあ、あるデータ項目を追加したいって場合は
実装はいじらせないって事?
0101デフォルトの名無しさんNGNG
>>95
プロジェクトで役割を明確にしろよ。
みんながみんな実装のロジック見るわけじゃないだろ。
なんのためのインターフェースだと思ってる?
てか、Saesarをどうのこうの言う以前にOO開発できないでしょ。
そんな考え方じゃ。
0102デフォルトの名無しさんNGNG
ソフトウェア開発の基本が分かってない人↑
0103デフォルトの名無しさんNGNG
>>100
ちゃんと設計しろよw
0104デフォルトの名無しさんNGNG
設計は絶対に変えない。これがくーす。
0105デフォルトの名無しさんNGNG
>>102
基本を教えてください。
0106デフォルトの名無しさんNGNG
>>102
基本?
それってあんたのMY RULEのこと?
0107デフォルトの名無しさんNGNG
ここは貧血症君とレガシー君が互いに罵倒し合うスレですか。
そうですか。
0108デフォルトの名無しさんNGNG
>>107
そうですよ。
傍観者は書き込まないでください。
0109デフォルトの名無しさんNGNG
>>95
「interface開く 〜 interfaceのタイプ階層を見て実装クラスを開く」
って2段階になるのがうざいよね。

IDE側に、interface名にカーソルあわせて「実装クラスを開く」
みたいな機能が欲しくなる時がある。実装クラスが一つの場合は
そのまま実装クラスのソースを開き、複数ある場合はドロップダウンで
選択とか。
0110デフォルトの名無しさんNGNG
ここ読んでておもうのは、もしかして本当にモデルオブジェクト(ここで想定しているのは、
S2Daoが返す、テーブルに対応したBeanとか)にいっさい振る舞いを持たせなくて、
setterとgetter以外あってはいけないとか思ってる人が多いのか。

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

おれはモデルにほとんど機能は実装しないが、それでもそのモデルに直接関わる機能
(モデル内のインスタンス・フィールドだけで処理が片付いてしまうようなもの)はモデルに
実装するぞ。複数のモデルが絡んでくるようなものはサービスにまわす。貧血症ぎみの
クラスは多いが、それでも構造体よりはましだと思う。
0111デフォルトの名無しさんNGNG
>>110
前スレの後半で俺も似たようなこと言ったんだけど、
構造体として使うのがくーすらしいよ。

つーかドメインオブジェクトが何かって事をそもそも理解されてないようだから、
このスレの"ナイーブOO指向好き"と論点が噛み合わないんだよな。
複数業務にまたがるロジックがあるからこそドメインオブジェクトが存在してるんだろうに。
あれだけ、でかでかともっともらしいことを書くんなら、せめてもうちょっと
OOについての理解を深めてからにしてもらいたい>>比嘉氏
0112デフォルトの名無しさんNGNG
ここはHDataSetのサポートをしてくれるスレじゃないんですか。
そうですか。
0113デフォルトの名無しさんNGNG
>>111
ttp://d.hatena.ne.jp/higayasuo/20040801#1091337811
> OOPの良さは分かったけど、OOA,OODってよくわからんと思ってました。
> プログラミングのスタイルも我流で、適当にクラスを作っていただけです。
> 心がけていたのは、メソッド全体を一度に画面で確認できるくらい
> 小さいものにすることだけ。
0114デフォルトの名無しさんNGNG
人が育たないって主張に対するレスポンスがないな
0115デフォルトの名無しさんNGNG
>>109
ほれ
http://eclipsewiki.net/eclipse/?Implementors%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3
0116デフォルトの名無しさんNGNG
>>114
自分で勝手に育っていく奴以外はほっとけ。
そんなことに金かけてる時代じゃねーんだよ。

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

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

日本の高齢化社会の年齢構成みたいに高給の人間の比率が多い組織になると
収益率を上げていくのは大変だからね。
0117デフォルトの名無しさんNGNG
ドメインオブジェクトと永続オブジェクトを分ける話じゃないんですね。
0118デフォルトの名無しさんNGNG
サービス層はドメインオブジェクトじゃないのか?
データアクセス層を純粋にデータアクセスだけに特化させることはOKな感じもする。
つまりDBからデータを取ってくる以外のロジックは存在しないただのBeanって感じで。
0119デフォルトの名無しさんNGNG
結局、エンティティBeanのショボイ奴か。
0120デフォルトの名無しさんNGNG
くーすは名前を返上すべし。
熟成とは縁のないファストフード作りのマニュアルじゃん。
0121デフォルトの名無しさんNGNG
http://d.hatena.ne.jp/higayasuo/20041218#1103335335
> 問題は、ドメインオブジェクトに業務ロジックを追加するのが、
> ナイーブかどうかということです。
>
> 私の経験からするとドメインオブジェクトが複数の業務で
> 使われるということは良くある話です。
> 複数の業務の業務ロジックを1つのドメインオブジェクトに
> 持たせるということは、単一責任の原則に違反しています。
> クラスを変更する理由が複数あるためです。

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

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

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

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

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

よって、

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

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


# ちなみに「単一責任の原則」はアジャイルソフトウェア開発の奥義に
# 載ってます。いい本ですよ。
0122121=44NGNG
べつに、DomainDrivenDesignを否定しなくてもいいとおもうんだけどね>ひがさん

くーすのネーミングの理由を聞かれたakonが
> 車輪の再発明ではなく、昔の道具でも使い方しだいで対応できるという心をこめてのネーミングです。
って言ってることですし、手続き型上等、TransactionScriptマンセーと開き直ればいーじゃない。
0123デフォルトの名無しさんNGNG
それにしても、オブジェクト指向じゃないくーすに(21世紀の手続き型なんでしょ)ナイーブなオブジェクト指向とか、レガシーなオブジェクト指向とか言われたくない。
0124デフォルトの名無しさんNGNG
>>114
>人が育たないって主張に対するレスポンスがないな

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

人を成長させるってことなら、XPが一番だな。とくにペアプロが効果大。
■ このスレッドは過去ログ倉庫に格納されています