【備忘録】コードを書くときに気をつけること（２）
前回に引き続き「良いコード／悪いコードで学ぶ設計入門」で学んだことを備忘録をとして書いていく。今回は短め。
名前設計（目的駆動名前設計）
良くない例
いい例が思いつかなかったので本に記載されているものをそのまま使わせてもらうと、「商品クラス」という非常に広い意味を持つクラスを使用すると必然的に低凝集・密結合になってしまうので良くないよねというもの。
（良いコード/悪いコードで学ぶ設計入門の図10.2を参考に作成。）
この画像では「予約」「支払い」「在庫」「発送」などの複数の役割が一つの商品クラスが担ってしまっている。
良くないところ
低凝集・密結合になってしまう
上記のような命名の仕方をすると、一つのクラスに複数の役割を詰め込むことが自然な実装になってしまい、必然的に低凝集・密結合になってしまう。
影響範囲が広い
これは低凝集・密結合のデメリットでもあるが、「商品クラス」が複数の役割を持ってしまっているために追加実装・変更の際に影響範囲が大きくなって意識しなくてはならないことが増えてしまう。
メンバーが機能を想像しづらい
他人のコードを見る際にはクラス・関数・変数の名前からどういった処理をするのかをなんとなく想像していくことが多い。その時に大雑把な名前をつけてしまうとコードを隅々まで見ないと機能すらわからないような状況になってしまう。
改善方法
こういった名前設計を改善するうえで「関心の分離」が重要になってくる。
クラスの設計・命名をする際には具体的な「もの・概念」毎に分割することが多い。上記の例の商品クラスなどもそのいい例だと思う。だが関心の分離とはその商品クラスを更に「予約」「支払い」「在庫」「発送」の関心毎に分離し、それぞれのクラスを高凝集・疎結合に保つことが出来る。
この関心を洗い出すのが難しい...本には関心事が最初から列挙されているから簡単に見えるけど、実際には関心を正しく認識すること自体がかなり何度が高い。
（重要）意識すること
- できるだけ具体的・意味範囲が狭い・特化した名前
- 存在ではなく、目的で考える
- 関心事の分析
- 声に出して読む
- 利用規約を読む
- 別の名前に置き換えられるか考える
- 高凝集・疎結合になっているか点検する
この中で具体的な行動として意識できるのは太字の3つだと考えている（上の三つは曖昧なため具体的な行動として意識しづらい）。
これらは具体的に意識しやすいのでクラス設計の所々でやってみようと思う。
声に出して読む
これは既にやっていることではある。実装する際に声に出して「今は○○をやっている。その目的は△△で、××の制約がある」などの独り言をいって自分の設計が間違ていないか、脱線していないかを確認する。
利用規約を読む
「利用規約を読む」というのは、何かしらのサービスの利用規約を読むということで、利用規約は何かに特化した名前が書かれていることが多いためそれを参考にするという意味だ。
別の名前に置き換えられるか考える
「別の名前に置き換えられる」ということはその名前がまだ曖昧性を含んでいることの証でもある。どこまで特化した名前にすればいいかはかなり悩むところで、いくらでも時間をかけてしまえる。そこで「置き換えられる名前が考え付かない」状況までは考えると決めると良さそう。
Discussion