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


1188

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

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

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

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

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

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

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

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

  • ファクトリー-他のオブジェクトを作成します(設計パターンから取得した名前)
  • 羊飼い-羊飼いはオブジェクトの寿命、オブジェクトの作成とシャットダウンを処理します
  • Synchronizer-2つ以上のオブジェクト(またはオブジェクト階層)間でデータをコピーします
  • ナニー-オブジェクトが作成後に「使用可能な」状態に達するのを支援します-他のオブジェクトへの配線などにより

  • などなど

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

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


更新:回答の要約

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

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

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

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

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

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

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


11
「ベスト」な答えは1つもないため、コミュニティウィキに属しています。それは議論です。
DOK

13
これは直観に反します。彼らはそれをフォーラムと呼ぶべきではありませんか?wikiは意見ではなく事実の集まりのためのものだと思います。
AaronLS 2009

78
これを更新してくれてありがとう-でも、最後のヒントはひどいアドバイスです!10分で良い名前が思いつかない場合は、クラスに問題がある可能性があります。(標準的な注意事項:1)完璧は善の敵、2)配送は機能です。技術的な負債が発生していることを忘れないでください。)
Jeff Sternal

11
10分以内に良い名前を思い付かない場合は、同僚に助けを求めてください。あきらめてはいけません。

9
10分で良い名前が思いつかない場合は、同僚に説明してみてください。彼ら良い名前を考えているかもしれませんが(user338195)、それを説明しようとすると、おそらく何が悪いのかを発見するのに役立ちます(Jeff)。
WillC、2016

回答:


204

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

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

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


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

  • Builder
  • Writer
  • Reader
  • Handler
  • Container

4
私はこれらがとても好きです。それらは、.NET Frameworkによって既に使用されているため、不良または不明なメタファーの罠にはまりません。他のライブラリー(Java)を見るのも興味深いかもしれません。一般的に使用されているものをさらに入力するためにもです。
froh42

私は提案したいConductor音楽のオーケストラのコンダクターのように、。「実施」する必要のあるコラボレーションの性質によっては、これは確かに重要な役割です(他のオブジェクトは、集中管理されたコマンドに応答し、他のすべての共同作業者についてあまり心配する必要のない非常に専門的なアクターです)。
heltonbiker、2015

1
-erクラスの解決策は別の名前を付けることではないと思います。他の多くの投稿を読んだり、答えを学ぼうとしているので、使用されている名前だけでなく、アーキテクチャを変更する必要があるということです。
Michael Ozeryansky

115

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

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

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

147
ある特定の会社で、私はエンジニアが知っていたので、会社を悩ましていたすべてのクラスを無視して不合理に成長している大量のサフィックス規則にうんざりしていましたThingy

8
この名前のリスト自体は、どのサフィックスを適用する必要があるかというコンテキストがなければ、あまり役に立ちません。
フレッド

65

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

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

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


10
この議論は、明らかにファクトリー自体が比喩であるという点で破綻します。多くの場合、メタファーはオブジェクトが何が得意かを明確にしますが、あいまいまたはジェネリックであることは、コードを完全に読み取ることによってコードが何を行うかを理解する唯一の方法です。最悪のシナリオ。
Kzqai 2017

1
「かわいい」名前を避けるための+1。言語をできるだけ直接的に扱うのは素晴らしいことだと思います。(もちろん、同時に、直接的、簡潔、正確明確であることは必ずしも容易ではありません...)
andrewf

1
創造的な動詞+ "er"の選択は、具体的なクラスでは通常、カラフルなアナロジーよりも明確になります。一方、新しい抽象概念-新しい概念であるもの、単なる新しい "もの"ではなく新しい "種類のこと"-メタファー(Javaの「豆」、Haskellの「レンズ」、GUI)としてうまく機能することがよくあります。 「ウィンドウズ」、多くの言語の「約束」)。ただし、ほとんどのコードベースには、そのような本物の発明はありません。
Malnormalulo、

51

実世界を正しくモデル化すればxxxFactoryxxxManagerxxxRepositoryクラスなしで実行できます。

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)


11
どのようにしてパラレルユニバースと代替次元に到達しますか?
tster

23
簡単です:Omniverse.Instance.Dimensions ["Ours"]。Universes ["Ours"]。Galaxies ... ... OK OK OKこれには再コンパイルが必要だと認めます。;-)
ヘルツマイスター、2010年

73
更新:これは.NET 4.0で追加されました:Universe.Instance.ToParallel();)
Connell 2013

2
しかし、デメテルの法則を破る!
Jonas G. Drange 2017

13
これらはクラス名ではなくオブジェクトとメンバーです
Harry Berry

39

それはthedailywtf.com、「ManagerOfPeopleWhoHaveMortgages」などに投稿されるものへの滑りやすい坂のように聞こえます。

1つのモノリシックマネージャークラスは適切な設計ではないが、「マネージャー」を使用することは悪いことではないと思います。UserManagerの代わりに、UserAccountManager、UserProfileManager、UserSecurityManagerなどに分解する場合があります。

「マネージャー」は、クラスが実際の「もの」を表していないことを明確に示しているため、良い言葉です。'AccountsClerk'-それがユーザーデータを管理するクラスであるか、または自分の仕事のAccounts Clerkである誰かを表すクラスであるかをどのように判断すべきですか?


8
UserAccounter、UserProfiler、UserSecurerについてはどうですか?Managerを取り除くと、特定の定義を考えざるを得なくなります。これは良いことだと思います。
Didier A.

10
UserAccount、UserProfile、UserSecurity oOはどうですか?
2013

3
「MortageOwnersManager」という名前にします
volter9

ドメインには特定の名前がある場合があります。"MortageHolder"のように、 "MortageOwner"よりも良いかもしれません
ボルジャブ


24

クラス名ManagerまたはHelperクラス名を使用することを考えているときは、コードのにおいだと思います。これは、正しい抽象化がまだ見つからないこと、および/または単一責任の原則に違反していることを意味します。そのため、リファクタリングを行い、設計により多くの労力を費やしています。多くの場合、命名がはるかに簡単になります。

しかし、適切に設計されたクラスでさえ、(常に)自分自身の名前を付けるわけではなく、選択は、ビジネスモデルクラスを作成するか、技術インフラストラクチャクラスを作成するかによって部分的に異なります。

ビジネスモデルクラスは、ドメインごとに異なるため、難しい場合があります。Policyドメイン内の戦略クラス(などLateRentalPolicy)のように、私がよく使用する用語はいくつかありますが、これらは通常、ビジネスユーザーと共有できる「ユビキタス言語」を作成しようとすることから生まれ、クラスを設計してネーミングして、実際のモデルを作成します-世界のアイデア、オブジェクト、アクション、イベント。

テクニカルインフラストラクチャクラスは、私たちがよく知っているドメインを記述しているため、少し簡単です。デザインパターン名をクラス名に組み込むのが好きです。InsertUserCommand, CustomerRepository,またはSapAdapter.、意図ではなく実装の通信に関する懸念を理解していますが、デザインパターンは、クラス設計のこれら2つの側面と結びついています。少なくとも、インフラストラクチャを扱っているときは、詳細を隠している間でも、実装設計は透過的です。


1
Policyビジネスロジックを含むクラスにサフィックスを使用するアイデアが本当に好きです
jtate

+1は、「マネージャー」や「ヘルパー」などの名前に関連付けられたコードのにおいを言及します。明確な名前がない場合、それは通常、少なくとも部分的には、ビジネスであれ技術であれ、ドメインの理解における曖昧さから生じていることがわかります。ほとんど同等に、クラスが「大きくなりすぎた」ので、私はクラスをただ反応的に分割しているだけである可能性があります。これは、モデリングが不十分であることの表れでもあります。これがトップ投票の答えになるはずです。
nclark

10

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


Fowlerは私にとって良い参考資料ですが、GOFは非常にお勧めです。
Lazarus、

私の無知を許してください。あなたはどのファウラーの本を参照していますか?
Brian Agnew


19
うーん、時々これは機能します(たとえば、ファクトリーまたは戦略のように)が、他の場合では、これはクラスの意図と仕事よりも実装の方法(パターンを使用した!)を伝えると感じます。たとえば、シングルトンの最も重要なことは、それが何を表すかであり、それがシングルトンであるということではありません。したがって、使用されるパターンの後の厳密な命名は、使用されるタイプの後の厳密な命名のように感じられます。たとえば、Windowsシステムグループによって誤って適用されたハンガリー語の表記法(「意図型」ではなくCデータ型を記述)
froh42

1
テクニカルインフラストラクチャクラスの場合、通常は実装を透過的にすることが望ましく、正規のデザインパターン名のほとんどは実装と意図の両方を伝えます。ただし、ドメインモデルクラスは別の問題です。
ジェフスターナル2010年

10

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


8

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

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


また、オブジェクトのトップダウン管理のアイデアが緩和されるため、このアプローチも本当に気に入っています。ユーザーのグループは、UserManagerからではなく、ユーザー間で作業が行われることを示唆する可能性が高くなります。また、Userへの参照をUserに所有させることは、UserManagerを所有することほど不自然には感じられません。厳密にOOPではなく、相対的な考え方に対してオープンです。
Seph Reed

この方法の問題はUsers、特にマネージャオブジェクトを渡す場合に、コードでを検索するのが非常に難しくなることです。this.users = new Users()ただし、コード内のどこかで必ずusersの配列が参照されますUser
雪だるま

あなたが言うように、ユーザーは確かに「ユーザーのコレクション」-ステートフルなエンティティのコレクションを意味します。しかし、SRPは、ユーザー管理(機能とビジネスロジック)をユーザーデータ(状態)にバンドルしたくないことを意味します。間違っていると言っているのではなく、クラスがユーザーの状態と基本的なCRUDを保存するだけでなく、ユーザーの管理を担当している場合は、そのUserManagerが適切です。
リチャードムーア

5

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

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


3

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

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


1
それでも、わずかに直感的ではないが一貫した慣習は、独自の慣習を開始するよりも優れています。プロジェクトに取り組んでいる人々は、一貫した慣習を非常に速く学習し、機能が一見して期待されるものとはまったく異なることをすぐに忘れてしまいます。
Boy氏、

@ジョン、それはまさに私が言ったことです。大会はグループに受け入れられる必要があり、会社で働いている場合は会社の大会があるかどうかを確認します。会社にとっては、オープンソースプロジェクトチームであろうと、プログラマーの緩やかなコレクションであろうと、どのグループでも考えています。誰もが自分の要件にほぼ一致する入手可能なものを採用した場合、私たちはイノベーションにひどく欠けていると思います。
Lazarus

2

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

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

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

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


私はブライアン・アグニューの答えでそれについてコメントしました。パターン名が適切なクラス名になるのは、一部の場合(Factory、Strategy)だけで、他の場合(Singleton)ではできないと思います。名前には、クラスの実装方法ではなく、クラスのジョブを反映させたいと思います。
froh42 2009
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.