15

インターフェイスまたはクラスによって表される概念があり、それを拡張する一連のサブクラス/サブインターフェイスがある状況に陥ることがよくあります。

例: 汎用の「DoiGraphNode」 リソースを表す「DoiGraphNode」 Java リソースを表す「DoiGraphNode」 パスが関連付けられた「DoiGraphNode」など。

3 つの命名規則が考えられます。選択方法についてコメントをいただければ幸いです。

オプション 1: 常にコンセプトの名前から始めます。

したがって、DoiGraphNode、DoiGraphNodeResource、DoiGraphNodeJavaResource、DoiGraphNodeWithPath などです。

長所: 何を扱っているかが非常に明確です。すべてのオプションを簡単に確認できます。

短所：あまり自然ではありませんか？全部同じに見える？

オプション 2: 特別なものを先頭に置きます。

したがって、DoiGraphNode、ResourceDoiGraphNode、JavaResourceDoiGraphNode、PathBaseDoiGraphNode など。

長所：コードで見ると非常に明確です

短所: 特に名前を覚えていない場合、見つけるのが難しい場合があります。視覚的な一貫性がありません。

オプション 3: 特別なものを配置し、冗長なテキストの一部を削除する

したがって: DoiGraphNode、ResourceNode、JavaResourceNode、GraphNodeWithPath

長所: 読み書きすることがそれほど多くない 短所: cr*p のように見え、非常に一貫性がなく、他の名前と競合する可能性がある

4

5 に答える 5

7

それらが何であるかにちなんで名前を付けます。

名前を付けるのが難しい、またはあいまいな場合は、多くの場合、クラスがやりすぎていることを示しています (単一責任の原則)。

名前の競合を避けるために、名前空間を適切に選択してください。

個人的には3を使いたい

于 2009-02-22T03:45:40.310 に答える
5

好きなものを使ってください、それは主観的なものです。重要なことは、各クラスが何を表しているかを明確にすることであり、名前は継承関係が意味をなすようなものにする必要があります。ただし、関係を名前にエンコードすることはそれほど重要ではないと思います。それがドキュメンテーションの目的です (そして、あなたの名前がオブジェクトに適していれば、人々は何が何から継承されているかを推測できるはずです)。

価値のあるものとして、私は通常オプション 3 を使用します。他の人のコードを見てきた経験から、オプション 2 はおそらくオプション 1 よりも一般的です。

于 2009-02-22T03:42:45.463 に答える
2

たとえば、C# の IDesign ドキュメントがここにあります。

個人的には、オプション 2 を好みます。これは一般に、.NET Framework がそのオブジェクトに名前を付ける方法です。たとえば、属性クラスを見てください。それらはすべて属性 (TestMethodAttribute) で終わります。同じことが EventHandlers にも当てはまります。OnClickEventHandler は、Click イベントを処理するイベント ハンドラーの推奨される名前です。

私は通常、独自のコードとインターフェイスを設計する際にこれに従うようにしています。したがって、IUnitWriter は StringUnitWriter と DataTableUnitWriter を生成します。このようにして、私は常にそれらの基本クラスが何であるかを知り、より自然に読みます。自己文書化コードはすべてのアジャイル開発者の最終目標であるため、私にとってはうまくいくようです!

于 2009-02-24T02:33:10.450 に答える
2

特にクラスがポリモフィックに使用される場合は、通常、オプション 1 と同様の名前を付けます。私の推論は、最も重要な情報が最初にリストされているということです。(つまり、サブクラスは基本的に先祖と同じであり、(通常) 拡張機能が「追加」されているという事実)。クラス名のリストをソートするときに、関連するクラスが一緒にリストされるため、このオプションも気に入っています。つまり、通常、翻訳単位 (ファイル名) にクラス名と同じ名前を付けるので、関連するクラス ファイルが自然に一緒にリストされます。同様に、これはインクリメンタル検索にも役立ちます。

私はプログラミングのキャリアの早い段階でオプション2を使用する傾向がありましたが、あなたが言うように「一貫性がなく」、あまり直交していないように見えるため、今は避けています。

サブクラスが実質的な拡張または仕様を提供する場合、または名前がかなり長くなる場合は、オプション 3 をよく使用します。たとえば、私のファイル システム名クラスは String から派生していますが、String クラスを大幅に拡張しており、用途や意味が大きく異なります。

String から派生した Directory_entry_name は、広範な機能を追加します。Directory_entry_name から派生した File_name には、かなり特殊な機能があります。Directory_entry_name から派生した Directory_name にも、かなり特殊な機能があります。

また、オプション 1 とともに、通常はインターフェイス クラスに非修飾名を使用します。たとえば、クラス相互チェーンがあるとします。

  • テキスト (インターフェース)
  • Text_abstract (抽象 (基本) 汎化クラス)
  • Text_ASCII (ASCII コーディングに固有の具象クラス)
  • Text_unicode (Unicode コーディングに固有の具象クラス)

インターフェイスと抽象基本クラスがソートされたリストの最初に自動的に表示されるのが好きです。

于 2009-03-01T10:48:15.947 に答える
0

オプション 3 は、継承の概念からさらに論理的に導かれます。インターフェイスまたはクラスを特殊化しているため、名前は基本実装を使用していないことを示す必要があります (存在する場合)。

クラスが何から継承されているかを確認するためのツールは多数あるため、クラスの実際の機能を示す簡潔な名前は、あまりにも多くの型情報を名前に詰め込もうとするよりもはるかに役立ちます。

于 2009-02-22T04:08:07.447 に答える