設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita

/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>

[n314]

オブジェクト指向ってこういうことじゃないの？あれ？これ普通じゃないんかな。ダメだと思ってる人は指摘記事書いてほしいなあ。

[devorgachem]

ブコメの評価低いけど、普通にこれは良い方法だと思う。特にIDとかは、ほかのIDが混入すると見つけるの大変だし、足し算引き算いらんしで同じ方法をとってるしうまくいってる

[a_suenami]

よかった（小並感

[fukken]

newした時点で「完全体」ではないインスタンスが存在するのがそもそも間違い。必須の要素は全部コンストラクタで要求するべき。「代入」が間違い。セッターにすれば解決。下手の考え休むに似たり。

[marshi]

コンストラクタがそもそもnewした時点で正常な状態にするための機能だからパターンというかコンストラクタ本来の使い方しましょうっていうやつ

[thetacpa]

不正なインスタンスの存在自体を許さない絶対正義。“下書き”をやりたいなら、“下書きクラス”の正しいインスタンスにすれば良い

[aipacommander]

よさそう

[kazuau]

消費税率は例がよくないよ。外国取引とか軽減税率とか経過措置とか継続役務とか、税率が決まる要素はたくさんあるので、こういうクラスで完結させるのは無理な例として挙げる方が適切なくらい

[otihateten3510]

やばい、全然良さが理解できない

[airj12]

個人的には好きな考え方だけど責務分割の難しい大規模システムで特定のValueObjectが開発のボトルネックになったりするので悩ましい

[msykt]

良い記事。1年に1回見返したい

[shunt_i]

課題が共感できるし解決法も良さそう、丁寧でわかりやすかった。ディレクトリ構成がどうなるかも欲しかったな。

[t1mvverr]

internalで外部から値を取れるように変えるのか、Valueという名のgetterを作って取れるようにするのか、似た目的に別々な手段を用意した意図が分からない。どっちかに統一したほうが良くね。

[guitgraph]

[プログラミング]

[efcl]

ValueObject

[wordi]

値の種類ごとに型(クラス)作るのは同意、消費税計算は日付や店内で食べるなどの外部要因が必要だから自分なら肥大化しうる計算関連を逃がすTaxCalculatorクラスとか作るかな

[password1234]

値のバリデーションはできるだけランタイムではなくコンパイルタイムでやって欲しい派

[tofu-kun]

凝集〜

[peketamin]

金額オブジェクトは難しいよね。税率が入ってくると「いつの」になるし、そうなると日時を持つ。税率は別オブジェクトになり、プロパティとして持つ？金融は関数型言語の方が向いてると聞いたが、どうやってるんだろ

[bambookun]

良記事。 https://engineer.crowdworks.jp/entry/2019/09/02/120253 こっちにも同じこと書いてある。こちらもおすすめ

[takahiro665]

途中まで。個人的には他人のクラス作成の過程を見れて得るものがあった。

[objectiveworker]

モデル系クラスで入出力が伴うメソッドは、SwiftでいうExtensionで分けないと逆に依存関係が複雑になるのよ。

[gabari]

個人的にはすごいわかるんだが、いかんせんこのレベルでも分かってないヤツが多すぎて辛い。たまにBuilderクラスとか使うと、これも理解されないのが辛い

[yuno001]

昔プログラムかじったレベルだけど大体言いたいことわかるし、むしろこんなレベルの話をわかってない人がITやってるの？(煽り)

[odakaho]

ロジックの途中でsetしたり破壊的メソッドの引数にしたりでも平気な顔してる人って結構いるので、言ってることはわかるけど、共通処理として切り出したほうがよりいいと思う。税率計算なんていろんなとこでやるし。

[yamadadadada2]

できるだけこういうことをやらずに、規約を守らせることでスピードを出そうとしたのがRailsなのかな

[gmkzmrn]

いまだsetterの存在価値がわからない

[Dragoonriders]

お題が適切じゃない気がする。特に　"契約日が決まってしまえば、あとは消費税施行日と照らし合わせて消費税率が決まる仕組み"　まあ、本気にして業務でこれやったら爆さつされますよ。あくまで例だからいいけど。

[chimerast]

型でガチガチに可視化するのって重要だよね。あと、契約プログラミング。この辺、概念だけ勉強しても、実際の現場で実例に触れないとまあ身につかない。

[ntaoo]

"オブジェクト指向で設計"が、最近はDDDで設計にリブランディングされつつあるのかな

[cpw]

いつか参照するかも

[snicmakino]

良記事。生焼けオブジェクト作ろうとする人が結構多いから、こういう説明は参考になるなあ。

[daibutsuda]

うむ？セッターで不正値を弾くのがなんでだめなのかがわからない…。

[gabill]

お題:軽減税率の行に※を表示する改造

[D_first]

シグネチャが正直になるように関数型プログラミングを取り入れればもっと良くなるな

[Futaro99]

最近スカラー型扱うとウッてなるようになってきた

[Helfard]

オブジェクト指向だよね？