Value Objectについて整理しよう - Software Transactional Memo
2022/05/15 09:08
tune
これ/問題の複雑さに合わせて膨れ上がるコードの複雑さをうまく統治するためにプラクティスを適宜使っていこうという順序で考えるべきであって、プラクティスの導入自体がコードに複雑さを加えるのであれば本末転倒
2022/05/15 09:14
t2y-1979
oop の一部の技法をことさらに強調する人たちがいる
2022/05/15 09:40
ledsun
“immutableは共有と複製の違いをぼかしたまま使うための工夫に過ぎなくて、常に複製しても良いとマーチン・ファウラーも言っている”
2022/05/15 10:10
sgo2
「オブジェクト指向」もそうだけど、機能を連想し易い命名をすべき、という大原則から外れてるから混乱を生んでる感。
2022/05/15 10:17
nunulk
"プリミティブ型をわざわざクラスで包んで別名参照問題の懸念を引き起こし、更にそれをimmutableデザインによって解決する、という手順は自分で掘った穴を埋める労働のよう"
2022/05/15 10:18
strawberryhunter
なんでもクラスにしてしまうのはValue Object Obsessionというのか。これを真剣に導入しようという頭のおかしい輩が実在したことはここに記しておこうと思う。
2022/05/15 10:51
peketamin
原理主義的に必要性を超えて「なんかそれっぽいこと」をやってるとイミフなものになりがち。
2022/05/15 12:06
turanukimaru
あー「すべてのプリミティブ型と文字列型をラップする」連中のことね。私もあれはやりすぎで各オブジェクトに独自の振る舞いが見つかるまではプリミティブ型でいいと思うしValueObjectと呼ぶ必要がないものも多いなって
2022/05/15 12:24
craftone
「顧客郵便番号」は無いけど「郵便番号」は Value Object にしたい。この記事では「郵便番号」も string で良い言ってたりする？
2022/05/15 13:10
yo_waka
"Value Object Obsession"
2022/05/15 13:10
aceraceae
この話の主題ではないけどルールへの過信みたいなのはあってインデント減らしたりひとつのメソッドを小さくするためにたらい回しみたいなコード書いてかえって可読性減らす人はわりといるよね。
2022/05/15 13:32
yojik
10年以上前のデブサミでOOPエクササイズを紹介した人間けど、当時はあくまでエクササイズですよというのを強調した。プリミティブを全部ラップするとかアクセサ全部禁止とかはベストキッドの窓拭きみたいなもん。
2022/05/15 13:45
dustytrombone
タグ付き型か櫛型でおけ
2022/05/15 13:49
roirrawedoc
丁寧で分かりやすい 冗長なくらいだ
2022/05/15 13:56
mimosafa
複雑になることをどのレイヤーで忌避するかの問題じゃないかと思うけどね。 / “「Valueのように振る舞うObject」がValue Objectであって「Valueそのもの」の名称はValueで充分である。” これは同感。
2022/05/15 13:58
yuyarin
この議論の中でstd::stringのCoW的な実装がC++11では仕様として禁止されてることを id:kumagi に教えてもらった
2022/05/15 14:00
masatotoro
value objectに関する深い洞察
2022/05/15 14:42
yarumato
“JavaScriptで = の意味が、プリミティブ型（int等）なら複製、オブジェクトなら（ポインタ）共有、という挙動の違いはややこしい。プリミティブ型の取り回しに揃えたい。Valueのように振る舞うObjectなのでValue Objectと呼ぶ”
2022/05/15 15:20
masudatarou
複製が必要ならば明示的にクローンせよ、はそうなんだけど =が参照渡しの言語だと オブジェクトのディープコピーするのが大変なんだよなぁといつも思う
2022/05/15 15:35
xxxxxeeeee
kumagiの言うとおりC++書いてる限り「なにそれ当たり前やん」ってなる話。Goも割とそう、Rustもそう。でも数年だけJava仕事で書いてるときは確かにこの辺めんどくさかった。
2022/05/15 16:45
mak_in
C#のrecord型が、これになってるな。ORMであるentity frameworkが、DBの追跡のためにentity クラスをrecordにするな、と書いてるんだけど、利用側にとってはrecordで使いたい場面もしばしば。そこら辺のノウハウが地味に知りたい。
2022/05/15 16:50
ch1248
同意。俺も一時期「全てをオブジェクトにした方がいいのか？」みたいな状態にはなってたが、YAGNI原則適用でいいよねと思う。
2022/05/15 17:20
nomber3
プリミティブ型の単純なラップ、欲しかったものは静的型チェックしてくれるtype aliasだったのでは感がある
2022/05/15 18:46
tengo1985
冷静に考えたらそのとおりだろ、と結論だと思うけれど極端な考えになってることあるよな。
2022/05/15 19:13
devrabi
なんにでもVOを自動生成で作りたがる人達はいる。そういうものに価値があるとは思えないが。
2022/05/15 20:15
PrivateIntMain
VOにできるのって複数の値が組み合わさった番号ぐらいなもんでは。バリデーション楽したいからとかシステム都合で生まれるもんじゃない。
2022/05/15 20:18
raydive
これはこれで過激なこと言いたいだけのように見えてなんだかなぁとは思う。/全部が全部オブジェクトに包む必要はないのは確かだけど
2022/05/15 21:26
cuttoff19
後半良かった
2022/05/15 21:54
tor4kichi
「VOはこうだ」とまでは言えるけど、じゃあそれ以外は？ 「VO以外の全てのコードはドメインオブジェクトだ」と言って差し支えないのであれば、VOと同時にそれ以外を説明することで混乱を減らせないだろうか
2022/05/15 22:57
rikuba
“Value ObjectはValueのように振る舞うObjectであって、ValueにObjectのような振る舞いを足す事ではない。”
2022/05/15 23:20
hasiduki
ほーん！！！！
2022/05/15 23:55
tkmkg8m
“問題の複雑さに合わせて膨れ上がるコードの複雑さをうまく統治するためにプラクティスを適宜使っていこうという順序で考えるべきであって、プラクティスの導入自体がコードに複雑さを加えるのであれば本末転倒”
2022/05/16 01:59
moriyoshi
こういうことを言うとすごい怒られそうだけど、議論を見ていると、Martin Fowler氏とかは絶妙に説明を変えて批判を避けてきているところもあるんじゃないかなとも思えて、逆にそれが氏の誠実さなのかもしれないけども…
2022/05/16 08:20
n314
ブコメ見て、確かに type alias がないから仕方なくやってるところがあるかも。
2022/05/16 11:38
mominis
null参照といいオブジェクト指向言語はことごとくポインタの抽象化に失敗しているな
2022/05/16 13:05
zyzy
Scalaだとこの辺はvalue classかcase classかみたいな話
2022/05/16 17:54
koba789
“問題の複雑さに合わせて膨れ上がるコードの複雑さをうまく統治するためにプラクティスを適宜使っていこうという順序で考えるべきであって、プラクティスの導入自体がコードに複雑さを加えるのであれば本末転倒”
2022/05/18 19:16
iwasiman
定義を見つめ直す話。"Value ObjectはValueのように振る舞うObjectであって、ValueにObjectのような振る舞いを足す事ではない。"
2022/05/18 23:27
efcl
Value Objectは値による比較が行われるオブジェクトという話。値を表現するものと、型のAlias的なものについて