クラスに名前を付ける最善の方法は何ですか？

クラスの正確で正確な名前を付けることは悪名高いほど困難です。正しく行われると、コードがより自己文書化され、より高い抽象化レベルでコードについて推論するための語彙が提供されます。

特定の設計パターンを実装するクラスには、よく知られたパターン名（FooFactory、FooFacadeなど）に基づいた名前が付けられる場合があり、ドメインの概念を直接モデル化するクラスは、問題のドメインから名前を取得できますが、他のクラスについてはどうですか？プログラマーのシソーラスのように、インスピレーションが不足していて、汎用クラス名（FooHandler、FooProcessor、FooUtils、FooManagerなど）の使用を避けたい場合に役立つものはありますか？

ケントベックの実装パターンの一部を引用します。

単純なスーパークラス名

「[...]名前は短くパンチのあるものでなければなりません。ただし、名前を正確にするために、いくつかの単語が必要になる場合があります。このジレンマから抜け出す方法は、計算に強力なメタファーを選択することです。メタファーを念頭に置いて、単一の単語は、関連付け、接続、および含意の豊富なWebをもたらします。たとえば、HotDraw描画フレームワークでは、描画内のオブジェクトの私の最初の名前は、 DrawingObjectでした。ウォードカニンガムは、タイポグラフィのメタファーとともに登場しました。印刷され、レイアウトされたページ。ページ上のグラフィックアイテムは図であるため、クラスはFigureになりました。メタファーのコンテキストでは、Figure は同時にDrawingObjectよりも短く、機能が豊富で、正確です。

修飾サブクラス名

「サブクラスの名前には2つの仕事があります。サブクラスの名前は、どのようなクラスであり、どのように異なるのかを伝える必要があります。[...]階層のルートにある名前とは異なり、サブクラス名は会話ではほとんど使用されません。そのため、簡潔さを犠牲にして表現力を高めることができます。[...]

階層のルートとして機能するサブクラスに、独自の単純な名前を付けます。たとえば、HotDrawには、図が選択されたときに図の編集操作を表示するHandleクラスがあります。Figure を拡張しているにもかかわらず、単にHandleと呼ばれています。ハンドルのファミリ全体があり、それらにはStretchyHandleやTransparencyHandleなどの名前が最も適切 です。Handleは独自の階層のルートであるため、修飾されたサブクラス名よりも単純なスーパークラス名に値します。

サブクラスの命名におけるもう1つの問題は、複数レベルの階層です。[...]修飾子を直接スーパークラスの前に付けるのではなく、読者の視点から名前を考えてください。彼はこのクラスがどのようなものかを知る必要があるのですか？そのスーパークラスをサブクラス名の基礎として使用してください。」

インターフェース

ネーミングインターフェイスの2つのスタイルは、インターフェイスの考え方によって異なります。実装のないクラスとしてのインターフェースは、クラスであるかのように名前を付ける必要があります（単純なスーパークラス名、修飾されたサブクラス名）。この命名スタイルの1つの問題は、クラスの命名に入る前に適切な名前が使い果たされることです。Fileというインターフェースには、ActualFile、ConcreteFile、（yuck！）FileImplなどの実装クラスが必要 です。（サフィックスと省略形の両方）。一般的に、具象オブジェクトと抽象オブジェクトのどちらを扱っているかを伝えることは重要であり、抽象オブジェクトがインターフェースまたはスーパークラスとして実装されているかどうかはそれほど重要ではありません。インターフェースとスーパークラスの区別を延期することは、この命名スタイルによって十分サポートされており、必要になった場合は後で自由に変更できます。

場合によっては、具体的なクラスに名前を付ける方が、インターフェースの使用を隠すよりも、コミュニケーションにとってより重要です。この場合、インターフェース名の前に「I」を付けます。インターフェイスがIFileと呼ばれる場合、クラスは単にFileと呼ばれます。

詳細については、本を購入してください。価値があります！:)

常にMyClassA、MyClassBを使用してください。これにより、優れたアルファソートが可能になります。

冗談です！

これは良い質問であり、私が少し前に経験したことです。私は仕事でコードベースを再編成していて、どこに何を置くか、何を呼び出すかという問題を抱えていました。

本当の問題は？

授業が多すぎました。単一の責任の原則を守ろうとすると、すべてがよりうまくまとめられます。1つのモノリシックなPrintHandlerクラスではなく、PageHandler、PageFormatterなどに分解してから、マスターPrinterクラスを作成できます。すべてをまとめます。

私の再編成では時間がかかりましたが、多くの重複したコードをビニングして、コードベースをより論理的にし、クラスに追加のメソッドをスローする前に考えることについて多くのことを学びました：D

私は考えていないが、クラス名にパターンの名前のようなものを置くことをお勧めします。クラスインターフェイスは、それを明確にする必要があります（シングルトンのコンストラクタを非表示にするなど）。クラスが一般的な目的を果たしている場合、一般的な名前に問題はありません。

幸運を！

Josh Blochの優れたAPI設計に関する優れた講演には、いくつかの良いアドバイスがあります。

• クラスは1つのことを行う必要があります。
• クラスの名前付けや説明が難しい場合、おそらく前の箇条書きのアドバイスに従っていない可能性があります。
• クラス名は、クラスが何であるかを即座に伝える必要があります。
• 良い名前は良いデザインを推進します。

問題が公開された内部クラスの名前付けである場合は、それらをより大きなクラスに統合する必要があります。

問題が、さまざまなことを行うクラスの命名である場合は、クラスを複数のクラスに分割することを検討する必要があります。

それがパブリックAPIにとって良いアドバイスであれば、他のクラスに害を及ぼすことはありません。

あなたが名前で立ち往生している場合は、時々ちょうどそれを与えるあらゆる後でそれを改訂へのコミットメントで半分賢明な名前は良い戦略です。

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

良い名前が思いつかない場合は、もっと深い問題があるかどうか疑問に思うでしょう-クラスは良い目的を果たしていますか？もしそうなら、名前を付けるのはかなり簡単です。

「FooProcessor」が本当にfoosを処理する場合は、BarProcessor、BazProcessorなどがすでにあるからといって、その名前を付けるのをためらわないでください。疑わしい場合は、明らかなのが最善です。あなたのコードを読まなければならない他の開発者はあなたと同じシソーラスを使っていないかもしれません。

とはいえ、この特定の例では、より具体的にしても問題はありません。「プロセス」はかなり広義の言葉です。たとえば、それは本当に "FooUpdateProcessor"（ "FooUpdater"になる可能性がある）ですか？命名についてあまり「創造的」である必要はありませんが、コードを書いた場合、おそらくそれが何をして何をしないかについてかなり良い考えを持っているでしょう。

最後に、裸のクラス名があなたとあなたのコードの読者が続ける必要があるすべてではないことを覚えておいてください-通常、同様に名前空間も関係しています。それらはしばしば、たとえそのベアネームがかなり一般的であっても、実際にあなたのクラスが何であるかを明確に見るのに十分なコンテキストを読者に与えることができます。