是否应在抽象类中添加“抽象”前缀？[关闭]

假设我有一个名为的抽象类Task。

是否有标准或约定建议我AbstractTask改用它命名？

根据Bloch的Effective Java（条款18），Abstract前缀是在特殊情况下使用的约定。

您可以通过提供抽象骨架实现类与导出的每个非平凡接口一起使用，来结合接口和抽象类的优点。...按照惯例，骨架实现称为AbstractInterface，其中Interface是它们实现的接口的名称。

但是Bloch还指出，SkeletalInterface这个名称是合理的，但结论是

现在，牢固建立了Abstract约定。

正如其他答案所指出的那样，通常没有理由将此命名约定应用于所有抽象类。

没有约定。这一切将帮助开发人员更快更好地编写代码，并帮助他人理解您的代码。

询问将要查看和维护代码的人员。他们宁愿看到什么？什么会使他们更轻松？然后根据他们想要的名称进行命名。

另外，Java编程语言的代码约定：9.命名约定建议不要求：

类名应为名词，大小写混合，每个内部单词的首字母应大写。尝试使您的类名称保持简单和描述性。请使用整个单词，避免使用首字母缩写词和缩写（除非缩写比长格式（如URL或HTML）使用得更广泛）。

不会。Int​​ellisense会简单地告诉我它是否是抽象的，因此您在这里违反了DRY。

这在某种程度上是个人喜好的问题（但是这是不明智的做法），但是大多数人不喜欢以班级的名义看到预选赛的一部分。

无论如何，大多数IDE都将使您轻松获得该信息，因此不必将其放在名称中，并且将其省略会更干净。这让人想起匈牙利人对变量命名的表示法，如今肯定已经被认为是不好的形式。我建议简单地调用它Task。

在.NET中，经常看到使用“ Base”作为后缀来表示抽象基类。对于这是否是Java的普遍做法，我将参考其他答案。

我认为，实体的名称不应传达有关其类型结构的信息，而应传达其语义。因此，如果抽象不是其运行时目标的一部分，则将类定义为“ AbstractSomething”是没有意义的。它是基础抽象类，对于程序员来说是可见的，不需要在名称中反映出来。

但是，如果可以完美地将抽象工厂的实现称为AbstractFactory，因为这确实与类的意图有关。

通常，建议使用命名约定，以帮助传达有关课程目标的最多信息。

同样，请从清除SomethingImpl。我们不在乎它是一个实现而不是基类。如果您的类层次结构是为继承而设计的，那么有人可以从中继承。当然，在它们中添加更多的“ Impl”后缀或其他工件毫无价值。添加“接口”后缀或“ I”前缀也没有任何价值。

考虑：

IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl

相对于：

Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
                                   <-- Ferrari
                                   <-- Trabi

我到目前为止更喜欢后者。

这一点，在某些方面，类似于公然滥用了的匈牙利命名法是后者确定了它的坏名声，人们错误地开始把它解释为要求开发商与变量的类型的指标前缀它们的变量。尽管有时可以使用它（大多数情况是如果您懒于查找类型的定义），但是它几乎没有用。Simonyi最初使用匈牙利符号法的想法是将其用作助记符，以提醒开发人员该实体的功能，而不是其类型。

一个好的经验法则是不要在语法中明显包含名称的属性。由于在Java中，您需要使用适当命名的abstract关键字标记一个抽象类，因此我不会在名称中包括它。例如，在C ++中，情况不是很清楚，但是至少当错误使用抽象类时，编译器会告诉您。再次使用Python之类的方法，明确地这样命名一个抽象类并不是一个坏主意。

该规则的常见例外是名称不明确时。如果由于某种原因存在一个具体的子类Task（在其他示例中，这可能更明智，但无论如何），那么请确保使用AbstractTask。

protected abstract SomeClass { }

这告诉我这是一个Abstract类。添加前缀是一种重言式和反模式，在大多数情况下并不适用，例如，请参见该链接中提到package local的例外。

在大多数情况下，Abstract类不应成为面向公众的API的一部分，如果确实存在，则应该有充分的理由，并且有充分的理由应该提供一个明显的好名字，而不是AbstractSomeClass。

在大多数情况下，如果您无法提供更具描述性的名称，则可能需要重新设计。

我的五分钱，可能您将拥有该抽象类的实现，它们的名称将为“ SomeSpecificTask”，“ TaskWithBubbles”，“ StrangeTask”等。因此，抽象的“ Task”与它们之间不会发生名称冲突。

另外，“抽象”一词与语言语法有关，而不与业务领域实体有关，因此我宁愿不要将其用作名称的一部分。

另一方面，在这里的一个答案中，我看到了J.Bloch Effective Java的摘录，该摘录说使用“抽象”作为名称的一部分是一种公认​​的做法。可能是这样。但是无论如何，在正式的Java代码约定中，都没有关于此的任何内容。

如果您在团队中工作，则整个团队必须决定是否应在抽象类之前添加“ Abstract”作为前缀。

如果您自己工作，那完全取决于您，而不是我或此站点上的任何其他人。

我不是Java开发人员（INAJD？），也不知道这些事情的标准命名法，但是我认为Task听起来很抽象，可以按原样独立。

如果要编写抽象AbstractSyntaxTree类怎么办？还是只是一个摘要SyntaxTree？

这不是传统的做法，很容易使人困惑。

我已经做到了。我确实在名为AbstractOperation的抽象类中添加了“ Abstract”作为前缀。我这样做的原因是，还有另一个包含非抽象类的软件包，名为Operation，它可以帮助我的团队和后来接手的程序员避免两者之间的混淆。