如果有的话，什么时候属性的名称应该包含类的名称？
public class Fruit
{
// choose one
public int Id { get; set; }
public int FruitId get; set; } // redundant or usefully more descriptive?
// choose one
public string Name { get; set; }
public string FruitName { get; set;} // redundant or usefully more descriptive?
public string Fruit { get; set; } // or what about this?
}
对于水果的识别号和名称，您更喜欢哪种约定？为什么？还有其他例子让您有不同的回答吗？
public class Fruit
{
// choose one
public int Id { get; set; }
public int FruitId get; set; } // redundant or usefully more descriptive?
// choose one
public string Name { get; set; }
public string FruitName { get; set;} // redundant or usefully more descriptive?
public string Fruit { get; set; } // or what about this?
}
Which is your preferred convention for the fruit's identification number and name? Why? Are there other examples where you would answer differently?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我知道这些属性都是Fruit的属性，那为什么还要重复这个名字呢？ SomethingId 对我来说是外键属性。
I know that these properties are properties of Fruit, so why repeat this name? SomethingId is foreign key property for me.
一般来说，属性名称应该以它们本身命名，而不是类。
类名可用作类成员的前缀或后缀的五种情况：
所需的属性名称是您语言中的保留字。例如，FruitType 而不是 Type。在大多数情况下，最好将属性命名为其他名称。
类充当工厂并返回其自身的实例。例如，如果 Fruit 有一个名为“GetFruitById”的静态方法，该方法返回一个水果。在这种情况下，您最好为该方法使用一个单独的 FruitFactory 类。
类包含其自身类型的其他内容。在您的示例中，也许，如果 Fruit 是显示水果进化链接的图表，则每个 Fruit 实例都可以在称为“后代水果列表”中包含从其继承的水果列表。有可能，您可以删除“水果”一词，它仍然具有完美的描述性。
域模型中的类名称与常见编程命名约定中使用的单词相匹配。示例：代表文字（现实世界）工厂、列表、字典等的对象，并且还需要在编程中对相关类使用相同的单词。
与数据库的 O/R 映射或成员碰巧具有相同单词的外部接口实现的兼容性。例如，如果 Fruit 实现现有的 IFruitStandProduct 接口。在这种情况下，您不必对命名的一致性负责。
In general, property names should be named after themselves, not the class.
Five situations where the class name may be useful as a prefix or suffix on a member of the class:
The desired property name is a reserved word in your language. For instance, FruitType instead of Type. In most cases it is better to just name the property something else.
Where the class acts as a factory and returns instances of itself. For instance, if Fruit has a static method called "GetFruitById" that returns a fruit. In this case, you'd likely be better off having a separate FruitFactory class for that method.
Where the class contains other things of its own type. In your example, perhaps, if Fruit is a graph showing the evolutionary links of fruit, each Fruit instance could contain a list of fruits descended from it in a called "DescendantFruitList". Chances are, you could drop the word "fruit" and it would still be perfectly descriptive.
The name of the class in your domain model matches a word used in common programming naming conventions. Example: an object representing a literal (real-world) Factory, List, Dictionary, etc. and also needing to use the same words for related classes in your programming.
Compatibility with an O/R mapping to a database or implementation of an external Interface whose members happen to have the same word. For instance, if Fruit implements an existing IFruitStandProduct interface. In this case, you aren't responsible for the coincidence of naming.
在我看来，几乎总是首选
Id和Name，并且不建议冗余地指定类名。但是，一个值得注意的例外是，当Id或Name引用内部标识符或名称，而FruitNumber和FruitName引用时实体的“真实世界标识符”或“显示名称”，并且由于某种原因您不想将其命名为DisplayName。In my opinion, almost always,
IdandNameare preferred and redundantly specifying the class name is not recommended. However, a notable exception is whenIdorNamerefer to an internal identifier or name andFruitNumberandFruitNamerefer to "real world identifier" or "display name" of the entity and for some reason you don't want to name itDisplayName.如果客户已经这样做了，我只会在属性名称中多余地指定类名称。维护无处不在的语言是值得的。
I'd only redundantly specify the class name in a property name if the customer already did. Maintaining ubiquitous language is worth it.
我有时需要在以下情况下（很少）这样做：
I sometimes need to do this (rarely) in a case like:
绝不。
曾经。
严重地。
Never.
Ever.
Seriously.