Как называется этот шаблон фабричного типа и как его представить в UML?

Question

Пример: у меня есть несколько типов, например Колесо, Тормоз, Двигатель, Сцепление, Автобокс, Ручной ящик, Электрическое окно, Задний датчик парковки, Сиденья с подогревом. Все они наследуют интерфейс маркера ICarPart (может быть атрибутом (аннотация Java), но на данном этапе это не имеет значения).

Затем я пишу свой класс автомобилей, который может представлять все типы автомобилей, например,

class Car
{
    string Name;
    DateTime creationDate;
    string ID;

    IList<ICarPart> parts;
}

Я тогда пишу фабрику по созданию автомобилей. Фабрика может ссылаться на некоторый XML, который представляет собой список ингредиентов для разных типов автомобилей. Например. (и, пожалуйста, игнорируйте формат, это только для иллюстрации):

<ExpensiveCar>
  <Name>Expensive Car</Name>
  <Parts>
    <HeatedSeats/>
    <Wheel count=4/>
    <RearParkingSensor/>
    <ElectricWindow type=FrontAndBack/>
  </Parts>
</ExpensiveCar>

Фабрика проанализирует этот список ингредиентов и создаст объект автомобиля. Новые типы автомобилей будут доступны для системы при условии кодирования деталей и написания списка ингредиентов в формате XML.

Вопросы:

1. Как называется эта модель? Или это просто несколько паттернов?
2. Является ли что-нибудь из этого антипаттерном?
3. Как мне представить это в UML? Я мог бы сделать диаграмму классов для частей и для базового класса автомобиля. Как бы я показал экземпляры этого класса, которые в настоящее время поддерживаются, и части, которые у них есть?

Спасибо заранее. Если что-то из этого неясно, пожалуйста, прокомментируйте, и я внесу изменения в / udpate / и предоставлю более подробную информацию.

Answer 1

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

Answer 2

1. Как называется эта модель? Или это просто несколько паттернов?

Шаблон описан как шаблон Builder . Шаблон строителя строит сложные объекты из набора более простых частей. Иногда объекты, построенные по шаблону построителя, являются составными объектами (но не обязательно в случае вопроса).

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

2. Является ли что-нибудь из этого антипаттерном?

нет

Нет

3. Как мне представить это в UML?

Возможно, по:

1. Определите диаграмму классов, показывающую детали как классы, а также класс Car. Покажите, что каждый класс детали реализует интерфейс ICarPart.
2. Возможно, на отдельной (но связанной) диаграмме классов покажите именованные экземпляры класса автомобиля, используя нотацию экземпляра UML. Представление класса экземпляра позволяет вам указать значения, которые атрибуты имеют в этом классе, например,

------------------------------------------
|ExpensiveCar : Car                      |
------------------------------------------
|parts = {                               |  
|HeatedSeats,                            |
|Wheel (count = 4),                      |
|RearParkingSensor,                      |
|ElectricWindows (type = FrontAndBack) } |
------------------------------------------

Обратите внимание, что, поскольку это экземпляр, текст «Дорогой автомобиль: Автомобиль» должен быть подчеркнут, но ТАК не позволяет мне это делать.

Обозначение, которое я использовал здесь для инициализации массива с частями, не очень хорошее и, возможно, не лучший подход. Возможно, альтернативой было бы добавить примечание UML, содержащее фактический XML. Важно то, что клиент может видеть, что делает дорогой автомобиль, и программист может.

Answer 3

Как называется эта модель? Или это просто несколько комбинаций шаблонов?

У вас есть шаблон фабричного метода (создание автомобильных объектов) и старая добрая композиция (создание автомобиля из колеса, сиденья и т. Д.). Последний вариант вариации.