命名属性对象的最佳实践是什么？

Question

例如,这是一个好习惯吗？

private SalesOrder salesOrder;

public SalesOrder SalesOrder
{
    get { return salesOrder; }
    set { salesOrder = value; }
}

或者我应该总是使用Object或BusinessObject附加object属性来区分属性类型和属性本身:

public SalesOrder SalesOrderBusinessObject
{
    get { return salesOrder; }
    set { salesOrder = value; }
}

如果属性是网页或对象的一部分,这是否重要？

Answer 1

后者是可怕的。它对具有销售订单的事物进行建模，而销售订单又由对象进行建模，而不是对具有销售订单对象的事物进行建模。

如果您正在为开发人员编写一个工具来帮助他们处理业务对象，那么“BusinessObject”应该只是代码中某些内容的名称。

前者往往是好的。

如果有多个，那就不好了SalesOrder——即使其中一个是“主要”的，也会造成混乱。然而，SalesOrders作为可枚举或SalesOrder对象集合的属性是好的（当英语复数不是单数 + 's' 形式时，使用真正的复数而不是仅添加 s，除非英语复数是这样的情况）与单数相同。

当其他一切都与销售相关时，它就不太好了。例如，这太可怕了：

public class Sale
{
  public SalesOrder SalesOrder{get;set;}
  public SalesReference SalesReference{get;set;}
  public decimal SalesValue{get;set;}
  public string SalesCurrency{get;set;}
}

在这种情况下，我将从每个属性名称中删除“Sales”，但（不一定）从类名称中删除。

然而，这是一个更好的情况：

public class Sale
{
  public SalesOrder SalesOrder{get;set;}
  public StockOrder StockOrder{get;set;}
}

总而言之，处理它的方法是：

1. 这个类所做的事情的最佳名称是什么，它将它与其他类所做的事情区分开来（因此，没有“对象”，“业务对象”，“实体”或类似的名称，除非它确实在给定的环境中特别相关案件）。
2. 该属性所反映的内容的最佳名称是什么，以将其与其他属性区分开来。

如果他们最终在特定情况下给出相同的名称，那么没关系（除非它是嵌套类，当它不明确且非法时）。如果他们最终给出不同的名字，那也很好。