設計 – クラスの命名のアンチパターン by @tnacigam on @Qiita http://t.co/cUZU6RbOAh — ん? Manager とか Property とか一般名詞を使わずにドメインに特化した名称でUMLを組み立てた後にパターン化するのが王道。
— Tomoaki Masuda (@moonmile) 2014, 9月 5
気になったので、ラショナルプロセス風なUMLスタンダードパターンを紹介しておきます。
- ユースケース等で対象のオブジェクトを抽出する。
- オブジェクトを辞書化する。
- 辞書を整理して、オブジェクト図を作成する。
- オブジェクト図を抽象化して、クラス図を作成する。
- クラス図を作成した後に、GoF などのパターンがあれば、それに準じる。
統一プロセス自体には 5 番目のパターン適用はありません（GoF の前のため）。このため、GoF などのパターン（特に Java のエンタープライズパターンなど）が既にある状態での、現在では Manager などの「パターン特有の単語」が頻出していますが、もともとはパターン適用時の単語なので変更しては駄目なんですよ。
最初にユースケースからオブジェクトを抽出するプロセスでは、具象的な名前を使います。これは、オブジェクト図（具象図）とクラス図（抽象図）を明確に区別するためでもあり、いきなりモデル化してしまうことにより、間違った抽象化を避けるためです。今でいえば、ドメイン駆動などがあるので、業務ドメインに特化した言語/単語を使いつつ、クラス図にて抽象化（一般化した名前）に落ち着けるか、ドメインに特化した名前をそのまま使うか、の判断を行います。このプロセスは、2 の辞書化の部分にもあてはまります。
そんな訳で、「今」しか学ばないと名称に混乱するでしょうが、「歴史」的なGoF 等のパターンにでてくる名称と統一プロセスを知っておくと、特に悩むことはありません。抽象化と具象化の部分が区別されますからね。なんか、ちょっと Twitter でのコメントが気になったので、書いておきます。
～～
余談ですが、名称をつけるときのテクニックは「明確」にあります。昔よりも IDE のインテリセンス/補完機能が働いているので、統一的な名称を単語の前に出すことで、うまくマッチせることができます。たとえば、本に関係するメソッドは、
- ListBook
- SortByBookID
- GetBookTitle
とするよりも
- BookList
- BookSortByID
- BookTitleGet
な風にすると揃えられます。Get/Set のように動詞を前にするか後ろにするかは異論があるでしょうが、それは業務ドメインによって判断してください。もちろん、この「Book」の場合、Book クラスを作っておいて、メソッド/プロパティでまとめる、ってのが王道ですが（そのあたりが、オブジェクト指向なんですけど）。
