Является ли наличие большого количества свойств, инициируемых при создании экземпляра, хорошей практикой?

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

Используйте конструктор:

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 2

Да, есть возможности для улучшения.Но будьте осторожны, многое зависит от требований, и в большинстве случаев они должны быть лидерами.И это дело вкуса.Некоторые люди более пуристичны, чем другие.

Это зависит от вашего проекта: насколько это важно?Это сторонний проект или ваш основной бизнес?

И, да, есть возможности для улучшения;всегда есть ... сейчас, в следующем году, в каждом обзоре ... и т. д. Просто говорю: идеального дизайна не существует.

---

Теперь, мое сильно предвзятое мнение:)

Ваша установка представляет собой типичный случай в дизайне, управляемом доменом.Ссылку я отправлю позже.

В общем, в дизайне, управляемом доменом, вы пытаетесь определить конкретную бизнес-функциональность / концепцию и обернуть ее, желательно, наиболее описательный объект.По сути, вы находитесь на правильном пути с вашей корзиной.

Но, похоже, в корзине достаточно много знаний о предметной области.

В частности, вложенные сложные типы могут указывать на то, чтоВы пересекаете границы некоторых доменов.

Например: 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> может быть полезным.