texta.fm - 2. The Power of Constraints を聴いたぞ

podcasts.google.com

メモ（きになったところだけ）

  • composed_ofだとfreezeされる
  • immutableなオブジェクトのデメリットはメモリ消費が多いこと
    • これは処理系レベルで解決されるべき問題
  • コンテナ数をスケールアウトすることが容易になってきたので、1コンテナの中でのプロセス数を増やすことは（少なくとも一般的なwebアプリケーションでは）目指さなくてよいのでは
  • （契約による設計において）assertion errorとexceptionは異なる
    • assertion errorは、ありえないこと、以下のときに投げる
      • 仲間内の利用者が約束を守っていなかったとき
    • exceptionは、呼び出し側が約束を守っていたとしても発生するかもしれないこと
      • 外部（APIとか）の利用者が約束を守っていなかったとき
      • 利用者は約束を守っているけど問題が発生したとき
  • assertionはそんなにいっぱい書かなくていいんじゃないの、という話
    • お互いに全てを疑ってガード節を並べるのではなく、約束を設けて、呼び出し側のことを信頼する
    • コントローラで不適切な入力はちゃんと弾いて、適切な引数で呼んでくれているのだろうから、モデルではいちいちガード節は書かない、と。
    • そうすると全体最適になる
  • VOはコンストラクタでvalidationを書く
    • そもそもinvalidなオブジェクトは存在しえないようにする
    • これはinvalidなオブジェクトが存在しうるRailsのモデルとは大きく異なる
  • なぜRailsではinvalidなオブジェクトの存在を許しているのか
    • Railsでは、ユーザーからの入力をいったん受け入れるのをモデルでやっちゃうから
    • モデルより外側にvalidationをする場所があるなら、モデルはvalidなものしか存在しえない世界にできる
    • Railsはその雑さと引き換えにレイヤーの少なさ=単純性を実現している
    • モデルに書くことによって、外部/内部からの入力に対するvalidationを一箇所に書けるようになっている

おもったこと

VOはimmutableな方がいいよね、というだけで、mutableでもありうるよな

JavaのStringはimmutableらしいけど、Rubyは。

str1 = "foo"
str1.object_id  # => 180
str2 = "foo"
str2.object_id  # => 200

# VOである
str1 == str2  # => true

# mutableである
str1.concat("bar")  # => "foobar"
str1  # => "foobar"
str1.object_id  # => 180

しかしmutableにすることのメリットがいまいちわからん。 メモリ消費の抑制というのはそこまでの理由ではない気がする。 なぜmutableにしたのだろうか？