長いので章ごとにしてます。
4 不変の活用 ―安定動作を構築する―
- 不変が標準的な流れ
- Rustはデフォルトが不変でしたっけ。
4.1 再代入
- サンプルをみてると…たしかにコメントがないとわかりにくいですね…。
- それぞれに意味のある名前をつけてあげれば、コメントなしにできそう。
4.1.1 不変にして再代入を防ぐ
- ちゃんと目的別にしてるなら不変にしなくても…？
- でもきっと誘惑があるんですよね…。
4.1.2 引数も不変にする
- 引数を変えたくなるってどんな場面…？
4.2 可変がもたらす意図せぬ影響
4.2.1 ケース1 可変インスタンスの使い回し
- あ…うーん…これはやっちゃうかも……。毎回
new AtackPower(20)とか面倒で書かないかもしれません…。- そもそもこれなら、Intを引数にして、中で生成しても…という気持ちにもなります…。
4.2.2 ケース2 関数による可変インスタンスの操作
- あ…うーん…起きそう…。
- 魔法を武器にかけるんでしょうが、その武器をちゃんと所有者ごとに作ってあげないと、こういうことが起きそう。
- 同じ銅の剣が世界中で持たれてたらって思うと面白すぎる。
- エターナル・チャンピオンを思い出してしまいましたw
- 同じ銅の剣が世界中で持たれてたらって思うと面白すぎる。
- 魔法を武器にかけるんでしょうが、その武器をちゃんと所有者ごとに作ってあげないと、こういうことが起きそう。
4.2.3 副作用のデメリット
- ですねぇ。
4.2.4 関数の影響範囲を限定する
- ですねぇ。
4.2.5 普遍にして予期せぬ動作を防ぐ
- これまでの例を見ていると、確かに予期しない不具合を作り込んでしまいそうな気になってきました。
- マルチスレッドで、スレッド共有のインスタンスがあるなら、これくらいガードしてても損はなさそうです。
4.3 不変と可変の取り扱い方針
4.3.1 デフォルトは不変に
- 基本は不変にして、ミスをしにくくする。書き方が面倒だけど…！
- ミノ駆動さん、技術的負債の解消で転職してる…。これらの手段が有効であることを示してるのか…。
- 変な誘惑に負けさせない圧力を感じる…。
- あ…コンパイルするとコケるのか！
4.3.2 どんなとき可変にしてよいか
- デフォルト不変、可変がOKな場を定義してます…なるほど、こっちのほうが確かにパターンが限定されるかもしれません。
4.3.3 正しく状態変更するメソッドを設計する
- HitPointにいろいろと条件を加えてきて、クラスに起こした理由が見えてきました…。
- あれ…この間不変にしてたような…？
- 2.4でした。
- このコードはなるほどって思えました。
- あれ…この間不変にしてたような…？
4.3.4 コード外のやりとりは局所化する
- ですねぇ。
