回答:
BlochのEffective Java（Item 18）によると、Abstractプレフィックスは特別な場合に使用される規則です。
抽象骨格実装クラスを提供して、エクスポートする各自明でないインターフェイスに対応することにより、インターフェイスと抽象クラスの長所を組み合わせることができます。...慣例により、骨格実装はAbstractInterfaceと呼ばれます。Interfaceは実装するインターフェースの名前です。
しかし、Blochは、SkeletalInterfaceという名前は理にかなっていると指摘していますが、
アブストラクトコンベンションが確立されました。
他の回答が指摘しているように、一般的にこの命名規則をすべての抽象クラスに適用する理由はありません。
慣習はありません。開発者があなたのコードをより速く、より良くし、他の人があなたのコードを理解するのを助けるのは、すべてです。
コードを見て保守する人に尋ねてください。彼らはむしろ何を見ますか？それらで何が簡単になりますか？次に、希望するものに基づいて名前を付けます。
別の注意として、Javaプログラミング言語のコード規約：9.命名規約は要件を示唆していません：
クラス名は名詞で、大文字と小文字が混在する各内部単語の最初の文字を使用する必要があります。クラス名はシンプルでわかりやすいものにしてください。単語全体を使用して、頭字語や略語を避けます（略語がURLやHTMLなどの長い形式よりもはるかに広く使用されている場合を除く）。
いいえ。IntelliSenseは抽象的かどうかを簡単に教えてくれるので、ここでDRYに違反しているだけです。
abstractクラス名に追加してもDRYに違反することはなく、全員がインテリジェンスを使用するわけではありません。たとえば、Webページのコードを読んでいる場合、またはプレーンテキストエディターまたは外部diffツールで表示しているパッチの一部である場合はどうしますか？
abstract class AbstractName？明らかに「抽象」が2回ある。Intellisenseを使用していない場合、それが問題です。他のすべてのユーザーは、適切なツールを使用してコードを表示します。
.NETでは、抽象基本クラスを示すための接尾辞として「Base」が使用されることがよくあります。これがJavaの一般的な慣行であるかどうかについては、他の回答を保留します。
私の意見では、エンティティの名前はそのタイプ構造に関する情報ではなく、セマンティクスに関する情報を伝える必要があります。したがって、抽象化が実行時の目標の一部ではない場合、クラスを「AbstractSomething」として定義することは意味がありません。それが基本抽象クラスであることはプログラマーに見えるため、名前に反映する必要はありません。
ただし、抽象ファクトリの実装をAbstractFactoryと呼ぶのが完璧な場合は、クラスの意図に関連しているためです。
一般に、クラスの目標に関する最も多くの情報を伝えるのに役立つ命名規則を支持します。
同様に、から離れてくださいSomethingImpl。基本クラスではなく、実装であることを気にしません。クラス階層が継承用に適切に設計されている場合、誰かがそれを継承できます。確かに、「Impl」サフィックスやその他のアーティファクトを追加しても、それらには価値はありません。「Interface」サフィックスまたは「I」プレフィックスを追加することにも価値はありません。
考慮してください：
IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImplとは対照的に：
Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
<-- Ferrari
<-- Trabi
私は後者をはるかに好む。
これは、いくつかの点では、と同様の露骨な誤用のハンガリアン記法後者はそれをそれにその悪評を与えた人々が誤って変数の型の指標とその変数の前に付けるために、開発者が必要とするものとしてそれを解釈するために始めたとして、。これには用途がある場合がありますが（ほとんどの場合、型の定義を検索するのが面倒な場合）、ほとんど役に立ちません。ハンガリー記法に関するSimonyiの当初のアイデアは、それをニーモニックとして使用して、そのタイプではなく、エンティティの機能を開発者に思い出させることでした。
良い経験則は、構文から明らかな名前にプロパティを含めないことです。Javaでは、抽象クラスを適切な名前のabstractキーワードでマークする必要があるので、抽象クラスを名前に含めません。たとえば、C ++では、ケースはそれほど明確ではありませんが、少なくともコンパイラーは、抽象クラスを誤って使用したことを通知します。再びPythonのようなものでは、抽象クラス自体を明示的に命名することは悪い考えではありません。
規則の通常の例外は、名前があいまいな場合です。何らかの理由で具体的なサブクラスがある場合Task（他の例では、これはより賢明かもしれませんが、何であれ）、を使用してくださいAbstractTask。
protected abstract SomeClass { }これにより、これが抽象クラスであることがわかります。接頭辞の追加はトートロジーおよびアンチパターンであり、ほとんどの場合適切ではありませんpackage local。たとえば、例外であることについて言及しているリンクを参照してください。
ほとんどの場合、Abstractクラスは一般向けAPIの一部であってはなりません。もしそれが本当に正当な理由があり、正当な理由が以外の明らかに適切な名前を提供するべきであるならAbstractSomeClass。
ほとんどの場合、よりわかりやすい名前を思い付かない場合は、おそらく再設計を行う必要があります。
私の五セント、おそらくあなたはその抽象クラスの実装を持ち、それらは「SomeSpecificTask」、「TaskWithBubbles」、「StrangeTask」などと命名されるでしょう。したがって、抽象「Task」とそれらの間に名前の衝突はありません。
さらに、「抽象」という言葉はビジネスドメインエンティティではなく、言語の構文に関するものなので、名前の一部として使用したくないと思います。
一方、ここでの答えの1つに、J.Bloch Effective Javaからの抜粋がありました。これは、名前の一部として「抽象」を使用することは、確立された慣行であると述べています。そうかもしれません。しかし、とにかく公式のJavaコード規約ではそれについて何もありません。
私はJava開発者ではなく（INAJD？）、そのようなものの標準的な命名法を知らないのですが、私はTask、それがそのままの状態で立つことができるほど十分に抽象的な音だと思います。