在实例化时启动很多属性是一种好习惯吗？

Question

我有一个具有很多属性的 Cart 类：

public class Cart
{
    public Customer Customer { get; set; }
    public Products Products { get; set; }
    public Payments Payments { get; set; }
    public DateTime TimeOfArrival { get; set; }
    //...and so on
}

每当我想实例化一个新的Cart 时，我都需要启动这些属性。其中一些是已知的（例如客户），另一些是未知的（例如产品和付款）。所以当我实例化一张新票时，这就是我最终做的事情：

Cart Cart = new Cart
                    {
                        // for know properties:
                        Customer = currentCustomer,
                        TimeOfArrival = DateTime.Now,

                        // for properties that are going to be filled later:
                        Products = new List<Product>(),
                        Payments = new List<Payment>(),

                        // ...and so on
                    };

这个解决方案显然有效，但在实例化时似乎非常庞大，而且在启动器中完成了很多工作，我认为这是一件坏事。

我这样做是对的还是在实例化时启动了很多属性不是一个好习惯？如果是这样，我应该怎么做？

提前致谢

Answer 1

是的，还有改进的余地。但要小心，很多取决于要求，基本上他们应该在很多情况下领先。这是一个品味问题。有些人比其他人更纯粹。

这取决于您的项目：它有多重要？它是一个副项目还是你的核心业务？

而且，是的，还有改进的余地；总是有......现在，明年，每次评论......等等。只是说：没有完美的设计。

---

现在，我强烈的偏见：）

您的设置代表了领域驱动设计中的典型案例。稍后我会发送链接。

通常，在域驱动设计中，您会尝试确定特定的业务功能/概念，并将其包装在最好是最具描述性的对象中。基本上，您的购物车是在正确的轨道上。

但是，购物车中似乎只有一点点领域知识。

特别是嵌套的复杂类型可能表明您正在跨越某些域边界。

例如：customer；它位于购物车内。客户可能又包含一个地址。 ...等等。

很明显，一个人的地址与购物车本身无关。

还有；支付。我不认为它通常绑定到购物车，可能更多绑定到订单。

关于产品；一个简短的描述和一个指向实际产品的链接就足够了。旁边当然是明显的价格和数量。

对于购物车，您可能需要考虑仅存储客户 ID，并在需要其他数据时获取客户。

总之，这是一个一般性的主题。最好的建议是；不要试图涉及太多复杂的类型，只在模型中放入只对特定“事物”有意义的事物

Answer 2

使用构造函数：

public class Cart
{
    // shorthand constructor, only 1 setting, else use a normal function style constructor
    public Cart (Customer cust) => Customer = cust;

    public Customer Customer { get; set; }
    public Products Products { get; set; } = new List<Product>();
    public Payments Payments { get; set; } = new List<Payment>();
    public DateTime TimeOfArrival { get; set; } = DateTime.Now;
    //...and so on
}

var cart = new Cart( my_customer_instance );  // all thats needs to be done

如果您只为自己的业务开发一些东西，这比Lazy<...> 方法更容易。如果您有昂贵的东西要创建，而这些东西可能根本不需要，也可能根本不需要。空列表不会花费您太多 - 如果您真的担心，您甚至可以使用 0 个元素创建它们（如果您“喂”它们，它们会增加内部缓冲区）。

最大的优势是您不必关心如果您需要 new Cart(customer) 该怎么做 - 该类自己处理初始化。

Answer 3

如果您担心预先初始化属性的成本（在这种情况下，这看起来不成问题），那么您可以使用Lazy<T> 在需要时方便地实例化属性。

例如

private Lazy<List<Product>> products;
constructor() {
   products = new Lazy<List<Product>>(()=>new List<Product>());
} 
public List<Product> Products => products.Value;

对于像列表这样的东西，这很愚蠢，但对于更昂贵的初始化，Lazy<T> 可能很有用。