書籍Amazonリンク
本の概要
オブジェクト指向を基本とした設計思想についてTwitterやQiita、テックコンなどで発信を行っているミノ駆動さんの設計本。
本の感想
読みながら、各章ごとに軽く感想を書いていきます。
1章 悪しき構造の弊害を知覚する
設計が下手だとこういう問題があるよという軽い話。 具体例は第1章ということもあってかなり低レベルなものを選んでいると思う。が、集団で開発していると（継ぎ足しの継ぎ足しなどで）マジで見るので辛い。
2章 設計の初歩
変数を使いまわすな、意味のあるまとまりを作って名前を適切に付けろ、という内容。
個人的には、色々設計を学んで最終的に戻ってくる真理もこういう話（命名、モジュールの責務の明確化）だと思ってる。
3章 クラス設計 -すべてに繋がる設計の基盤-
そのクラスの役割ならそのクラスに書け、という話。具体例として値オブジェクトが挙がっているのでクラスの役割として不変性や不正値の検出に言及。
4章 不変の活用 -安定動作を構築する-
値オブジェクトの説明と言える。ゲーム的には新しいクラスインスタンスは作りたくないので、C#的に言えばここは構造体に読み替えるかなと思う。
値オブジェクトだからインスタンスの同一性には無頓着で良いが、値オブジェクトはそういうものだ、という説明をせずにこの話を持ってくるのはやや怖い気はする。（知らない間に別インスタンスに変わっているのは基本的に弊害であるはずだ。）
ただ、不変をデフォにしたいという気持ちは同意する。僕もprivate readonlyと書くとメンタルが回復する。
5章 低凝集 -バラバラになったものたち-
意味単位でクラス化して、そのクラスの役割であるメソッドはそのクラスに定義しろという話。
4章までと違って、普遍的に言えることであり、そのため具体的にこういうケースはこうすればいいという理解が初心者には難しい、かなり難易度が高い章ではないかと思う。
が、その分重要度はかなり高い。
6章 条件分岐 -迷宮化した分岐処理を解きほぐす技法-
interfaceによるポリモーフィズムを使えという話。完全に同意する。使用者側でキャストしてたら意味ねーぞというツッコミも良い。（マーカーインターフェースを使い、使用者側でasキャストしているプロジェクトを2回見たことがある。interfaceを使う意味が全く無い。）
7章 コレクション -ネストを解消する構造化技法-
Linqを使えという話と、コレクションを自作クラスで包んで不要な処理を隠蔽しろという話。どちらもその通りだが（値オブジェクトのとき同様、ゲーム的には頻繁なクラスインスタンス生成は避けたいが）関連性が薄いので章を分けても良いのでは。後者はコレクションは一例であってもう少し広く言える話だと思った。
8章 密結合 -絡まって解きほぐせない構造-
ミノ駆動さんの発信を見ていればすごく既視感がある章。単一責任原則の理解と、DRY原則の誤解、継承より委譲、疎結合など、最重要要素がてんこもり。恐らく実体験無しにここを理解するのは難しいが、ここを理解できて実践できているかはすごく重要だと思う。単一責任原則を守っていれば長くても200行、だいたい100行くらいのクラスに収まる、というのは普段Unityで開発している僕の感覚にも一致している。
9章 設計の健全性をそこなうさまざまな悪魔たち
変更容易性を高く保つための細かいテクニック。悪例として挙がっている「技術駆動パッケージング」は自分も反対なのだが、なぜかゲームエンジンの仕様事例ではよくみる（Scenesフォルダ、BluePrintsフォルダ、Scriptsフォルダなど）。フォルダ名で何のためのアセット群か判断するものがあるのでそれは仕方ないと思うが、その必要が無い部分もその分け方で本当に分かりやすいか考えてみてほしいと常々思う。
10章 名前設計 -あるべき構造を見破る名前-
超重要。僕も、命名は最も重要だと思っており、完全に同意する。仕様変更によって言葉の意味が変わりうる、という点は見逃していたので今後注意したい。
11章 コメント -保守と変更の正確性を高める書き方-
Whyを書け、という話や、コメントを過信するなという話。個人的には、悪例「コメントで命名をごまかす」が面白かった（ありすぎる）。
ちなみに自分は結構コメントは書く方だと思う。Whyのコメントだったり、例えばMVPのPresenterの初期化メソッド内で細分化してメソッドに分ける意味無いけどメソッドがちょっと長いし、お互いに関係無い処理は見た目分かれてるっぽくしたいなぁと思ったら、改行とコメントを入れることがある。コンパイラが0コストでインライン化してくれるなら普通にメソッドにわけるのだが。
12章 メソッド（関数） -良きクラスには良きメソッドあり-
コマンド・クエリ分離は名前を知らなかったが、最近同じことを考えていた。利便性のためにモディファイアを実装することもあるが、その場合名前は〇〇And△△みたいな、コマンドしてクエリするというのがわかる名前にするだろうとか考えていた。
null引数やフラグ引数をやめろ、というのも真っ当な主張。
13章 モデリング -クラス設計の土台-
単一責任原則の解釈として、クラスは1つだけ目的を持つようにしろ、という話。僕も単一責任原則は設計において最重要な概念だと考えるが、その解釈はかなり曖昧な表現が多いと思っている。僕はよく「何のためのクラスか一言で明確に説明できる」ようにと言うが、これも結局、聞き手が未熟であれば「目的」の範囲が不適切に広くなってしまう可能性を避けられない。正直ここは有識者の下で指導を受けたり実践で学ばないと身に付けるのは難しいのではないかと思っている。
14章 リファクタリング -既存コードを成長に導く技-
テストコード、IDEの機能を使用して実際にリファクタを行う手順。
実際クソコードのリファクタは精神的にかなり辛いことが多いので、使えるものは使ってそのとき考える必要があることを減らし、精神を守る手段は非常に大切だと思う。
15章 設計の意義と設計への向き合い方
凝集度、結合度の計算方法（ツール）の紹介や、現実的に設計、というかリファクタするにあたっての注意点など。ところで個人的には循環的複雑度よりは認知的複雑度の方が好き。（認知的複雑度は5以下に収めたいと思っている）
16章 設計を妨げる開発プロセスとの戦い
コミュニケーションを取れ、という話とその具体例。まさに自分がチームの設計レベルを上げなければならない状況なので、この辺りの経験者の考えは参考になった。この本は大部分は設計初心者向けという感じだが、ここだけは中級者以上向け。
17章 設計技術の理解の深め方
主に書籍の紹介。何が良くないかと探す意識を持って読むと良い、初歩の初歩を抜けた人や中級者以上向けの書籍が多数紹介されています。特定の言語に特化した書籍は省かれているので、ここから評判の良いものを何冊か選び、さらに自分のよく使う言語に特化したものを合わせて読むのが良いと思った。
C#であればAdaptive Codeが自分の読んだことのある中ではおススメ。
全体を通して感想
自分は設計に関しては中級者以上だとは思いますが、今の知識が間違っていないかの確認や、未だにチームメンバーの初心者にうまく説明することができていないため、その手助けにならないかという目的で読みました。その目的は概ね達成できたのではないかと思っています。
ミノ駆動さんが普段からRPGツクールで設計指南の動画を作ったりとフランクなタイプの方ということもあり、堅苦しくなく、サッと読めます。
入門書なので理論や様々なデザインパターンを学ぶことはできませんが、入門書としては取っつきやすさからおススメできると感じました。
