Это сбивает с толку для вызова этого класса “фабрикой”?
У меня нет большого опыта с BSPs, но я могу сказать, что необходимо пойти с деревьями октантов по деревьям квадрантов, когда Вы сцена, которую Вы представляете, высоки. Таким образом, высота является больше чем половиной ширины и глубины - мало эмпирического правила. Обычно деревья октантов не принесут огромную стоимость по деревьям квадрантов, и у них есть потенциал для ускорения вещей достойный бит. YMMV.
9 ответов
Для меня это не сильно отличается от конструктора для экземпляра SetupView. Возможно, в вашем примере было исключено слишком много контекста кода, но я не понимаю, почему то, что у вас есть, нельзя просто записать как конструктор, а аргументы передаются конструктору как аргументы.
Судя строго по Шаблоны GoF, я думаю, он не попадает в цель в Factory по двум причинам:
- не существует семейства связанных / зависимых объектов
- конкретный класс действительно указан
Что касается Builder, я думаю, что он отсутствует в аспекте вариативности продуктов.
Когда я преподаю курсы по шаблонам дизайна, я говорю студентам, чтобы они смотрели не только на назначение шаблона, пытаясь определить «наилучшее соответствие», но, скорее, смотреть на применимость и структуру / участников. Намерение может помочь вам исключить ситуацию, но применимость и структура / участники - это то, что вам поможет.
Мне кажется, что у вас больше паттерна Builder , чем паттерна Factory .
Я думаю, это «Завод». Когда я смотрю на объявление класса, я рад видеть, что это «Фабрика», и более того, это «Фабрика» объектов SetupView. Итак, я знаю, что эта Factory предоставит мне конкретные и правильно построенные экземпляры SetupView.
«Фабрика» - это все, что инкапсулирует создание новых объектов. Почему или что это за объекты, не имеет значения. Чаще всего используется так, как вы описываете, но другие цели, не соответствующие этому описанию, также могут называться Factory. Фундаментальная идея (которую, я думаю, не мог бы неверно истолковать любой, кроме самых придирчивых и придирчивых разработчиков), заключается в том, что эта штука создает для вас новые объекты ...
Почему не два класса с простыми конструкторами?
public class SetupViewModel {
public SetupViewModel(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities) {
this.DatabaseModel = databaseModel;
this.SettingsModel = settingsModel;
this.ViewUtilities = viewUtilities;
}
}
и
public class SetupView {
public SetupView(SetupViewModel model) {
this.DataContext = model;
}
}
Таким образом, оба класса ясно заявляют, что им нужно построить.
Я бы согласился с Джейсоном над. Для меня это больше похоже на шаблон Builder, но если вы превратите SetupView в интерфейс, он будет больше похож на шаблон Factory. Ключ к паттерну Factory - позволить паттерну Factory сделать всю работу по принятию решения, что возвращать из вызова функции. Так что я бы подумал, что вам понадобится переключатель, выбирающий между различными вариантами с учетом входных параметров.
Мне это кажется немного странным. Это не абстрактная фабрика, но и не совсем подходит для паттерна Строитель. Для меня было бы наиболее разумно использовать вместо SetupViewFactory метод CreateView, я бы переместил этот метод в класс SetupView и сделал его статическим. Итак, у вас будет ...
public class SetupView
{
public static SetupView CreateView(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities)
{
var setupViewModel = new SetupViewModel(databaseModel, settingsModel, viewUtilities);
var setupView = new SetupView();
setupView.DataContext = setupViewModel;
return setupView;
}
}
Теперь у вас есть так называемая статическая фабрика или фабричный метод. Вы можете сделать еще один шаг и приватизировать конструкторы SetupView, чтобы единственный способ получить экземпляр SetupView - это вызвать фабричный метод.
В ответ на комментарий OP:
Если существует такая необходимость в разделении Я бы не стал создавать SetupViewModel где-либо в этой части кода. Вместо этого просто передайте SetupViewModel, который вы хотите связать с вашим SetupView, вместо составляющих свойств, которые нужно передать конструктору SetupViewModel. Таким образом, код становится ...
public class SetupView
{
public static SetupView CreateView(SetupViewModel model)
{
var setupView = new SetupView(); { DataContext = model };
return setupView;
}
}