• おおむね内容は同意できたし、今後も本書の内容に考慮してコードを書いていきたいと思えた

  • 単一責任の原則、分かるようで分からないところがある
    • 管理(Manager)の意味が広いのは同意するし、自分なら避ける命名だとは思う
    • 一方で例えば「ヒットポイントに関する責務」が適切な粒度かと言われるとそこまで自明だとは思えない
    • 結局何を単一とするかは個人の解釈次第。管理を単一と思う人は一定数いるのかもしれない
    • ヒットポイントに関するロジックがあまりに増えて複雑化してきた際には改めて考え直す時が来るのかもしれない
    • 以上のことから「単一責務にしましょう」とは人に自信を持って言えなさそう。関心事が多すぎるので分けましょう、とは言うかもしれない。単一責務という言葉自体が実用的ではない気もする
  • 高凝集は誤解していたかもしれない
    • 「class名 メソッド名」を声に出した読む、あるいは文章にした時に違和感があるならばクラス分割すると良いかもしれない
  • ただし、どこまで本書の内容を生かせるかは採用しているプログラミング言語、フレームワークによって変わってくる
    • フレームワーク標準から逸脱するとそれはそれで別の苦しみがある
    • 特にそれを中途半端なまま終えたりすると…
  • 用語の定義やサンプルコードの質についてはネガティブな意見がある
    • https://zenn.dev/339/articles/e3c174fdcc083e
    • 全てに同意はしないが、同意する部分もある
    • もっとも内容に賛否があるのはこの本に限った話ではない
    • 可読性や設計に関しては主観が多分に入るため、いろいろな意見が出やすいと感じる