在类名中使用"Base"

在作为继承树底部的类名中使用"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
{
}

Grzenio.. 9

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

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

因为你引用的重构原因,我支持"不".

一个类应该以它逻辑上代表的名称命名,除了Object类之外什么都不是真正的 Base.形而上学ftw :)

re:选项B,没有什么令人困惑的

namespace MySpecificNamespace
{
  MyClass: MyCommonNamespace.MyClass
  {
  }
}

"你所有的BaseClass都属于我们."

我支持一个明确的否定,只有一个例外.如果您正在编写应用程序来管理军事设施或棒球场,那就去吧.

与其父类具有相同名称的类会让我感到不安.在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可以告诉你什么类型的对象,在奇怪的情况下,如果它是一个接口或类,它甚至是重要的.