命名クラス - すべてを "<WhatEver>マネージャー"と呼ぶのを避ける方法は？
昔、私はオブジェクトの命名に関する「正しい」トラックに私を置く記事（私はブログ記事だと思う）を読んだことがあります。
たとえば、私のアプリケーションが（典型的なビジネスアプリケーションとして）ユーザー、会社、および住所を処理していた場合、User、Company、およびAddressドメインクラスがあります。 UserManager、CompanyManager、およびAddressManagerがポップアップ表示され、それらが処理されます。
それで、あなたはそれらのUserManager、CompanyManager、そしてAddressManagerが何をしているのかわかりますか？いいえ、Managerはドメインオブジェクトを使ってできることに当てはまる非常に一般的な用語です。
私が読んだ記事では、非常に具体的な名前を使用することをお勧めしました。それがC++アプリケーションであり、UserManagerの仕事がユーザーを割り当ててヒープから解放することであれば、ユーザーを管理するのではなく、彼らの誕生と死を守ることになります。うーん、多分これをUserShepherdと呼ぶことができます。
あるいはUserManagerの仕事は、各Userオブジェクトのデータを調べてデータに暗号化することです。それならUserRecordsClerkがあります。
このアイデアが私にはまったので、私はそれを適用しようとします。そして、この単純なアイデアを驚くほど難しいと思います。
私はクラスが何をするのか、そして私が書くクラスが正確にoneすることを説明することができます。その説明から名前に行き過ぎるのは、一種の名前のカタログ、概念を名前にマップする語彙です。
最終的に私は私の心の中でパターンカタログのようなものが欲しいのです（しばしばデザインパターンは簡単にオブジェクト名を提供します、例えばfactory）
- Factory - 他のオブジェクトを作成します（デザインパターンから取った命名）
- シェパード - シェパードはオブジェクトの存続期間、それらの作成とシャットダウンを処理します。
- Synchronizer - 2つ以上のオブジェクト（またはオブジェクト階層）間でデータをコピーします
Nanny - 作成後にオブジェクトが「使用可能」な状態になるのを助けます - 例えば他のオブジェクトへの配線によって
など.
それで、あなたはどのようにその問題に対処しますか？あなたは固定語彙を持っていますか、あなたはその場で新しい名前を発明しますか、あるいは物事を命名することはそれほど重要ではないか間違っていますか？
P.S .：私は問題について議論している記事やブログへのリンクにも興味があります。最初に、私がそれについて考えさせた最初の記事はここにあります： 「マネージャ」なしでJavaクラスに名前を付ける
更新：回答のまとめ
これまでの間に、この質問から私が学んだことを少し要約します。
- 新しい隠喩を作らないようにしてください。（Nanny）
- 他のフレームワークが何をするのか見てください。
このトピックに関するさらなる記事/本：
- 定期的にクラスの前に付けたり付けたりする名前は何ですか？
- クラスの命名に最も適した方法は何ですか？
- 本： デザインパターン：再利用可能なオブジェクト指向ソフトウェア（ハードカバー）の要素
- 本： エンタープライズアプリケーションアーキテクチャのパターン（ハードカバー）
- Book： Implementation Patterns（ペーパーバック）
そして私が答えから（主観的に！）集めた名前の接頭辞/接尾辞の現在のリスト：
- コーディネーター
- ビルダー
- 作家
- リーダー
- ハンドラ
- 容器
- プロトコル
- ターゲット
- コンバータ
- コントローラ
- 見る
- 工場
- エンティティ
- バケツ
そして道のための良いヒント：
命名麻痺をしないでください。はい、名前は非常に重要ですが、膨大な時間を無駄にするほど重要ではありません。あなたが10分で良い名前を思い付くことができないならば、上に進んでください。
同様の質問 をしましたが、可能であれば、.NETフレームワークにすでにある名前をコピーしようとし、JavaとAndroidのフレームワークでアイデアを探します。
Helpername__、Managername__、およびUtilname__は、状態を含まず、通常は手続き型で静的なクラスを調整するために付ける必然的な名詞です。代替方法はCoordinatorname__です。
あなたは特に紫色のproseyをその名前で手に入れてMindername__、Overseername__、Supervisorname__、Administratorname__、そしてMastername__のようなものを選ぶことができますが、私はあなたが慣れ親しんでいるフレームワーク名のように保つことを好む。
.NETフレームワークにある他の一般的な接尾辞（それが正しい用語である場合）は以下のとおりです。
Buildername__Writername__Readername__Handlername__Containername__
あなたは source-code-wordle.de を見てみることができます、私はそこで.NETフレームワークと他のいくつかのライブラリのクラス名の最もよく使われる接尾辞を分析しました。
トップ20は以下のとおりです。
- 属性
- タイプ
- ヘルパー
- コレクション
- コンバータ
- ハンドラ
- 情報
- 提供者
- 例外
- サービス
- 素子
- 部長
- ノード
- オプション
- 工場
- コンテキスト
- 項目
- デザイナー
- ベース
- 編集者
私はみんな良い名前を求めています。私は物事の名前を選ぶときは細心の注意を払うことの重要性についてよく書きます。これとまったく同じ理由で、物事に名前を付けるときは私は隠喩には用心しています。元の質問では、 "factory"と "synchronizer"はそれらが何を意味しているように見えるかについて良い名前のように見えます。しかし、 "shepherd"と "nanny"はそうではありません、なぜならそれらは 比喩 に基づいているからです。あなたのコードの中のクラスは 文字通り a nannyにすることはできません。実生活の乳母が赤ちゃんや子供の世話をするのと非常によく似ているので、あなたはそれを乳母と呼びます。非公式のスピーチでは大丈夫ですが、誰がいつ知っているのかを誰が知っているかによって管理されなければならないコードでクラスに名前を付けることはできません（私の意見では）。
どうして？比喩は文化に依存し、しばしば個人にも依存するからです。あなたには、クラス "nanny"の命名は非常に明確になることができますが、多分それは他の誰かにそれほど明確ではありません。個人的な使用のみを目的としたコードを書いているのでなければ、それに頼るべきではありません。
いずれにせよ、条約は比喩を作るか破ることができます。 「ファクトリー」自体の使用は比喩に基づいていますが、かなり前からあり、プログラミングの世界ではかなりよく知られているので、使用しても安全だと思います。しかし、 "乳母"と "羊飼い"は受け入れられません。
実世界を正しくモデル化すれば、xxxFactory、xxxManager、xxxRepositoryのクラスを使わずに行うことができます。
Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
.Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
.OfType<User>().CreateNew("John Doe");
;-)
Thedailywtf.com、 "ManagerOfPeopleWhoHaveMortgages"などに掲載されるような、なめらかな坂道のようです。
1つのモノリシックなManagerクラスが良い設計ではないのは正しいと思いますが、 'Manager'を使用することは悪いことではありません。 UserManagerの代わりに、UserAccountManager、UserProfileManager、UserSecurityManagerなどに分類することができます。
「マネージャー」は、クラスが現実の「もの」を表していないことを明確に示しているので、良い言葉です。 'AccountsClerk' - それがユーザーデータを管理するクラスなのか、それとも自分の仕事でAccounts Clerkなのかを表すクラスなのかどうかをどのように判断すればよいですか。
この分野の記事に興味があるので、Steve Yeggeの意見記事「名詞の王国での処刑」に興味があるかもしれません。
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
クラス名にManagerまたはHelperを使うことを考えているとき、それは正しい抽象化をまだ見つけていないこと、および/または 単一責任の原則 に違反していることを意味するコード臭いと見なします。そのため、リファクタリングを行い設計に力を入れると、命名がはるかに容易になります。
しかし、よく設計されたクラスであっても（常に）名前を付けているわけではなく、ビジネスモデルクラスを作成するのか、テクニカルインフラストラクチャクラスを作成するのかによって、選択は部分的に異なります。
ビジネスモデルクラスは、ドメインごとに異なるため、難しい場合があります。ドメイン内のストラテジークラスのPolicyのように、私がよく使用する用語がいくつかあります（例：LateRentalPolicy）が、ビジネスユーザーと共有できる " ユビキタス言語 "を作成しようとすることから来るのが普通です。現実世界のアイデア、オブジェクト、アクション、およびイベントをモデル化するようにクラスを設計および命名する。
テクニカルインフラストラクチャクラスは、私たちがよく知っているドメインを記述しているので、少し簡単です。 InsertUserCommand,CustomerRepository,やSapAdapter.のように、設計パターン名をクラス名に組み込むことを好みます。意図というよりは、インプリメンテーション・インプリメンテーションについての懸念を理解しています。詳細を隠している間でも、実装 design を透明にしたいのです。
もし私がXyzManagerよりも私のクラスのためにもっと具体的な名前を思い付くことができないなら、これがこれがクラスに一緒に属する本当に機能的なものかどうか、すなわち建築的な 'コード臭'かどうかを再考するポイントです。
GOF book で定義されているパターンに不合格であること、そしてこれらの後にオブジェクトを命名することは、クラスの命名、それらの体系化、そして意図の伝達において非常に長い意味を持ちます。ほとんどの人はこの命名法（あるいは少なくともその大部分）を理解するでしょう。
私が覚えておくべき最も重要なことは次のとおりだと思います。名前は十分に説明的なものか？あなたはそのクラスが何をするべきなのかという名前を見て教えてもらえますか？クラス名に "Manager"、 "Service"、 "Handler"などの単語を使用することは一般的すぎると考えられますが、多くのプログラマがそれらを使用するため、クラスの目的を理解するのにも役立ちます。
私自身もファサードパターンを多用してきました（少なくとも、それがいわゆる呼ばれていると思います）。 1人のユーザーだけを記述するUserクラスと、私の "ユーザーのコレクション"を追跡するUsersクラスがあります。実生活では管理者が好きではないし、思い出したくないので、クラスをUserManagerと呼びません。:)複数形を使用するだけで、クラスの機能を理解するのに役立ちます。
C＃に特化して、 "フレームワーク設計のガイドライン：再利用可能な.NETライブラリの規約、慣用句、パターン" /命名の論理について多くの優れた情報を持っていることがわかりました。
ただし、これらのより具体的な単語を見つけることに関しては、シソーラスを使用し、関連する単語を調べて良い単語を見つけようとすることがよくあります。私は開発を進めていくにつれてより良い名前を思いついたり、時にはSuchAndSuchManagerを実際には複数のクラスに分割しなければならないことに気付いて、その非推奨クラスの名前が非公式になるようにします。問題。
ここで重要なことはあなたのコードの可視性の範囲内で一貫していること、すなわちあなたのコードを見て/作業する必要があるすべての人があなたの命名規則を理解している限り「CompanyThingamabob」と「UserDoohickey」。あなたが会社で働いている場合、最初のストップは、命名のための会社の規約があるかどうかを確認することです。会社に勤務していない、または勤務していない場合は、自分に理にかなった用語を使用して独自の文章を作成し、少なくとも気軽にコードを書く数人の信頼できる同僚や友人に渡してください。
広く受け入れられている場合でも、他の人の規約を適用しても、ページから飛び出さないのであれば、私の本ではちょっとした間違いです。まず第一に私は他のドキュメンテーションを参照せずに自分のコードを理解する必要がありますが同時にそれは同じ業界の同じ分野の他の人には理解できないほど十分に一般的である必要があります。
私はあなたがあなたのシステムのために使っているパターン、クラスの命名規則/カタログ化/グループ化が使われるパターンによって定義される傾向があると考えるでしょう。個人的には、他の人が自分のコードを入手して実行できる可能性が最も高いので、これらの命名規則に従います。
たとえば、UserRecordsClerkは、UserRecordsClerkとCompanyRecordsClerkの両方が実装して特殊化する一般的なRecordsClerkインターフェースを拡張すると説明しやすい場合があります。つまり、インターフェース内のメソッドを調べて、そのサブクラスの目的を確認できます。
Design Patterns などの本を参照してください。情報はすばらしい本で、コードの使用場所を明確にするのに役立ちます - まだ使用していないのであれば！ ; o）
あなたのパターンが適切に選択され使用されている限り、私は考えています。