クラスの命名-すべてを「<WhatEver> Manager」と呼ばないようにする方法 [閉まっている]

ずっと前に私は記事を読んだことがあります（私はブログエントリだと思います）。これは、オブジェクトの名前付けに関する「正しい」トラックに私を導きました。

たとえば、私のアプリケーションが（典型的なビジネスアプリとして）ユーザー、会社、アドレスを処理している場合、a User、a、CompanyおよびAddressドメインクラスがあり、おそらくこれらの処理を行うa UserManager、a、CompanyManagerおよびanのAddressManagerポップアップが表示されます。

だからあなたは何それらを伝えることができるUserManager、CompanyManagerとAddressManagerのですか？いいえ。Managerは、ドメインオブジェクトで実行できるすべてのものに当てはまる非常に一般的な用語であるためです。

私が読んだ記事では、非常に具体的な名前を使用することをお勧めしました。それがC ++アプリケーションであり、UserManagerの仕事がユーザーの割り当てとヒープからの解放であった場合、ユーザーを管理するのではなく、その誕生と死を守ります。うーん、多分これをと呼ぶことができますUserShepherd。

または、UserManagerの仕事は、各Userオブジェクトのデータを調べて、データに暗号で署名することです。次に、UserRecordsClerk。

この考えが私にくっついたので、私はそれを適用しようとします。そして、このシンプルなアイデアを驚くほど難しいものにしてください。

私はクラスが何をするかを説明することができます（そして私が迅速で汚いコーディングに陥らない限り）私が書くクラスは正確に1つのことを行います。その説明から名前に行くのに欠けているのは、一種の名前のカタログであり、概念を名前にマッピングする語彙です。

最終的には、パターンカタログのようなものを念頭に置きたいと思います（多くの場合、設計パターンは、ファクトリーなどのオブジェクト名を簡単に提供します）。

• ファクトリー-他のオブジェクトを作成します（設計パターンから取得した名前）
• 羊飼い-羊飼いはオブジェクトの寿命、オブジェクトの作成とシャットダウンを処理します
• Synchronizer-2つ以上のオブジェクト（またはオブジェクト階層）間でデータをコピーします

• ナニー-オブジェクトが作成後に「使用可能な」状態に達するのを支援します-他のオブジェクトへの配線などにより

• などなど

それで、あなたはその問題をどのように扱いますか？あなたは固定された語彙を持っていますか、あなたはその場で新しい名前を発明しますか、それともそれほど重要ではないか間違っているものに名前を付けることを考えますか？

PS：この問題について議論している記事やブログへのリンクにも興味があります。初めに、私がそれについて考えさせた元の記事は次のとおりです：「マネージャー」なしのJavaクラスの命名

更新：回答の要約

その間、私がこの質問から学んだことの簡単な要約を以下に示します。

• 新しい隠喩を作成しないようにしてください（乳母）
• 他のフレームワークが何をするか見てください

このトピックに関する他の記事/本：

• 定期的にクラスの先頭に追加/追加している名前は何ですか？
• クラスに名前を付ける最善の方法は何ですか？
• 本：設計パターン：再利用可能なオブジェクト指向ソフトウェア（ハードカバー）の要素
• 本：エンタープライズアプリケーションアーキテクチャのパターン（ハードカバー）
• Book：実装パターン（ペーパーバック）

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

• コーディネーター
• ビルダー
• ライター
• 読者
• ハンドラ
• 容器
• プロトコル
• 目標
• コンバータ
• コントローラ
• 見る
• 工場
• エンティティ
• バケツ

そして道のための良いヒント：

名前の麻痺を取得しないでください。はい、名前は非常に重要ですが、膨大な時間を無駄にするほど重要ではありません。10分で良い名前を思い付かない場合は、先に進んでください。

私は尋ねた同様の質問を、しかし、可能な場合、私はすでに名前をコピーしようとするの.NETフレームワーク、そして私がアイデアを探したJavaとAndroidのフレームワーク。

それはそうですHelper、ManagerとUtilあなたは何の状態を含まず、一般的に、手続きや静的なクラスを調整するための添付避けられない名詞です。代替はCoordinatorです。

名前で特に紫proseyを取得し、のようなもののために行くことができるMinder、Overseer、Supervisor、Administrator、とMaster私はあなたが使用しているフレームワークの名前のようにそれを維持好む言ったように、しかし。

.NETフレームワークにもある他の一般的なサフィックス（正しい用語の場合）は次のとおりです。

• Builder
• Writer
• Reader
• Handler
• Container

あなたが見てとることができsource-code-wordle.deを、私はそこにクラスの.NETフレームワークの名前といくつかの他のライブラリの中で最も頻繁に使用されるサフィックスを分析しました。

上位20は次のとおりです。

• 属性
• タイプ
• ヘルパー
• コレクション
• コンバータ
• ハンドラ
• 情報
• プロバイダー
• 例外
• サービス
• 素子
• マネージャー
• ノード
• オプション
• 工場
• 環境
• 項目
• デザイナー
• ベース
• 編集者

私はすべて良い名前を求めています。物事の名前を選択するときは細心の注意を払うことの重要性についてよく書いています。これと同じ理由で、私は物事に名前を付けるときの隠喩に警戒しています。元の質問では、「ファクトリー」と「シンクロナイザ」は、それらが何を意味するように見えるかについて、適切な名前のように見えます。ただし、「羊飼い」と「乳母」はメタファーに基づいているため、そうではありません。コード内のクラスを文字通り乳母にすることはできません。乳母とは、実際の乳母が赤ちゃんや子供の世話をするように、他のことを非常によくするからです。それは非公式のスピーチでは問題ありませんが、誰がいつ誰を知っているかを誰が知っているかによって維持されなければならないコードでクラスを命名することは（私の意見では）許されません。

どうして？なぜなら、比喩は文化に依存し、しばしば個人にも依存するからです。あなたにとって、クラスに「乳母」という名前を付けることは非常に明確ですが、他の誰かにはそれほど明確ではないかもしれません。個人的な使用のみを目的としたコードを作成しているのでない限り、これに依存すべきではありません。

いずれにせよ、慣習は隠喩を作り、壊すことができます。「ファクトリー」自体の使用はメタファーに基づいていますが、かなり以前から存在し、現在プログラミングの世界ではかなりよく知られているものなので、安全に使用できます。ただし、「乳母」や「羊飼い」は許可されません。

実世界を正しくモデル化すれば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つのモノリシックマネージャークラスは適切な設計ではないが、「マネージャー」を使用することは悪いことではないと思います。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.、意図ではなく実装の通信に関する懸念を理解していますが、デザインパターンは、クラス設計のこれら2つの側面と結びついています。少なくとも、インフラストラクチャを扱っているときは、詳細を隠している間でも、実装設計は透過的です。

（たとえば）GOFブックで定義されているパターンでau fait になり、オブジェクトに名前を付けると、クラスの名前付け、クラスの編成、および意図の伝達において長い道のりが得られます。ほとんどの人はこの命名法（または少なくともその大部分）を理解します。

XyzManagerよりも具体的な名前をクラスに付けられない場合、これが、これが本当にクラスに属している機能であるかどうか、つまりアーキテクチャの「コードの匂い」であるかどうかを再検討するポイントになります。

覚えておくべき最も重要なことは次のとおりです。名前はわかりやすいですか？クラスが何をすることになっているのか名前を見ればわかりますか？クラス名に「Manager」、「Service」、「Handler」などの単語を使用することは一般的すぎると見なすことができますが、多くのプログラマーがそれらを使用するため、クラスの目的を理解するのにも役立ちます。

私自身、ファサードパターンを頻繁に使用しています（少なくとも、それがその名前だと思います）。私が持っている可能性がUser一つだけのユーザーを記述したクラス、そしてUsers私の「ユーザーのコレクション」を追跡するクラスを。私はクラスをaと呼んでいません。私はUserManager実際のマネージャーが好きではないので、それらを思い出させたくありません:)複数形を使用するだけで、クラスの機能を理解できます。

C＃に固有の「フレームワーク設計ガイドライン：再利用可能な.NETライブラリの規則、イディオム、およびパターン」には、命名のロジックに関する多くの優れた情報があることがわかりました。

ただし、これらのより具体的な単語を見つけることに関しては、シソーラスを使用して関連する単語をジャンプして、適切な単語を見つけようとします。私はそれを多くの時間に費やさないようにしていますが、開発を進めるにつれて、より良い名前を思い付くか、時にはそれSuchAndSuchManagerが本当に複数のクラスに分割されるべきであることに気づき、その非推奨クラスの名前は問題にならない。

ここで重要なことは、コードの可視性の範囲内で一貫していることです。つまり、コードを調べたり作業したりする必要があるすべての人が命名規則を理解している限り、たとえそれらを呼び出すことにしたとしても、それは問題ありません。 「CompanyThingamabob」と「UserDoohickey」。あなたが会社で働いているなら、最初のストップは会社の命名規則があるかどうかを確認することです。会社にいない、または会社で働いていない場合は、自分にとって意味のある用語を使用して独自に作成し、少なくとも何気なくコーディングしている信頼できる数人の同僚や友人に渡し、意味のあるフィードバックを組み込んでください。

広く受け入れられている場合でも、他の人の慣習を適用することが、ページから飛び出さない場合は、私の本では少し誤りです。何よりもまず、他のドキュメントを参照せずにコードを理解する必要がありますが、同時に、同じ業界の同じ分野の他の誰かが理解できないほど十分に一般的である必要があります。

私はあなたがあなたのシステムに使用しているパターンを考えます、命名規則/カタログ/クラスのグループ化は使用されるパターンによって定義される傾向があります。個人的には、他の人が私のコードを取得して実行できるようになる可能性が最も高い方法であるため、これらの命名規則に従います。

たとえば、UserRecordsClerkは、UserRecordsClerkとCompanyRecordsClerkの両方が実装してから専門化する一般的なRecordsClerkインターフェースを拡張することでより適切に説明される可能性があります。

詳細については、デザインパターンなどの本を参照してください。これは優れた本であり、コードを使用する目的を明確にするのに役立つ場合があります（まだ使用していない場合）。; o）

パターンが適切に選択され、適切に使用されている限り、かなり独創的なクラス名で十分です。