この番組はエンジニアの成長は楽しい学びからをもっとにエンジニアリングに関する学びをワイワイお届けするラジオでございますはい今日はちょっとオブジェクト思考の話をしていこうかなと思っておりますお世話になってますはい今日話そうと思っているのですね値オブジェクト値オブジェクト値

アータイオブジェクト1エピソードになるのがすごい楽しみです僕は何の話をするんですか?え?何のソースかこれ?分かんないです、いやなりますなりますアータイオブジェクトちなみに使ってます?そんなに使ってないです、多分あ、ちょっと待ってくださいあんま書いてないから使ってないですね使ってないですか?使ってます、はい使ってる?はいじゃあちょっとまずアータイオブジェクト何なのよって話からしようかなって思うんですけどそうですねはい

値オブジェクトというのはですね書籍でいうと多分パターンオブエンタープライズアプリケーションアーキテクチャーっていうやつとあとはドメイン駆動設計とかで結構紹介されるケースが多いんですけど要はですね値をプリミティブじゃなくてオブジェクトで表現しようっていうやつですねつまりどういうことだってばよまずプリミティブとは何でしょうっていうところなんですけどじゅんぺくん何ですかうわーやべー

調べたいな調べたいなやば調べたいよく出しちゃったやばちょっとパスしていいですかOKプリミティフトはですねプログラミング言語が標準で用意している基本のデータ型のことですねやべえ文字列とか整数とか不動小数点とかそういうやつここで一個質問なんですけど例えばユーザーっていう

オブジェクトがありましたユーザーのオブジェクトは名前と年齢とあとなんか持ってますいろいろ年齢どんなデータ型で入れますかっていうイントじゃダメですか整数じゃダメですか怖いどんなって多分そういう回答じゃないですよねいや合ってるよもっと出せってことですかイントでいいのってマイナス20とか入れちゃうよ確かに

プラス側だけのやつの整数でいきたいときは何でいくんだろう何が使えますかそういうときは値オブジェクトですそうなんだ別にイントでやること多いと思うんですよ

ていうか別に間違いでもないと思うけどイントでやった場合って一つ問題があってですねじゃあそのユーザーのオブジェクトを作るってなった時に毎回毎回これプラスだよねプラスだよねってチェックして

OKだったら入れるみたいなことをしなきゃいけないんですよってなるとコードのいろんなところにそのチェックが入ってくるんですねそれって超めんどくさいよねってことでそれをなんとかして一箇所にまとめたいそんな時に使えるのが今回紹介する値オブジェクトという考え方でございますこれはさっき概要ザックと説明したんですけどそういうプリミティブのデータ型じゃなくてあえてそういうちっちゃいやつとかでもオブジェクトで表現しようねイエーイ

イエーイってやつですねさっきの例で言うとAGっていうクラスを作っちゃうんですねで中にプロパティとしてその値自体を保持するようにするとなるほどインスタンス化するときに

例えば0以下だったら0未満だったら例外投げますよっていう風なブロックを書いておくとそうすればエイジクラスだった時点で絶対0以上じゃんってことが保証できるんですねしかもそれってエイジクラスを全体で使っていれば0未満だよねっていうロジックってエイジのコンストラクターの中にしか存在しないから非常にドライ

非常にドライなんですよスーパードライ急速乾燥そっちアパレルブランドの方名前あっただけ超速乾燥だっけ急速乾燥だっけですよそんな感じがありますよね極度乾燥だ極度乾燥だってことができちゃうわけですよ

っていうのがまず値オブジェクトですよとはいまずこれ名前がすごいシンプルで値をオブジェクトとして使うよねってことなんですよじゃあ値ってどんな特性があるんでしょう値この値の特性を考えるとどこで適用すべきなのかっていうのが分かるようになるんですね値であるってどういうことですか値であるそういうの普通に値文字とかストリングとかも含めてます

そう、値ってそもそもなんですか?確かにデータですデータですか?どんなデータでも値ですか?可変であるとかなのかな?お!それはね、逆な気がするんですよね逆?不変2っていう値はもう概念で2なんですよ今日から2は3ですってなんないんですよ確かになんで、まず値の特徴その1イミュータブルであること

その1そうですね1回入れられたらそのインスタンスはそのままの値を持ち続けるというかそうそう交換するときも別に2が変形して1000になったとかじゃなくて2を捨てて新しく1000という値を入れてるんで元々あった2という概念自体は変わってないはずなんですよっていうのがまず普遍であるという特徴その1です

特徴その2交換可能であること交換可能であるさっき言ってた2を1000にするみたいな話そう交換可能であるってあんま言われてないんですけど僕はこれが一番考えやすいなと思ったんでそうしました一般的には同一性を気にしなくても良い概念であることっていうのがありますね例えば1000円あります僕の所持金1000円ですっていうデータがありますとはい

この1000円って特別な1000円ですかっていうそんなことはないそんなことはないですよね他の人も持ってる他の人も持ってますよねはい例えばじゃあこの1000円を別の1000円に入れ替えました何かが変わるでしょうかっていうこの1000円を別の1000円に入れました?1000円ユーザーが所持金っていうプロパティを持っててそこに1000円っていうデータが入ってましたそれを別の1000円に変えました一体何か変わりましたかっていう変わりません?うん所持金は1000円のままそう

これが交換可能であるということですねなるほど要はそこの1000円に対して特別な意味を持ってないというかなるほど一方ユーザーは値じゃないですAさんかBさんかはめっちゃ重要ですっていう意味で値であるっていうのはその2つが結構ポイントでなるほど普遍であるということでかつ交換可能であること要は同一性というか一位性がないことかなはいはいうん

こういうデータに対しては値オブジェクトを作るとロジックがクラスの中に閉じ込めやすくて非常にきれいなコードというかまとまったコードを書いていくことができますよというそういうテクニックなんですよなるほどどんなデータに使えるかなっていうのでピックアップしてみたんですけど例えば郵便番号郵便番号を例えば

前半部分と後半部分で保持しておいてで配分なしで取り出せたりとか配分付きで取り出したりとかあとはそもそも郵便番号って存在し得る値ありますよね一方うちの郵便番号特別なんだよねっていう一意性も特にないと同じエリアに住んでたらみんな同じ郵便番号になるけどそれって別に交換しても何も問題ないっていうことに使えますよとかあとはさっき出てきたお金

さっきついてきたっけ1000円お金はまずマイナスいかないですよね最近的な意味ではわかんないけど所持金的にはマイナスいかないはずまあそうね

マイナスいくシステム作るならマイナスいるんですけどそれはロジックによりますよビジネスの例えばアマゾンでこの商品はマイナス1200円です買ったら1200円あげますってことはないのでないですねそういう場合は絶対プラスですよねとかあとはお金作るなら一層のこと通貨単位とかもその中に含めていいんじゃないかなって気がしますね円とかドルとかユーロとかさすがに

監禁は別サービスにしたい気持ちだけどでも一方その監禁するサービスはお金マニークラスを受け取って返還する作業すればいいよねっていうのとか年齢とか誕生日とかねあとさっき言ってない名前とか名前も苗字があって名前がありますよねミドルネームある人もいるかもしれないしもしかしたらそのサービスは苗字は必須だけど名前は任意かもしれないし

もし名字と名前がどっちかだけ必須だった場合って多分いろんなロジックが挟まると思うんですよ表示の時にこの人は名前もあればフルネームで表示するとか名前なかったら名字だけで表示するとかメールとかウェブビューとか全部いろんなところにロジック散っちゃうのはちょっときついよねってことでそれを名前の値オブジェクトの中に突っ込めたりができるというわけですねここからですね

じゃあこれは値オブジェクトになるのかっていうのを話する前にちょっと一個説明するの忘れてたわ逆に一位性大事なやつはエンティティと呼ばれますほうDDDの文脈だと例えばさっき言ったユーザーとかうんユーザーの例えが出てればいいかまあそうですね投稿とかもそうじゃないかなポスト系のやつなんかちょっと違うかもしれないんですけどうん

ちょっと違うんですけどデータベースのテーブル単位ぐらいのやつってだいたいエンティティですかわかるそうかもしれないちょっと違うんですけどテーブル単位は割とエンティティになりがちだしカラム単位は割とバリオブジェクトになりがち値オブジェクトになりがちだけど値オブジェクトは別に必ずカラムってわけじゃないとは思いますね複数にまたがってる場合もあるし多分テーブルになってるケースもあるんじゃないかなって気がするわかる

そう考えるとカラムは絶対ないかもしれないエンティティになることカラム単体ではそうかもしれないそんな気がしますだってレコードで増えてっちゃうからユニークキーなら別かちょっと分かんなくなってきたけど多分ないんじゃないかなって気がするじゃあこれって

どっちみたいな値オブジェクトエンティティどっちクイズ楽しいクイズというか議論だなこれ正解ないと思うしアプリケーションによっては違うと思うはいはいテーマを発表します本本ブックなるほどブックちょっと考えててねむずいなって思ったんですよねなんかあのすごく今聞いて直感的にはエンティティっぽいなって思ったんですけどじゃないですかはい値

だとすると書籍名みたいな話いやでも本自体が値になるケースも全然あるかなと思ってて本って

一応ISBNで区切られてて識別番号ついてるじゃないですか一方その識別番号ついてる同じ本いっぱいあるじゃないですかそうなんですか知らないそうなんだ多分あれ本の種類ごとにつけられてるはずだからクリーンアーキテクチャー100冊用意したら全部ISBNの同じなはずってなるとクリーンアーキテクチャー1とクリーンアーキテクチャー2って交換可能なんじゃないかみたいな言ってる意味わかりますようん

だから書籍名だとバリューデってことですよね会社の人がブックって言ったらエンティティなんじゃないかって言ってる意味わかるけどノリさんで言ってるISBNがもし同一な場合交換可能かどうかここも議論ポイントあると思いますよだから思うにシステムによって違うんじゃないかなっていうのが一旦私が思った結論なんですけどAmazonとかで

ブックを扱う場合は値オブジェクト的に扱っても問題ないんじゃないかっていうアマゾンでブックを扱うなるほどね例えばクリーンアーキテクチャ買いましたみたいな届きましたこれ俺が欲しかったクリーンアーキテクチャじゃねえよってなんない

なるよなるかどういうこと全く同じ本全く同じ本で100冊すられてますとその

番号1を欲しいなという気持ちでAmazonポチったら番号50が届いて違うやんけとはならないってことですねならないそういうことかISBNも今やっと分かりましたあれですね本ごとにIDが振られてるんですねそうそうそう本の種類ごとに振られてるだからクリーンアーキテクチャー第1版第2版があったとして1とには違う番号が振られてるんですねのはず同じ第2版の中で何うん

印刷番号とかはついてないついてないと思うってことか勘違いしてましたってなったら値オブジェクト的に扱えるんじゃないかっていうそういうことですね一方よ

一方図書館はそうはいかないんじゃないかなと思ってて図書館は図書館で本をちゃんと管理しなきゃいけなくて誰に何を貸してるかって重要じゃないですか大事ってなったら図書館の貸し出しシステムでは値オブジェクトとして扱えなくてエンティティとして使うんじゃないかなっていうあーそういうことっすねそういうことっすねもうなんかなんて言うんだろうなそれは本という概念が変わってますもんなんか本という概念が変わっているシステムによってなるほどそうそうそうそうその

本の同じクリーンアーキテクチャという本をそれぞれ3冊だったとして同じものとみなすか違うものとみなすかはそれぞれ違うじゃないですか図書館とアマゾンでそれによってだから厳密に言うと同じような概念ではない

本っていうクリーンアーキテクチャーっていう括りで括るかクリーンアーキテクチャーのこれっていう括りで括ってるかが異なってる気がしますそうねだからシステムどれによってかどういうシステムで使うかによってここちょっと変わってくるんじゃないかなっていうのでこれを議論に出したかったという感じですねなるほどこれはもう答えです答えがあります図書館の本ですそれは

本じゃなくてそういうことサイン入りってなったらまた変わりません?イージーサイトでもサイン入りってなったとしてもただサイン入りが100個あったとしたらこのサイン入りじゃないってなんないですただ僕が持ってるサイン入りの本をのりさんが持ってるサイン入りじゃないクリーンアーキテクチャーって入れ替えられたら僕ブチ切れるじゃないですかそれは本じゃなくてカイチの本だからですなるほどね

所有してしまったってことか所有権がつくとその本はエンティティになるってこと?所有権がつくとそうですねエンティティになるでもその所有権も難しいですね別にアマゾンが持ってるんで最初は確かに

所有権ではないかもしれないこだわりがあるかでもAmazonは所有権じゃなくて在庫として持ってる気持ちだから在庫でも所有権じゃないですかね多分一回買ってるわけですから多分Amazon買ってないのかどうなんだろうなんか出版社のその辺のあれは分かんないわ本屋なんでややこしいっすね本屋はややこしいわ出版社に返すパターンもあるから売れなかったやつ返してるよねややこしいっすだから

在庫を抱えるとかなかったはず 返せるんだ返せるで返金してくださいってどうなんだろう 返金とかあんのかな金銭のやり取りタイミングわかんないけど買われた後に送ってる可能性ないお金100冊売れたんで100冊分で売り上げどうぞみたいななるほどね出版社の在庫が本屋さんみたいな発想そうそうそうそうなるほどそんなこと置いといてはい

その理論で言ったらありとあらゆることそうじゃないですかねありとあらゆることそうかなユーザーが与えになることあるんじゃないですか例えばじゃあのりさん家お手伝い家事手伝いスタッフ送りますって家事手伝い業者が送ってきた人が誰でも良くないですか気持ちは誰でもいいけど

多分管理してる会社側からどうでもよくないんじゃないですかなるほどその人がどれくらい働いたか結構重要じゃないですかどっち視点か言いません?ノリさん視点だったら誰でもいいんですけど会社視点だったらその人どっちだまあでもそっか確かにそうですね僕がもし評価できるならどうでもよくないですよまあそっかそれはそうかもな

なんかないかななんかありそうだけどユーザーはむずいぞユーザーはむずいんじゃないかそっか全く同じ能力を持つ人なんてあんまりいないもんな会社とかそうやって回ってそうだけど給料とか挟まっちゃうとややこしいなそうですね給料がない奴隷制度だったらじゃあどうでもいいかもしれない奴隷制度ならどうでもいいかもしれないそれならありえるかも

奴隷派遣サービスだってそうだね奴隷派遣サービスで怖い怖い炎上しない?炎上しないですか?しないよファンタジーだよ架空の話だからユーザーはむずそうだぞ確かに飲み物とかどうですか?本と同じですね多分同じかなでも賞味期限あるじゃないですかはいだから完全にどうでもよくはないと思うんですよね生産ロット的に大事というかなるほどロット単位で値なんじゃないかなみたいなロットの範囲で見たら

値として使えるんじゃないかなっていうまあそうっすね在庫管理どうなってんすかねさすがにロット単位かでも交換した時にそもそも賞味期限っていう値が変わるのであればそれは普遍じゃないなうんまあ確かにだから飲み物はエンティティだわ本も1スリ2スリとかあるじゃないですかありますね重販出体はいはいはいそれが関わってきた時はもう値じゃなくなるね完全になるほどねうん

それをシステムとして扱ってればだけどはいはいはい確かAmazonでこれ第2版か第1版かは関係あるけど第23ですとか書いてないもんな書いてないんじゃないですか変態ですよそうだよね相当な本好きのためのサイトだよねそうそうそう初版が良かったみたいなそういうのじゃないよなどう思いますかじゅんぺくいやー

そうですねまあ使いこなせたら使いこなす方法なんだろうなまあ適切に使えたらなんか助かりそうですよね閣僚減って閣僚はね増えるよ増えるんですか場合によるな例えばさっきのチェックしなきゃいけないロジックとかもマジでこの一箇所以外絶対増えませんとかだったら多分わざわざオブジェクト作るの大変だと思うファイル増えるしなるほど

今回というか値オブジェクトを使ってゴリゴリに開発することをあんまり経験なかったんです恥ずかしながら今やってるところではゴリゴリにやっててでまあ閣僚増えるんですけど仕様を思い出すのめっちゃ楽ですねなんかこれどうなってたかなって久しぶりにコード見に行った時にもしその値オブジェクトで使ってなかったら

これ使ってるリクエストのコントローラーどこだっけなバリデーションロジックこれかこうなってんだってなってたのがモデル見に行きゃ終わりみたいな確かにアプリケーションで年齢例えば18歳から60歳までしか使えないですよっていうサービスとかだったら値オブジェクト見ればそのロジックが書かれてるみたいな状態になるんでバリデーションファイル見なくていいっていうそうそうそうなんですよね

ちょっと適当こいてる可能性あるんですけどファストAPIってスワガのヤムル出してくれるんですけどそのスワガから値オブジェクトをちゃんと定義してるとリクエストに投げる何かとかモデルとかの制限制約事項を見れるようになってるから値オブジェクトでやるとちゃんとスワガにもそういうのが出てくるようになる

それこそあれですけどねリクエストレスポンスのモデル定義してその中のモデルにちゃんと値オブジェクトを使っていればですけどねだからすごいドキュメント見やすくなるってすげーなって思った記憶がある型定義とかしてそれをインポートして使ったりとかスワカでできるもんねそうそうそうまあちょっと手動で作るときそこまでやるかは人によるっすね普通にモデルでやるんじゃなくて

設計書のパラメーターの下に足せますからねって思いましたなるほどっていうアダイオブジェクトの話でしたありがとうございますこれを使うと書くファイルは増えてファイル数は増えるんですけどなんか思ったんですけどプログラミング特に始めたばかりの人ってファイル増えることとかを結構嫌わないですかはいそう思います一方さそれによってなんか

あるファイルがでかくなってるのをよく見かけるんですけどファイル増えろがマシじゃないですかどっちの気持ちもわかるどっちの気持ちもわかる僕は初心者の気持ち忘れてないんで多分ファイル往復するのがしんどいんですよね場所わかんなくなるというかエディターの機能を使えばね余裕でたどれるんですけどそんな

ことできないんで最初じゃあ一個に書いてたら分かりやすいよねって発想なんじゃないですかねなるほどね一応これもともとは駆け出しエンジニア向けの番組だったのでこれだけ言っておきたいなってのはあってファイル数増えることは恐れなくていいんじゃないかなって思うんですよねあんまりそうですね置き場所ちゃんとしてくれればファイルの構造化はちゃんと大事なんですけど変更

変更するときに大変なのって関係ないロジックがいっぱい混ざってるときだと思うんですよ一方ファイルたくさんあったとしても今回の処理に関係あるファイルって追うのそんな大変じゃなくてかつそれがちっちゃかったらすごい追いやすくないですかっていうのがあるんでぜひ新しいオブジェクトファイル増えるから嫌だなって思ってる人はファイル増えることは嫌じゃないよって思ってほしいうん

パワーでねパワーでそう思ってください確かにあったかもしれないエディターで開いたファイルのタブ消さない消したらこれどこあるか分かんなくなっちゃうから開いとこうってしてたことあったかもしれないすっとことっこいあったかもでもそういう時期Chromeのタブもそうだよねありがとうございます作る上でのメンタルブロックだけ外しておこうかなっていう最後の言葉いいと思います

じゃあ終わりますねでは最後お知らせでハッシュタグひまじんプログラマーでSNSでフィードバック募集してますので本日のエピソードの感想これ値それともエンティティクイズの取材ありましたらお願いしますなんならブックどう思うか欲しいですまあそうですね確かに答えを持ってる人がいるかもしれない一応ちゃんとGPTは論破できました

最初エンティティじゃないって言われたんですけどいやでもこういう観点で見たらあんまり関係なくないですかって言ったらいい観点ですねって言われたまあそうですね確かにそういうやりとり大事ですね本当にO1ですかO1って何GBTのモデルそういうの何も意識せずに使ってるからまあでも多分どっちでも言うと思いますよそうしてやなみたいなあとは

ポッドキャストの説明欄からGoogleフォームで番組のお手入れ要望感想質問何でもお待ちしてますお気軽にお願いしますお願いしますお願いします最後各種ポッドキャストプラットフォームでのフォロー高評価お待ちしてますのでこちらもまだやってない人ぜひお願いしますお待ちしておりますお願いしますはいではまた次回バイバイバイバイ初めて触ったMacBook

各種ポッドキャストで配信中