国産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/
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トランザクションスクリプトはいくらでも分割できるだろうけど、そのとき大きなドメインのモデルよりいいかどうかは疑問に思える。
杞憂なのかな？
■ このスレッドは過去ログ倉庫に格納されています