読んだ上で印象に残ったこと、それを起点にして調べたことなどを書いていく
1章
シンボルと文字列を使い分ける
Rubyではシンボルを文字列を同等のように使えるシーンが多々ある。
例えば代表的なのはsend、find_methodなど。
シンボルというのは、記述されたらその識別子としてIDが保持される。
例えば以下なら、パースしたときに:addはIDを生成される。
```ruby
foo.send(:add, bar)
```
ところがaddが"add"であれば、パース時には生成されない。実行時に"add"にあたるIDがなければ動的に探索する。sendはシンボルを受け取るようにできてるので、この機構がないとエラーになるらしい。
自分が「シンボル」と「文字列」で最も最初に思い浮かんだのはenumの扱いだった。
enumはシンボルでセットしてもenumでセットしても、比較もシンボルで行える。
これも同じようにシンボル前提での設計がされているのかと思いきや、ActiveRecordから取得すると。文字列で取得されるのがずっと疑問ではあった。
では、シンボルで設計されている場合も、文字列のほうが都合が良いパターンというのがあるのだろうか。
配列、ハッシュ、セット（集合）を使い分ける
たぶん16ページのソースコードは誤植がある。flat_mapはいらないし、album_infosは生成されない（読んでる人には伝わるはず）
インメモリデータベースのメモリ使用量や速度をハッシュと配列を使いこなして解説するというテーマだったが、アルゴリズムを学んでから出直してきたほうがいい、あるいは学ぶ段階で読み直す必要もなくなるような気がしたので飛ばした。
SetとStructについても触れられていた。Structは使っていたがSetは全く使ってなかったので少し調べてみた。Structについては別記事を書いてみようかなと思う。
Setの特徴は、Setでは重複が弾かれる、要素の存在確認が高速の2つが主に挙げられる。
存在確認が高速な件については、内部構造がArrayと違ってどうなっているのか気になったので調べてみたら下記の記事が見つかった。
ここのSet.newしたときのソースコードが載っています。
今はSetはRubyの組み込みクラスになっているようなので、機会があれば使ってみようと思う。
2章
役に立つ独自クラスを定義する
いつ独自クラスを定義すべきか
毎回思うけど、こういう類の本は例示コードがシンプルすぎていまいち何が言いたいのかよくわからないことが多い。
この章では、独自クラスか組み込みクラスかよく考えて、みたいな話から「あると嬉しい独自クラスはなにか」という展開の仕方をしているが
実際に業務で独自クラスを使おうとした時や、すでに独自クラスになっているものを読んでいるとき、「これ独自クラスじゃなくて組み込みクラスでいいよね」というケースに出会ったことがない気がする。
実際は独自クラスの中身や組み合わせや責務をどうするかという話の方が重要なので、そういう意味でガチガチのコンテキストを持った独自クラスなどは確かにあっても嬉しくないかも、、みたいな議論ができるので、そういうことを言いたいんだと思っておきます。
SOLID原則とのトレードオフ
＜単一責任＞
必ずしも単一責任である必要はなく、過剰に分割すべきではないという話。
必要ならあとから分解すればいいし、分解すべきときは複雑性が増したときであり、複雑性は取り除くより追加するほうが簡単だからである。
思うに、これは単一責任という概念の捉え方によると思う。
クラスの責務を説明せよと言われたときに、どのくらい抽象的に良い表すかにもよるんじゃないだろうか。個人的には
「同じドメイン知識を持つチームにおいて、解釈の余地が生まれない抽象度で一言で言い表せるかどうか」
が1つの指標なのではないかと感じる。
小田急バスの注意事項に「運転に必要な機器に触れない」みたいなルールと言うか法令が書いてあるんですが、これが「解釈の余地が生まれない抽象度」の例かなと。
一般的な生活を送っている日本人ならわかるよね、ということ。
