国産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/
0138デフォルトの名無しさん
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先ず書く、そして打つという手順を守りさえすればそんなはずはない
と上司は言うけれど・・・・・・・・
短期で動くモノを差し出せとせっつかれて、それどころじゃないのです。
アジャイルって本当に素晴らしいモノなのかな？なんか週間連載を
抱えた漫画家みたいって言うか、納期が短い間隔で何回もやってく
る感じで、昔よりも寧ろ過酷になってる様な気がするんですが・・・・・
■ このスレッドは過去ログ倉庫に格納されています