🕌
良いコード、悪いコードで学ぶ設計入門 10章 まとめ
10章 名前設計 あるべき構造を見破る名前
-
アンチパターン
- ex: ECサイトの商品を命名する際にそのまま「商品クラスと設計してしまうこと」
-
10.1.1 関心の分離
- 商品クラスにすると予約、注文、発送など様々な関心事と結び付きそのロジックを持ってしまう。つまり密結合になる。
- 疎結合高凝集にするには関心の分離が大事。
- 関心の分離とは「関心事、つまりユースケースや目的、役割ごとに分離する」
- 商品クラスは関心事それぞれのクラスへの分割が必要
- 関心事それぞれでクラスを疎結合高凝集にしておけば、たとえば注文に関しての仕様変更が生じた場合、注文関連のクラスだけに注意を払えばよくなる。影響範囲が低減し、開発生産性が向上する。
- 「商品」のような大雑把な名前は様々な目的に使われやすいいい加減な名前である。
- こうした目的不明なクラスを目的不明オブジェクトと筆者は読んでいる。
- このような事態に陥らないよう、関心分離をお式した名前を設計する必要がある。関心の分離には、ビジネス目的を名前として表現することがポイントになる。
-
10.2.7
-
目的に特化した名前を選ぶと、目的以外のロジックを寄せ付けにくくする。
-
目的だけのロジックが集まりやすくなり、高凝集になる。
-
10.5.2
- Managerはクラスの巨大化複雑化を誘発する。
- ex: MemberManager
- なぜ複雑化する?Managerが意味する「管理」の意味が広すぎて曖昧だから。
- Managerは具体的に何をするもの?ヒットポイントの制御?それともアニメーション制御?管理と名づけるとなんでもできそうに感じる。
- メンバーの仕様が変更されたら、とりあえずMemberManagerあたりにロジックをついかすればいいやと感じてしまう。=> カオスになる。
- Managerを分解するとヒットポイント、魔法力、アニメーション、CSVなど
- Managerに近い名前として、ProcessorやControllerなどが挙げられる。
- Controllerは受け取ったリクエストパラメータを他のクラスへ渡す責務にとどめるべき、金額計算や予約可否を判断したりなどの分岐ロジックが実装されていれば単一責任原則違反
-
10.5.3
- 状況によって意味や扱いが異なる名前
-
10.5.4
- 連番命名はダメ
-
10.6 名前的に居場所が不自然なメソッド
- 10.6.1
- 敵クラスにアイテムを入手するメソッドを入れるのは不自然。
- 仮に宝箱からアイテムを取得する場合に重複コードが生じる。
- この例に限らず、関心ごとに無関係なメソッドが追加されることがよくある。
- そしてその場合はaddItemToPartyのような** 「動詞+目的語」**の型式になる。
- 10.6.2 可能な限り動詞1語で済む名前にする。
- 関心ごとの異なるメソッドの混在を防ぐには、可能な限り動詞1語で住むような名前設計するのがコツです。
- addItemToPartyであれば、「パーティの所持品」の概念をクラス化
- そうするとメソッドはaddのみでいい。ファーストコレクションパターンになる。
- removeメソッドを追加してもいいかも
- 10.6.1
-
10.6.3 不適切な居場所のbooleanメソッド
-
「クラス名 is 状態」にして、自然な英語で読めるとそのメソッドは正しい責務であるといえる。
Discussion