Какие проблемы (если таковые имеются) вы видите при использовании шаблона построителя внутри самой сущности, в отличие от отдельного внутреннего класса? - PullRequest
0 голосов
/ 19 апреля 2019

После поиска в SOF связанных вопросов и нахождения чего-то похожего на PHP, но все же неудовлетворительного, вот мой вопрос.

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

Решение: Создайте класс с конструктором, который принимает все обязательные поля и методы установки для свойств, которые не требуются.Цепочка вызова, чтобы разрешить следующую схему.

var product = new Product("Car")
.withColor(Color.Black)
.withGears(5);

Считаете ли вы это анти-паттерном?Какая польза от этого классического строительного шаблона?Поля только для чтения по-прежнему будут частью аргументов конструктора.

Мой первый пост в SOF, спасибо!

1 Ответ

0 голосов
/ 26 апреля 2019

Если вы разрабатываете Модель предметной области , этот тип решения нарушает разделение проблем и ставит в тупик определение конкретной части Модели ( Продукта * 1006).* в вашем случае).

A Класс продукта представляет собой Продукт из бизнес-области, которую вы моделируете.A Экземпляр класса продукта будет конкретным продуктом, например книгой, радиатором, велосипедом и т. Д. Экземпляр класса Product должен отвечать за содержание и управление его жизненным циклом исохраняя свои инварианты.

Методы, такие как WithColor и WithGears in Product Путать то, что он представляет.

Создание Product это отдельная ответственность.Он может быть передан отдельному Классу , например, ProductFactory или ProductBuilder , или он может быть преобразован в Class самой Конструктор или статический Заводские методы .

На создание продуктов может влиять множество различных факторов.

  • Насколько сложна задача?
  • Сколько существует вариантов продуктов?У вас может быть отдельный фабричный метод для повторного использования при создании продуктов и упрощения его для клиентского кода?

Если создание Экземпляров продукта просто, то вам нужен только конструктор.

Если вы заметили, что существует слишком много разных способов создания Product , вы можете использовать фабрику.Например:

class ProductFactory {

  public Product CrateBook(string title, ....);
  public Product CrateFictionalBook(string title, ....);
  public Product CrateScifiBook(string title, ....);
  public Product CrateMagazine(string title, ....);
}

Эти методы создадут наиболее распространенные типы книг, установив соответствующие параметры, чтобы ваш клиентский код не делал этого.Как следствие, у вас есть более читаемый код, так как имена методов дают вам информацию о том, какой тип книги вы создаете, вместо того, чтобы иметь только конструктор.

Это более показательное намерение и короче:

book = ProductFactory.CreateScifiBook("Killer robots", ...);

чем это:

book = new Product(BookTypes.Scifi, new ISBN(), "Killer robots", ...);

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

В вашем случае у вас есть множество различных комбинаций между свойствами Класса продукта .Создание различных методов, таких как ProductFactory , которые создают книги, приведет к взрыву методов, которые затруднят написание и выполнение кода.Эти методы не являются композитными.В этом случае используйте шаблон компоновщика, чтобы сделать создание продукта более простым и читабельным, как в вашем примере.

Если ваша система не очень сложна, нет необходимости добавлять дополнительные классы.Если ваша система развивается, добавление фабрик и компоновщика может сократить объем печати и сделать код более читабельным и понятным.

Если вы еще не читали Домен-управляемый дизайн от Эрика Эванса Я настоятельно рекомендую его.В нем подробно описывается, как построить доменных моделей .

...