名前重要
PIE原則などとの関連もある。
他のSLAPなどやKISSなどと密接にかかわっているものである。
また操作の名前だけでなく、エンティティ名やコンポーネント名
さらにはその粒度感まで把握しやすい名前が重要となる。
これのためには、チーム内または時にはチームの境界を飛び越えて他のチームと共同でモデリングを継続的に行うことでユビキタス名を発見するのをお勧めします。
ステークホルダーの命名
書籍では触れられていないが、ステークホルダーの命名も端的かつ潜在的な要求やその者(外部システムの場合もある)が欲しい情報などを類推しやすい命名を意識すると、変なところに操作やデータを割り当てるリスクを減らせる。
インターフェイス命名における名前設計
インターフェイスの設計は以前の記事で解説したように、
下位の具象でオーバーライドするすべての処理の事前事後条件を満たすという、
契約による設計を意識した帰納的な設計が求められる。
これは決して容易なことではなく、一度定義したインターフェイスに対して、
変更せざるを得ないような仕様変更が入ることだってある。
その際に意識しておいた方がいい点を以下に示す。
Fat Interface
さらにそのインターフェイスが太ってきて、
多目的なインターフェイスになってしまった際に
インターフェイス分離の原則が適用できるようなケースである。
ここですぐにインターフェイスを1つの目的となるように分割する決断をするのは早い。
そのインターフェイスに依存したクライアントプログラムが、どの程度の不利益を被るかを考慮していないからだ。
しかしかといって何もしないのは非常に見通しも悪い状態なままだ。
そこでもしも１つの単一目的となるように分割できなくても、
「このインターフェイスには複数の目的が混在しています」という意図の伝わりやすい名前であること、
および 「無理に単一目的にできない時には、命名で複数目的と理解できるようにする」
というコード規約によって、対象のインターフェイスがどの程度多目的か理解しやすい。
事例
たとえば、再生・早送り・巻き戻し・停止・一時停止するという
処理から構成されたDVDプレイヤーというインターフェイスがあるとする。
対して、再生・早送り・巻き戻し・停止・一時停止する 以外にも、
録画・ダブルで録画・予約録画・ダブルで予約録画する という9つの処理を持つ
DVDレコーダーというインターフェイスがあるとする。
補足
また多目的と分かりやすい名前にするだけでなく、「なぜ多目的なのにinterface分離の原則に従わないのか？」の理由をADRとして残しておくなどすると、さらにチーム全体の設計力向上にもつながりやすい。
ループバックチェック
これは超重要なテクニックであり、以下の記事でも触れている。
それだけでなく、以下のようなケースでも使用できる。
クラス名の命名
まずはクラス名だけを見て、属性リストを隠し、中にどんな属性があるのかを類推する。
今度は属性のリストを見て、クラス名を隠し、どんな名前が妥当なのかを考える。
属性が必要十分になっているかのチェックもおおよそ可能である。
パッケージ名の命名
上記の属性をクラス、クラス名をパッケージ名に対応させて同じことをする。
ドメインモデリングはある意味トップダウンでモジュールに命名をしている。
対して、
今回第三回目のまとめ
SLAPにしてると、インターフェイスを用いた変動からの保護、OCPを満たしやすくなる。そのためには名前設計(名前空間含む)も重要であり、粒度や意図まで容易にわかる命名である必要がある。その名前の洗練のためには極力シンプルさを意識し、ムダなもの関連の薄いものを混ぜない対策と工夫が必要。