国産DIコンテナSeasarとくーす その３
■ このスレッドは過去ログ倉庫に格納されています
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/
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
必要になったらリファクタリングしましょう。
■ このスレッドは過去ログ倉庫に格納されています