クラスに適切で正確な名前を付けることは、非常に難しいことで知られています。正しく実行すると、コードがより自己文書化され、抽象化のより高いレベルでコードについて推論するための語彙が提供されます。
特定の設計パターンを実装するクラスには、よく知られているパターン名 (FooFactory、FooFacade など) に基づいた名前が付けられ、ドメインの概念を直接モデル化するクラスは、問題のドメインから名前を取得できますが、他のクラスはどうでしょうか? インスピレーションがなく、一般的なクラス名 (FooHandler、FooProcessor、FooUtils、FooManager など) の使用を避けたい場合に参照できるプログラマーのシソーラスのようなものはありますか?
Kent Beck による実装パターンからいくつかの一節を引用します。
「[...] 名前は短くてパンチの効いたものにする必要があります。ただし、名前を正確にするには、いくつかの単語が必要な場合があります。このジレンマから抜け出す方法は、計算に強力なメタファーを選択することです。メタファーを念頭に置いて、単一の単語は、関連付け、接続、および含意の豊富なネットワークをもたらします. たとえば、HotDraw 描画フレームワークでは、描画内のオブジェクトの私の最初の名前は DrawingObject でした. ウォード・カニンガムは、タイポグラフィのメタファーと共に来ました: a drawing is like印刷され、レイアウトされたページ。ページ上のグラフィック項目は図であるため、クラスはFigureになりました。比喩の文脈では、FigureはDrawingObject よりも短く、豊かで、正確です。」
「サブクラスの名前には 2 つの役割があります。サブクラスは、どのようなクラスであり、どのように異なるかを伝える必要があります。[...] 階層のルートにある名前とは異なり、サブクラス名は会話でほとんど使用されません。そのため、簡潔さを犠牲にして表現力を高めることができます [...]
階層のルートとして機能するサブクラスには、独自の単純な名前を付けます。たとえば、HotDrawには、図が選択されたときに図を編集する操作を表すクラスHandleがあります。Figure を拡張したにもかかわらず、単純にハンドルと呼ばれます。ハンドルのファミリ全体があり、 StretchyHandleやTransparencyHandleなどの名前が最も適切 です。Handleはそれ自体の階層のルートであるため、修飾されたサブクラス名よりも単純なスーパークラス名を使用する価値があります。
サブクラスの命名におけるもう 1 つの欠点は、複数レベルの階層です。[...] 修飾子を直接のスーパークラスにやみくもに追加するのではなく、読者の観点から名前について考えてください。このクラスがどのようなクラスであるかを知るには、どのクラスが必要ですか? そのスーパークラスをサブクラス名のベースとして使用してください。」
インターフェースの命名方法には、インターフェースの考え方に応じて 2 つのスタイルがあります。実装のないクラスとしてのインターフェイスは、クラスであるかのように名前を付ける必要があります (単純なスーパークラス名、修飾されたサブクラス名)。この命名スタイルの問題点の 1 つは、クラスに名前を付ける前に適切な名前が使い果たされることです。Fileと呼ばれるインターフェースには、 ActualFile、ConcreteFile、または (ヤッ!) FileImplなどと呼ばれる実装クラスが必要 です。(接尾辞と省略形の両方)。一般に、具体的なオブジェクトを扱っているのか抽象オブジェクトを扱っているのかを伝えることは重要であり、抽象オブジェクトがインターフェースまたはスーパークラスとして実装されているかどうかはそれほど重要ではありません。インターフェイスとスーパークラスの区別を延期することは、この命名スタイルによって十分にサポートされており、必要になった場合に後で自由に変更することができます。
インターフェイスの使用を隠すよりも、具体的なクラスに名前を付ける方がコミュニケーションにとって重要な場合があります。この場合、インターフェイス名の前に「I」を付けます。インターフェイスがIFileと呼ばれる場合、クラスは単にFileと呼ばれます。
より詳細な議論については、本を購入してください。価値がある！:)
常に MyClassA、MyClassB を使用してください - これにより、優れたアルファ ソートが可能になります。
冗談です！
これは良い質問であり、私が少し前に経験したことです。仕事でコードベースを再編成していて、どこに何を置き、何と呼ぶかという問題がありました..
本当の問題？
やりすぎた授業がありました。単一の責任の原則を守ろうとすると、すべてがうまくまとまります..1つのモノリシックなPrintHandlerクラスではなく、それをPageHandler、PageFormatter (など)に分解し、マスターPrinterクラスを持つことができます。すべてをまとめます。
私の再編成では、時間がかかりましたが、多くの重複コードをビンに入れ、コードベースをより論理的にし、クラスに追加のメソッドをスローする前に考えることに関して、非常に多くのことを学びました:D
ただし、パターン名などをクラス名に入れることはお勧めしません。クラス インターフェイスはそれを明確にする必要があります (シングルトンのコンストラクターを非表示にするなど)。クラスが一般的な目的を果たしている場合、一般的な名前に問題はありません。
幸運を！
優れたAPI設計に関するJoshBlochの優れた講演には、いくつかの優れたアドバイスがあります。
問題が公開された内部クラスの名前にある場合は、それらをより大きなクラスに統合する必要があります。
問題が多くの異なることをしているクラスに名前を付けることである場合、それを複数のクラスに分割することを検討する必要があります。
それがパブリックAPIにとって良いアドバイスであるなら、それは他のクラスにとって害になることはありません。
名前に行き詰まっている場合は、後で修正することを約束して、中途半端な名前を付けるだけでよい場合があります。
命名麻痺を取得しないでください。はい、名前は非常に重要ですが、膨大な時間を無駄にするほど重要ではありません。10 分でいい名前が思いつかない場合は、先に進んでください。
良い名前が思い浮かばない場合は、より深い問題があるかどうかを疑問視するでしょう - クラスは良い目的を果たしていますか? そうであれば、名前を付けるのは非常に簡単です。
「FooProcessor」が実際に foo を処理する場合は、BarProcessor、BazProcessor などを既に持っているという理由だけで、その名前を付けることを躊躇しないでください。あなたのコードを読まなければならない他の開発者は、あなたと同じシソーラスを使用していない可能性があります。
とはいえ、この特定の例では、より具体的にしても害はありません。「プロセス」はかなり広い言葉です。たとえば、それは本当に「FooUpdateProcessor」(「FooUpdater」になる可能性があります) ですか? 命名について「創造的」になりすぎる必要はありませんが、コードを書いた場合は、そのコードが何を行い、何をしないかについてかなり良い考えを持っているでしょう。
最後に、生のクラス名だけが、コードの読者が続けなければならないことではないことを思い出してください。通常、名前空間も関係しています。それらは多くの場合、たとえその素の名前がかなり一般的であっても、クラスが本当に何のためにあるのかを明確に理解するのに十分なコンテキストを読者に与えることができます。