「オブジェクトをイミュータブルにしろ」って言うけど、それってたとえば状態が変わったらオブジェクト作り直すってことでしょ、ちょう非効率じゃん。回にゃあと鳴くNekogata.rotation_per_minute(45)2013-06-15「オブジェクトをイミュータブルにしろ」って言うけど、それってたとえば状態が変わったらオブジェクト作り直すってことでしょ、ちょう非効率じゃん。言っていて(正確には、イミュータブルなリストに新しい値を追加した新しいリストを作るときには、中身をコピーする必要ない。変更されないことが保証されてるから、という話だった)目から鱗が落ちたのでここに記して置こうとおもった。終わろうと思ったんだけど、もう少しちゃんと書く。ミュータブルな世界では同一性の問題がある。変数が同じ数値オブジェクトを参照していたらまずい。同一のオブジェクトではないのに、同じものを参照していたらまずい、ということだ。別のオブジェクトはそれぞれの内部状態を別のメモリアドレスに保持しなければならない」というのがミュータブルな世界における常識、基本だと思う。しないとどこで変わっちゃうかわかんないからね。イミュータブルなら心配ないよ!そういうミュータブルな世界に慣れきってしまっていたわたしは「イミュータブルってことは状態が変わったらオブジェクト作り直すとか、毎回コピーが発生してちょう馬鹿じゃん」って思ってたんだけど、冒頭に書いたようにそうではない。playerA」が生まれる。作るためにわざわざ「別のメモリアドレスに旧の値を全部コピー」なんてしなくていい。別のメモリアドレスに作った新しい値を参照するようにすればよい。作りたい」ってときに「全部コピーして作り直す」必要がなくなる。これって、わかってしまいえば当たり前の話なんだけど、ミュータブルな世界の常識にとらわれているわたしが持っている「イミュータブルって言ってもさー、これどうすんのよ疑問」の、大きなもののうちのひとつが氷解して「エウレーカ!」ってなったので書いた。追記ほぼ3年前の記事が急に伸びてびっくりしています。さんのブコメを見て「あー追記したほうがいいかも」っておもう部分があったので追記します。「オブジェクトをイミュータブルにしろ」って言うけど、それってたとえば状態が変わったらオブジェクト作り直すってことでしょ、ちょう非効率じゃん。classにcopyというメソッドが生えていて、これは指定した引数の内容は書き換えてあとは同じ値を指す新しいオブジェクトを作るという、まさに上述のような動きをするメソッドです。それを利用することで、たとえば上記のような「ダメージ食らったらダメージ分だけhpの減った新しいオブジェクト作る」というのは以下のように書くことができます。ここまでは事実とか情報の類で、以下は私の意見です。depends.」な気もします。ライブラリなどがミュータブルなデータ構造が当たり前の世界で、すべての自作クラスをイミュータブルにする必要はないと私は考えます。一方で、複数のスレッドから触られることが多くミュータブルであることが怖い事故を引き起こしそうだなー、とか、そういう場合には、わざわざ自前でcopyメソッド的なものを実装してしまう、という選択肢も「アリ」なんじゃないかなと思います。かように、言語そのものや文化そのものがイミュータブルを推奨しているのではない場合、上記の内容は「イミュータブルにしたいときが出てきたら知っておくともしかしたら役に立つかもね」くらいの内容かなと思いますので、ミュータブルが当たりまえの世界でもすべてをイミュータブルにする必要はないんじゃないかなと私は思います。01:37「オブジェクトをイミュータブルにしろ」って言うけど、それってたとえば状態が変わったらオブジェクト作り直すってことでしょ、ちょう非効率じゃん。EP」をリリースしましたbuilderscon2019振り返り(not技術編)エンジニア・コミュニティにはオープンであってほしいリンクヘルプはてなブログお知らせはてなブログをはじめよう!nkgt_chkonkさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。