国産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/
0103デフォルトの名無しさん
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
必要になったらリファクタリングしましょう。
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は反論になってないです。
ファウラーに、在庫推移は複式簿記で管理しないだろ、大丈夫かお前？
といってるようなもんじゃないでしょうか。
もうちょっとダメな理由を詳しくよろしく。
■ このスレッドは過去ログ倉庫に格納されています