国産DIコンテナSeasarとくーす その3
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGってどうよ?みんなもう使ってるの?
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 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/
0034デフォルトの名無しさん
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技術的に語れる人間はこのスレには居ないって事だ。
それはそれで構わないと思う。そこは所詮2ちゃんだし?
重要なのは、このスレがヒガ氏へのQとして機能し得るか否かって事だ。
何が言いたいかって言うと
ヒガ様、手隙の時で構いませんので、その辺をBLOGの方で技術的に解説よろ
って事だw
006744
NGNG> 要するに、
> ヒガ氏の提唱しているのはビジネス的な視点での方法論で、
くーすの言う、DTOとかStatelessBusinessロジックはビジネスの話だと。
はあ、そうですか。
って、んなわけねーだろ。
0068デフォルトの名無しさん
NGNGいや、ひがさんの日記は、BeanMetaDataに振る舞いを「もたせるべきではない」という
話ではないだろ。BeanMetaDataはメタデータの管理(に直結した振る舞い)だけをすべき
だったのに、SQL自動生成とか関係ない振る舞いを持たせてしまった、という話だろ。
振る舞いとデータを分離するといってるんじゃなくて、「データにやまほど振る舞いをつけた
くなったとき、その振る舞いがデータと直結してるかどうかちょっと考えてみろ」っていって
るんだと思うけど。
まあ俺が思うのは、データに直結してないけど、そのデータを利用する機能を山ほど搭載
したFatなクラス設計(モデリング?)というは、「レガシー」なんではなくて、そんなものは
始めからオブジェクト指向の原則に反してるだろ、ということだな。
それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
かなり微妙だし、俺も正直言って間違うよ。
データと振る舞いをまとめるときに、「データと直結した振る舞いを持たせる」「データをつかった
ほげほげは別にする」というのはオブジェクト指向的には正しい判断じゃないか?
0069デフォルトの名無しさん
NGNGああ、それ自体は技術の話題だ。
でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。
0070デフォルトの名無しさん
NGNG> >>67
> ああ、それ自体は技術の話題だ。
> でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
> 技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。
もしそうっだったとしたら、なぜひがさんは
従来のオブジェクト指向を「レガシー」と言って技術的に批判するの?
0071デフォルトの名無しさん
NGNGここでレガシーと言われているものって、レガシーなんじゃなくて、そんなのはもともとオブジェクト指向的に
間違ってるんだし。
007251
NGNGいや、別にくーすに従わなきゃS2使ってバリバリにOOPなシステム作ることは
可能なわけよ。だからひが氏の実装自体には問題ない。むしろ素晴らしいと思うよ。
問題なのはくーすだよ。ただ、心配してるだけなんだけどね。
マジョリティとしての技術の方向性っちゅーのかな。それがこの先どうなっちゃうのか、とか、
くーすによってさらに加速されるであろう量産型低スキルエンジニア達の増産とか、
そいつらと一緒に、これからも仕事していかなきゃならない自分の身の振り方とかを。
ビジネス的にはそれでいいだろうけどさ、長期的に見て、まず「人」は育たないよな。
だから前々スレ686の一言に尽きるって結論になっちゃうんだけど。
ま、「レガシー」って言っちゃったのは失言でしたってこった。
どれだけ多くの人たちがあなたのBlogをチェックしてんのか忘れないでね。>>ひが氏
0073デフォルトの名無しさん
NGNGいけないんですか」とか聞く奴が毎年量産されていることを考えると、そいつらと一緒に仕事
していく手法を身につけとかないといけないってのは切実な問題かもしれん。
だって毎年量産されるんだし...
0074デフォルトの名無しさん
NGNGいろいろ覚えることあって大変だ。何がどういう役割を持っていてどう扱うのが正しいのか、
原作者にしか分からない理論(しかも、漏れ的には相当あやしい)を理解するのに何年かかるんだ。
そして覚えてそれで一体何になるのか。謎は深まる。
0075デフォルトの名無しさん
NGNG0076デフォルトの名無しさん
NGNG将来の客と現場に対する思考を停止するためのエクスキューズ用語。
0077デフォルトの名無しさん
NGNG0078デフォルトの名無しさん
NGNG示して難解フレームワーク固有の知識で壁を構築するっていうのは、
よく見かける手ではあるけどね。
シンプルな解決法は他にいくらでもあるのに。
本当にいいものは分かってもらおうという迫力が文章やコードで示されてる
のだけど、Seasarは・・・、まぁ、しょうがないな。
0079デフォルトの名無しさん
NGNGなんか凄い自信家ですねw
>>それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
>>かなり微妙だし、俺も正直言って間違うよ。
この辺に自惚れさが見え隠れしているように感じられるのは気のせいでしょうか?
0080デフォルトの名無しさん
NGNGそうだな。Strutsよりはマシかもしれん。
Strutsも大いなるネタの代表例でさ、あれよりいいってうのは、
果たして。大差は無いように思う。
0081デフォルトの名無しさん
NGNGくーすはWeb開発ノウハウの集合体であって、別に独自のフレームワークや固有の知識だと
思った事ないんだが。むしろ「あーたしかにそんな感じでやってるよ」ってくらいで。
逆にその「まとめよう」というところに価値があると思ってる。
0082デフォルトの名無しさん
NGNGみんな比嘉さんにもてあそばれてるなあ。
しかし、「レガシー」って括られるとそりゃ頭にきますよね。
みんな最先端を走ってるつもりなんですからねえ。
そう書けばここで盛り上がるのわかって書いてるのに
予想通りの盛り上がりを見せてるのはちょっと笑えるね。
しかし、Blogで2ちゃんのスレに煽りを入れて、
こんなにたくさんの人が踊らされるなんて、さすが比嘉さん。
0083デフォルトの名無しさん
NGNGDIスレの213=332と同様。厨がいたほうが一見盛り上がってるように見える罠。
0084デフォルトの名無しさん
NGNGそうか。やっぱり、ネタだったのか。
くそー、悔しい。
まぁ、そりゃそうか。
でも、本当にイカンのはマジなトーンで
DIコンテナORマッピングAOPとか言ってるやつらだぞ。
思わず反応してしまう・・・
0085デフォルトの名無しさん
NGNGもし本気でレガシーって思って書いてたら、S2自体の価値が疑われかねないので、
調子のって突っ走ってしまったと思いたいね。
まあ一方で、データと振る舞いの組み合わせ方は微妙な判断が必要な問題だ
と思う。その判断を卒業したてのPGに任せたくはないが、やらせないと低能の
ままの奴と付き合い続けなければいけないというジレンマに...
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ちゃんと設計しろよw
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データアクセス層を純粋にデータアクセスだけに特化させることはOKな感じもする。
つまり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???
もっと詳細キボン。
■ このスレッドは過去ログ倉庫に格納されています