Если шаблон фабрики вынуждает вас использовать конструкторы по умолчанию, то как следует проектировать интерфейс класса, требующий параметризованных конструкторов?

Question

У меня есть набор DAO ( Объекты доступа к данным ), которые необходимо извлечь из DAOFactory (используя шаблон фабричного метода).

Теперь у нас есть случай, когда DAOsвсегда должны быть инициализированы с параметрами, например: (с параметрами String)

MyDataDAO myDAO = new myDAO("myProject", "myProjectWallName");

Теперь, имея кучу DAO, мы должны провести рефакторинг (используя фабричный шаблон), и вотконфликтующие принуждают :

1. Если мы реорганизуем наши DAO, чтобы НЕ использовать аргументы по умолчанию (вероятно, хорошо), мы можем получить сеттеры / получатели для обязательных членов, которые ДОЛЖНЫ бытьинициализируется.Подразумевает, вероятно, нулевые проверки / утверждения, замусоренные повсюду (плохо IMO)
2. Другой способ - заставить каждый метод DAO передавать соответствующие обязательные аргументы вместе с тем, что у них уже есть (слишком много данных / длинный параметр)список - вероятно, плохо, но, возможно, единственный выбор?)
3. Используйте Spring!Что ж, мы делаем для некоторых DAO, не имеющих состояния, которые действительно не требуют настройки по умолчанию.Но я не думаю, что Spring действительно поддерживает инициализацию параметров конструктора во время выполнения, поскольку он создает и кэширует объекты при запуске.Итак, вернемся к исходной точке (Spring может поддержать это, но я действительно пока не смог найти что-нибудь об этом. Справка? :)

Так как же нужно разрабатывать «хорошо»?интерфейс для классов, которые должны быть созданы с использованием фабрики, т. е. передовой опыт, которому следует следовать в этом отношении.До этого момента я всегда сталкивался с непараметрическим конструктором, где я действительно чувствую необходимость / причину наличия параметров.Лично я чувствую, что плохо ОО иметь только конструктор по умолчанию и устанавливать все через сеттеры-геттеры, побеждая самих конструкторов, которые нужно решать!

Смущенный ...

Answer 1

Я не вижу причин, по которым фабрика всегда должна использовать конструктор по умолчанию. create -метод полностью свободен для принятия аргументов, которые он передает конструктору, который он вызывает. Кроме того, фабрика может хранить аргументы в переменных-членах. Таким образом, вы можете убедиться, что все объекты, созданные с помощью этой фабрики, созданы с одинаковыми параметрами.

Answer 2

Шаблон Factory используется для создания объекта и проверки его правильности при возвращении вызывающей стороне.

Если у вашего объекта есть требуемые свойства, возвращая его с конструктором по умолчанию, а не с инициализированными свойствами, вы не получите правильное состояние для вызывающей стороны. В таком случае, везде, где вы вызываете фабрику, код должен также знать, какие поля являются обязательными, и инициализировать их после вызова фабрики. Таким образом, вы дублируете код инициализации (и знания), и вся идея фабричного шаблона состоит в том, чтобы удалить такое дублирование.

Таким образом, обязательные поля должны быть переданы как параметры фабричному методу.