Мое понимание фабрики заключается в том, что она инкапсулирует создание конкретных классов, которые все наследуют общий абстрактный класс или интерфейс. Это позволяет отделить клиент от процесса определения, какой конкретный класс создать, что, в свою очередь, означает, что вы можете добавлять или удалять конкретные классы из вашей программы без необходимости изменения кода клиента. Возможно, вам придется изменить фабрику, но фабрика «построена специально» и на самом деле есть только одна причина для изменения - конкретный класс был добавлен / удален.
Я создал несколько классов, которые на самом деле инкапсулируют создание объектов, но по другой причине: объекты трудно создать. На данный момент я называю эти классы "фабриками", но я обеспокоен тем, что это может быть неправильным и может привести в замешательство других программистов, которые могут посмотреть на мой код. Мои "фабричные" классы не решают, какой конкретный класс создавать, они гарантируют, что ряд объектов будет создан в правильном порядке и что правильные классы будут переданы в правильные конструкторы, когда я вызову new().
Например, для проекта MVVM, над которым я работаю, я написал класс, чтобы гарантировать, что мой SetupView будет создан правильно. Это выглядит примерно так:
public class SetupViewFactory
{
public SetupView CreateView(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities)
{
var setupViewModel = new SetupViewModel(databaseModel, settingsModel, viewUtilities);
var setupView = new SetupView();
setupView.DataContext = setupViewModel;
return setupView;
}
}
Смешно ли называть это «фабрикой»? Он не выбирает среди нескольких возможных конкретных классов, и его возвращаемый тип не является интерфейсом или абстрактным типом, но он инкапсулирует создание объекта.
Если это не "фабрика", что это?
Редактировать
Некоторые люди предположили, что это на самом деле Образец Строителя.
Определение шаблона Builder из dofactory выглядит следующим образом:
Отделите построение сложного объекта от его представления, чтобы один и тот же процесс построения мог создавать разные представления.
Это тоже немного натянуто. Что меня беспокоит, так это «разные представления». Моя цель не состоит в том, чтобы абстрагировать процесс построения View (не то, что это не достойная цель). Я просто пытаюсь поместить логику для создания определенного представления в одном месте, чтобы, если какой-либо из компонентов или процесс создания этого представления изменился, мне нужно было только изменить этот один класс. Кажется, что шаблон конструктора действительно говорит: «Давайте создадим общий процесс создания представлений, тогда вы сможете следовать тому же базовому процессу для любого создаваемого представления». Хорошо, но это не то, что я здесь делаю.
Редактировать 2
Я только что нашел интересный пример в статье в Википедии об инъекции зависимостей .
В разделе «Вводимые вручную зависимости» он содержит следующий класс:
public class CarFactory {
public static Car buildCar() {
return new Car(new SimpleEngine());
}
}
Это почти точно использование, которое у меня есть (и, нет, я не писал вики-статью:)).
Интересно, что этот комментарий следует за этим кодом:
В приведенном выше коде завод берет на себя ответственность за сборку автомобиля и впрыскивает двигатель в автомобиль. Это освобождает автомобиль от знания того, как создать двигатель, хотя теперь CarFactory должен знать о конструкции двигателя. Можно создать EngineFactory, но это просто создает зависимости между фабриками. Таким образом, проблема остается, но по крайней мере была перенесена на фабрики или строителя объектов. [мой акцент]
Итак, это говорит мне о том, что, по крайней мере, я не единственный, кто задумывается о создании класса, чтобы помочь вводить вещи в другой класс, и я не единственный, кто пытался назвать этот класс фабрикой.