6

すべての抽象クラスの名前に「Abstract」という接頭辞が付いていることを確認することをお勧めしますか?

4

9 に答える 9

4

他に良い名前を思いつくのは難しいので、この命名規則が使用されているだけだと思います。「List」という名前のインターフェースが既にある場合、「AbstractList」クラスにどのように名前を付けますか? 名前の衝突を避けてから、実装の詳細を伝えることが重要です。

于 2009-09-15T11:53:41.063 に答える
1

説明するのはちょっと難しいですが、ドメインオブジェクトのようなものではなく、機能クラスで同じコードをコピー/貼り付けすることを避けるためにのみ使用します。

  • AbstractServiceTestCase --> Abstract 接頭辞が役に立ちそうです
  • AbstractAnimal --> 奇妙で役に立たないようです

もちろん、プロジェクト全体で同じ規則に従う限り、自分で決める必要があります。

于 2009-09-15T12:08:13.577 に答える
0

クラスの使い方にもよると思います。派生クラスを強制的にインターフェースに準拠させるための内部使用のみを目的としている場合は、その前にAbstractを追加することは悪い考えではないかもしれません。ただし、実際にSpecializedFoo1またはSpecializedFoo2であるFooインスタンスを提供するFooファクトリを提供している場合、AbstractFooインスタンスを返すのは厄介なようです。

于 2009-09-15T11:51:10.563 に答える
0

これまでの回答は非常に役に立ち、責任ある実践の広がりを示しています。名前が実装を示すべきではないことに同意する傾向があります（Foo後でインターフェースに移動された抽象クラスである可能性があります）。ただし、派生クラスにメソッドを提供する必要があるという視覚的な手がかりをコーディングするときに役立ちます。

例として、私は現在階層構造を持っています (名前の論理的根拠について尋ねないでください。ただし、それらはコンテキスト内で意味があり、XML 要素名にマップされます)。私は Java を使用していますが、ほとんどの言語は似ていると思います。

public abstract class Marker {...}
public class Template extends Marker {...}
public class Regex extends Marker {...}

私は現在、次の傾向があります。

public abstract class Marker {...}
public class TemplateMarker extends Marker {...}
public class RegexMarker extends Marker {...}

それよりも

public abstract class AbstractMarker {...}
public class Template extends AbstractMarker {...}
public class Regex extends AbstractMarker {...}

また

public abstract class AbstractMarker {...}
public class TemplateMarker extends AbstractMarker {...}
public class RegexMarker extends AbstractMarker {...}

Marker個人的には、これは抽象的な機能概念であり、サブクラスは具体的な実装であることを覚えています。

于 2009-09-15T13:15:06.453 に答える