絵描きエンジニアの日常スマートフォン用の表示で見る絵描きエンジニアの日常この広告は、90日以上更新していないブログに表示しています。Fallのいくつかのセッションで型についての話があったので書きたくなった。この話はJavaやScalaみたいな静的型の世界の思想で、多分Rubyとかでは違う思想だとおもう。ことを最初に考えてる。防御的プログラミングってやつなのかな?しらんけど。エラーはより早いタイミングで見つかるほうが良くて、実行時よりコンパイル時にわかるほうが便利だし、コンパイル時よりエディタ上でリアルタイムに分かるほうがもっと良い。汎用的な型を使うとこんなミスがあり得る。Item(id);静的型なら多分こうかけるほうが間違えなくて嬉しい。strという変数が出てきたとき、これが何なのか、どんな操作が許されているのかがわからない。Stringという型には文字列以上の情報が含まれていなくて、splitしたりsubstringできたりする。仮にこれがDisplayNameという型であれば、splitやsubstringなんて操作はないし、表示用に整形するだとかDisplayNameとしての操作だけが提供されて間違えることはない。コンストラクタやfactoryメソッドで入力値をチェックすることで例えば空文字の場合はインスタンス化できないようにすると、DisplayNameの取りうる値の範囲が制限されてDisplayNameを扱うときに考えなければいけないことを減らすことができる。Railsにはcomposed_ofというあまり使われていないマイナーな機能があってそれを好んで使っている。これはDBのカラムの値を値にマッピングする機能で、JPAでいうEmbeddedと同じような機能。Rails界隈であまり使われていない機能でも好んで使うのは取りうる値の制限ができるという理由から来ている。PAYの薄い本」で書いてある。ちなみに表紙は僕が一番好きなイラストレーターのしらたま先生です。booth.pmFolioという証券会社のScalaの事例では、金額などの計算に型を使うことでうまく意図をもたせていた。JPY同士の掛け算は定義していない。そんな意味不明な計算はありえない。割り算とかもありえないのでコンパイルエラーこれはわかりやすい例なのでそんなことでミスしないだろうと思いがちだが、ドメイン知識が複雑になると力を発揮する。別の例で、損益と損益の引き算の例では以下のようなコードが示されていた。realized.value}計算結果の型によって計算の意図が読みやすくなるし、型が明確に分かれることで取り違いがなくなったり、気をつけたり意識することの脳内リソースを開放できる。クラスはどれだけ作れば良いか別の概念のものなら息をするように作る細かく分ける。名前考えるのは面倒だけど、作るのは一瞬。使うものだしどんどん作ろう。プリミティブは滅ぼそう。最初はやりすぎかな?って思うくらいやればいい。分けるのは大変だけど統合は簡単。