抽象クラスの名前に接頭辞Abstract
を付けるチームのコーディング標準が必要ですか?例えば.
public abstract class AbstractB implements B {}
はい、実際に http://download.Oracle.com/javase/6/docs/api/ の標準ライブラリのjavadocを見ると、クラスのリストが左下のフレームは、質問で言及した命名規則を使用した抽象クラスで始まります。
AbstractAction
AbstractAnnotationValueVisitor6
AbstractBorder
AbstractButton
AbstractCellEditor
AbstractCollection
AbstractColorChooserPanel
AbstractDocument
AbstractDocument.AttributeContext
AbstractDocument.Content
AbstractDocument.ElementEdit
AbstractElementVisitor6
AbstractExecutorService
AbstractInterruptibleChannel
AbstractLayoutCache
AbstractLayoutCache.NodeDimensions
AbstractList
AbstractListModel
AbstractMap
AbstractMap.SimpleEntry
AbstractMap.SimpleImmutableEntry
AbstractMarshallerImpl
AbstractMethodError
AbstractOwnableSynchronizer
AbstractPreferences
AbstractProcessor
AbstractQueue
AbstractQueuedLongSynchronizer
AbstractQueuedSynchronizer
AbstractScriptEngine
AbstractSelectableChannel
AbstractSelectionKey
AbstractSelector
AbstractSequentialList
AbstractSet
AbstractSpinnerModel
AbstractTableModel
AbstractTypeVisitor6
AbstractUndoableEdit
AbstractUnmarshallerImpl
AbstractWriter
それらのいずれかを取り、最初のものを言い、その定義を確認します:AbstractAction
。それは確かにAction
を実装しますが、これも慣習に似ています。サブクラスの名前は、ClosedAction
、MaximizeAction
などです。
一般的に、チームの設定では、あらゆる種類の標準が適切です。そうしないと、チームメンバは、自分だけが理解できるような方法でクラスに名前を付け、その後、混乱につながる人々のさまざまなコーディングスタイルが混在する可能性があります。
読みやすさのために、それは良いアイデアのように聞こえます。コードを読むと、クラスが何であるかをすぐに知ることができます。誰もが標準に従う限り、それは良いことです。
最新のIDEでは、オブジェクトの上にマウスを移動すると説明テキストがポップアップ表示されます。この場合、プレフィックスは冗長です。
私は答えに賛成か反対かを言いませんが、あなたが選ぶものは何でも、良い 静的分析ツール を使ってそれを確実にします。
このタイプのほとんどの質問と同様に、「それは依存します」。私は一貫性と明快さが好きなので、それがあなたとあなたの店のために働くなら、素晴らしい。ただし、従来の抽象クラスがある場合は、戻って同じ名前付け規則にリファクタリングする必要があります。