[解決済み】クラスの命名 - すべてを"<WhatEver>Manager "と呼ぶのを避けるには？[クローズド］

質問

昔、ある記事(確かブログ)を読んで、オブジェクトの命名について正しい認識を持つようになりました。プログラム中の命名には細心の注意を払いましょう。

例えば、私のアプリケーションが（典型的なビジネスアプリケーションとして）ユーザー、会社、住所を扱うものであったとしたら、私のアプリケーションは User , a Company と Address ドメインクラス、そしておそらくどこかで UserManager , a CompanyManager と AddressManager がポップアップして、それらを処理します。

では、その UserManager , CompanyManager と AddressManager を行うのですか？いいえ、マネージャーは非常に一般的な用語であり、ドメインオブジェクトでできることすべてに適合するからです。

私が読んだ記事では、非常に具体的な名前を使うことを推奨していました。もしそれがC++アプリケーションで UserManager の仕事は、ヒープからユーザーを割り当てたり解放したりすることで、それはユーザーを管理するのではなく、その誕生と死を見守ることです。ふむ、これは UserShepherd .

あるいは UserManager の仕事は、各Userオブジェクトのデータを調べ、そのデータに暗号で署名することです。そうすると UserRecordsClerk .

このアイデアが心に残ったので、私はそれを応用してみました。そして、この単純な考え方が驚くほど難しいことに気づきました。

クラスが何をするかは説明できるし、（クイック＆アンプ;ダーティなコーディングに陥らない限り）私の書くクラスは、まさに 一 のことです。その説明から名前に至るまでに必要なのは、名前のカタログのようなもので、概念を名前にマッピングする語彙なのです。

最終的には、パターンカタログのようなものを頭の中に入れておきたいと思っています（よくあるデザインパターンは、オブジェクトの名前を簡単に提供してくれますが、例えば ファクトリー )

• ファクトリー - 他のオブジェクトを作成する（デザインパターンから取ったネーミング）
• Shepherd - Shepherdは、オブジェクトのライフタイム、作成、シャットダウンを処理する。
• シンクロナイザー - 2つ以上のオブジェクト（またはオブジェクト階層）間でデータをコピーします。

• Nanny - 他のオブジェクトに配線するなどして、オブジェクトが作成後に "使用可能な状態になるのを支援します。

• などなど。

では、その問題をどのように扱っているのでしょうか。決まった語彙を持っているのか、その場で新しい名前を考案するのか、それともネーミングはあまり重要でない、あるいは間違っていると考えているのか？

追伸：この問題を論じている記事やブログへのリンクもお待ちしています。手始めに、私がこの問題について考えるきっかけとなった元記事を紹介します。 マネージャー」を使わないJavaクラスのネーミング

更新：回答のまとめ

とりあえずこの質問でわかったことを少しまとめておきます。

• 新しいメタファーを作らないようにする(ナニコレ)
• 他のフレームワークがどのようなことをしているか見てみる

このトピックの他の記事/書籍

• あなたは、定期的にクラスにどのような名前を前置/後置していますか？
• クラスの命名にはどのような方法がありますか？
• 本 デザインパターン 再利用可能なオブジェクト指向ソフトウェアの要素 (ハードカバー)
• 書籍 エンタープライズアプリケーションアーキテクチャのパターン (ハードカバー)
• 書籍 インプリメンテーション・パターン (ペーパーバック)

そして、私が（主観的に！）回答から集めた名前のプレフィックス/サフィックスの現在のリストです。

• コーディネーター
• ビルダー
• ライター
• 読者
• ハンドラ
• コンテナ
• プロトコル
• ターゲット
• コンバータ
• コントローラ
• ビュー
• 工場
• エンティティ
• バケット

そして、旅先での良いヒント。

ネーミングマヒを起こさないこと。確かにネーミングはとても重要ですが、膨大な時間を浪費するほど重要なものではありません。10分以内に良い名前が思いつかなければ、次に進みましょう。

どのように解決するのか？

を聞いてみました。 類似の質問 にある名前をコピーするようにしています。 .NET フレームワークにアイデアを求めます。 Java と アンドロイド のフレームワークを使用しています。

それは、どうやら Helper , Manager および Util は、状態を含まず、一般に手続き的で静的なクラスを調整するために付ける、避けられない名詞です。代替案としては Coordinator .

特にパープル・プロシーで名前をつけて、次のようにすることもできます。 Minder , Overseer , Supervisor , Administrator および Master しかし、私は、あなたが慣れ親しんでいるフレームワークの名前のように保つことを好むと言ったように。

その他の一般的な接尾辞（という表現が正しいかどうかわかりませんが）は .NET フレームワークがあります。

• Builder
• Writer
• Reader
• Handler
• Container