Question

在继承树底部的类名中使用“Base”这个词是否可以接受？

我总是发现这有点像警察，只是想知道是否有人同意我。

例如，如果我将MyClassA和MyClassB中的某些元素重构为公共基类，我很想创建一个从中继承的MyBaseClass。

但是如果我需要重构MyBaseClass会发生什么？ MyBaseBaseClass？现在这太傻了。

我知道Rocky Lhotka不介意他的CSLA框架，但我总是对编程中的'definites'感到不安。

思想？

让我澄清为什么我甚至担心这个。

我有两个名称空间 - MySpecificNamespace和MyCommonNamespace。 MyNamespace使用MyCommonNamespace，正如您所料。

现在，我希望尽可能最大限度地使用命名空间来描述问题的上下文，并避免将上下文添加到类名中。因此，例如，考虑我在MyNamespace中有一个类，它来自MyCommonNamespace中的一个。

选项A

我可以调用此

MySpecificClass: MyClass
{
}

但后来我在名称中添加了“特定”（上下文） - 这是多余的，因为它已经在MySpecificNamespace中。

选项B

MyClass: MyCommonNamespace.MyClass
{
}

你可以看到我们如何在这里感到困惑，对吗？

选项C

我觉得这个很可疑：

MyClass: MyBaseClass
{
}

Answer 1

我倾向于在基类的名称中添加一个Base后缀，只要它从技术角度来看（共享一些代码），并且它本身并不真正构成任何可用的类（因此所有这些类都是抽象）。这些情况非常罕见，应该像Helper类一样避免使用。

Answer 2

对于你所引用的重构原因，我支持“不”。

一个类应该以它逻辑上代表的名称命名，除了Object类之外什么都不是真的 Base。形而上学：）

re：选项B，没有什么令人困惑的

namespace MySpecificNamespace
{
  MyClass: MyCommonNamespace.MyClass
  {
  }
}

Answer 3

与其父类具有相同名称的类会让我感到厌烦。在Java中，java.sql.Date扩展了java.util.Date。这非常烦人，因为您必须指定要导入的确切类，或者完全指定类名（包括包/命名空间）。

我个人更喜欢按原样命名;如果Base或Abstract类仅存在以提供某事物的部分实现，并且不代表该事物的接口，则通常可以在其名称中添加Abstract或Base一词。但是，如果该类也代表了接口，那么您应该在它所做的之后命名它。

例如，在Java中，我们有Connection接口（用于DB连接）。它叫做Connection，而不是IConnection。你这样使用它：

Connection con = getConnectionFromSomewhere();

如果要创建JDBC驱动程序并需要实现连接，则可以使用ConnectionBase或AbstractConnection，它是特定Connection的实现细节的下层。你可能有

abstract class AbstractConnection implements Connection

class OracleConnection extends AbstractConnection

或类似的东西。但是，代码的客户端从不会看到AbstractConnection，也看不到OracleConnection，他们只看到Connection。

因此，一般来说，通常有用的类应该以它们代表/做的命名，而代码维护/组织的帮助类可以按照它们的名称命名。

* ps我讨厌用I命名接口。人们用C命名所有类吗？这是2009年！你的IDE可以告诉你什么类型的对象，在奇怪的情况下，如果它是一个接口或类，它甚至是重要的。

Answer 4

“你所有的BaseClass都属于我们。”

我支持一个明确的否定，只有一个例外。如果您正在编写应用程序来管理军事设施或棒球场，请选择它。

Answer 5

我认为值得维基这个问题。

FWIW，我同意。我通常会尝试为我的基类找到一个更“通用”的术语。因此，如果我有一个“客户”类并需要为它引入一个新的基类，我会选择“联系”或其他东西，而不是“CustomerBase”。

Answer 6

我也会建议不，但不是一成不变的......

遵循OO口头禅，您的命名系统应该最好地代表代码应该封装的底层对象。应该没有“元语言”，与那里选择的编程语言的实际语法构成有关。

也就是说，如果你的对象真的是抽象的，你真的不会很快看到它的变化，那么有一种观点认为添加'Base'有助于提高一般可读性。

与大多数事情一样，没有一揽子正确和错误的答案 - 这取决于代码库的整体布局，这个特定代码应该代表的内容以及您拥有的内部风格。试着保持一致。

基地是否在其他地方使用？

Answer 7

我也支持no camp ...今天在那里放置一个Base，在6个月内，当你不在的时候，有人会在你的代码库中敲打一个MyDerivedClass类。

Answer 8

“抽象”前缀可能吗？

Answer 9

在Java中，我倾向于在抽象类FooBase中提供接口Foo的基本实现。我认为这是完全正常的，并且使得与界面的连接非常清晰和有规律。

如果没有接口，我会调用抽象基类Foo。

Answer 10

我同意，AbstractFoo是一个不错的解决方案。我尝试选择不需要额外形容词的名字。我会回避使用Base。

Answer 11

我认为在可能的情况下应该避免使用实际描述它的标识符！

这个问题很难回答，因为它是抽象的。例如，我可能会考虑调用MyClassA和MyClassB的基础，“MyClass”。

Answer 12

我通常使用IFoo作为接口，使用AbstractFoo作为骨架实现，这是.NET和Java约定的混合。

Answer 13

从代码易读性的角度来看，我也要说“不”。继承是一种(a, b, , d, e, , , ) ( , , c, , e, , g, ) (a, , c, , , f, , h)关系，因此is a 是 Cat（不是Animal）。另外，如果您创建BaseAnimal的集合，则可以说Animal比List[Animal]更容易阅读和理解。{p>

最后，如果要保留DRY，则在将函数声明为抽象时，就不再需要此类前缀。

Answer 14

似乎任何有原则的答案都将最终不是...但是，逗号，当我查看我不是特别熟悉的代码时，这在python中经常发生（其中源代码有时是仅可靠的文档），当类中包含Base时，我发现它真的很有帮助。 Python与其他OO语言不同，在其他OO语言中，类是使用“抽象”或“接口”说明符定义的。为了进行命名，我想问自己“如果我以前从未看过这段代码，哪种方式会使我更容易理解该代码？” （然后，根据我的懒惰程度，我相应地命名它。）

在类名中使用“Base”

14 个答案: