「良いコード／悪いコードで学ぶ設計入門」読書会第3回を開催しました

みんなで書いたホワイトボード

（あとでFIXしたものを貼ります…！）

「状態」を表すインスタンス変数は増やしたくないという話が出ました
- 有効/無効、公開/保留/非公開みたいなもの
- 複数作ってしまうと、組み合わせがスゴいことに…
- 普段、気をつけてます…！
正常とはどういう状態？という話が出ました
- なんとなくイメージはあるけど…うまくかけない><
- 意図しない例外が起きない、かなぁ…。
- 「状態」が複数あって、ある組み合わせが絶対存在しないのであれば、状態を操作するメソッドではそれが起きないようにちゃんとする、みたいな…。
抽象的、汎用的なクラスではバグなく作るのが難しいという話が出ました。
- interfaceとかabstractなクラスのことだそうで…確かに単体ではテストを書きづらそうです。
- Rubyだと…プログラム中で継承したりincludeしたりできるので、普通に書けるのがありがたい感じ…。テスト書いてます！
「利用者の視点」大事にしたいです。
- 急いで作ると…どうしてもクラスを使う人のことまで考えなくて…
- 結局、後から自分が使うときにスゴく苦労して涙する感じです…。

コンストラクタで初期化が難しいケースがあるという話が出ました。
- ファイルから読み込むとか、データベースに接続するとか、ちょっと時間がかかるようなものが必要な場合…
- これは自分もここではやらないですね…。
- 読み直していて…
  - ファイルを読み込んでいない/読み込んだ、接続した/してないという状態なのかも。
  - そういう状態であるときに、他の操作ができない作りにできれば…？
Moneyクラス、ここまで読んだところでは、amountの上書きをしたくない理由がピンと来てません…。
- 商品とか注文のようなクラスがあり、それらがMoneyという属性を持つことを想定してるのかな…。
- あとのほうの説明を期待…！

Moneyの背景がちょっと曖昧だったために、いろんなことを考えてしまって、みんなでモヤモヤしてました。
Valueオブジェクトなら、書いてあるとおり、うまくいきそうです。
- クラス一般としたら、例外が一杯ありそうでした。
- Userみたいなクラスで、名前を変更したら新しいオブジェクトになりました…！っていうのはアリなのかしら…。

完全コンストラクタとValueオブジェクトはちょっと意識して使っていこうと思います！
- 氏名とか、結構あちこちに整形用のコードが散らばってしまってて…うまく扱いたい気持ちになっていました。

ノウハウの多くは言語に依らなそう。
- あくまでも「多くは」
言語やフレームワークの方針がある場合はそちらを優先させたほうがよいのでは？という話が出ました。
- SpringMVCではModelやFormが処理を通じて書き換わっていくのが普通なんだそうで…。
  - ムリヤリ変えると、あちこち歪みそうです。

KPT方式で。

発言者が偏ってしまいました。
- 発言されてない方も学びを得られているかな？大丈夫かな？という感想がありました。
- 発言内容が「マサカリ」だと思われてないか心配している感想がありました。

Meetのリアクションを求めてみます。
- 言葉だとまとめるのが大変なのもわかるので、軽めのリアクションなら…？
心理的安全性のためのルールを入れてみます。
- 心理的安全性を脅かすような発言はなかったと思いますが、あえて明記することで、大丈夫な場であることを示せるかな…と。

参加してくれたみなさん、ありがとうございました！あとでざっと見直しても、一人で読むより圧倒的に気づくことが多いので、今後も継続してやっていきたいと思います！