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?
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.