代码之家 › 专栏 › 技术社区 › Alexander Torstling

提供接口完整实现的类的命名,但其设计为扩展/用作mixin

naming-conventions language-agnostic

2

Alexander Torstling · 技术社区 · 15 年前

如果用很多方法编写接口,比如 IPerson ,您期望它有很多不同的实现,提供一个抽象类是很常见的做法。 AbstractPerson 它实现了大部分功能。

正常地 抽象人物 是抽象的,因为您通常会保留一些未实现的关键功能。在这种情况下,命名是有意义的。

但是,如果已经实现了所有的iperson,但仍然需要子类,那么什么是好的命名约定呢?也许 PersonMixin , PersonHelper , GenericPerson 或者简单地 Person ?我想 人 有点模糊,因为它没有清楚地显示出预期的用途。

3 回复 | 直到 15 年前

1

3

Scott Dorman 15 年前

虽然这是来自 Framework Design Guidelines (对于.NET),我认为它同样适用于任何语言。建议如下:

如果类要在公共API中使用,请避免使用基后缀命名基类。 如果库将基类公开为返回类型或参数类型,则它不应具有基后缀。

一般来说,如果该类是公共的(甚至是私有的,尽管在这种情况下风险较小),并且您将其命名为 PersonBase 这意味着它是一个基类。如果将来某个时候类层次结构被重构,并且 资料管理 不再是要重命名的基类 资料管理 其他一些最有可能导致任何消费代码发生破坏性变化的东西。

我只想说出班级的名字 Person 并且让任何派生类使用更具体的名称。我想 人 非常清楚并表明它是作为一般(非特定)人使用的。

2

3

Steven Sudit 15 年前

我想 Person 很好。关键是你可以将它专门用于特定类型的人,但它仍然是一个人。

3

2

Douglas 15 年前

~~如果它能按原样使用,我会坚持 Person . 如果没有,我会将其抽象化(即使它没有抽象成员),并称之为 PersonBase .~~