В коде постоянно повторяется последовательность действий:

1. Запрос создания фабрикой нового объекта
2. Добавление созданного объекта в репозитори

dim NewObject = Factory.CreateObject
Repository.Add(NewObject)

'дальше модифицируются свойства объекта

Разумно ли объединить эти действия в отдельный метод? и где разместить этот метод? Например,

Вариант 1:

Добавить в репозитори метод создания объекта, который запрашивает новый объект в фабрике и добавляет созданный объект в репозитори

'репозитори использует фабрику для создания объекта
dim NewObject = Repository.CreateObject

Вариант 2:

Перенести добавление созданного объекта в репозитори внутрь фабрики.

'фабрика возвращает новый объект уже добавленный в репозитори
dim NewObject = Factory.CreateObject

Здравствуйте, Strategy, Вы писали:

S>В коде постоянно повторяется последовательность действий:

S>1. Запрос создания фабрикой нового объекта
S>2. Добавление созданного объекта в репозитори

Вариант 3:
Выкинут нафиг фабрики и репозитории.

G>Вариант 3:
G>Выкинут нафиг фабрики и репозитории.

Хм, интересно, а как это?
Можешь вкратце показать, как можно сделать без фабрики и репозитори, чтобы можно было менять метод создания объекта?

Здравствуйте, Strategy, Вы писали:

G>>Вариант 3:
G>>Выкинут нафиг фабрики и репозитории.

S>Хм, интересно, а как это?
Оператор new

S>Можешь вкратце показать, как можно сделать без фабрики и репозитори, чтобы можно было менять метод создания объекта?

А зачем тебе что-то менять?

Здравствуйте, Strategy, Вы писали:

1. Если вам реально нужно отвязать логику хранения и логику создания от прикладной логики (и друг от друга), то можно убрать лишний вызов:

dim NewObject = Repository.AddNewObjectFromFactory(Factory)

или

dim NewObject = Factory.AddNewObjectToRepository(Repository)

2. Если у вас фабрика и репозиторий жестко связаны между собой, то их можно склеить и не заморачиваться.
3. А лучше всего — выкинуть нафиг фабрики и репозитории, и Писать Код.

Здравствуйте, Strategy, Вы писали:

S>Вариант 1:
S>Добавить в репозитори метод создания объекта, который запрашивает новый объект в фабрике и добавляет созданный объект в репозитори
S>

S>'репозитори использует фабрику для создания объекта
S>dim NewObject = Repository.CreateObject
S>

S>Вариант 2:
S>Перенести добавление созданного объекта в репозитори внутрь фабрики.
S>

S>'фабрика возвращает новый объект уже добавленный в репозитори
S>dim NewObject = Factory.CreateObject
S>

Если четко обозначить ответственности, то:
— Фабрика создаёт представление объекта в памяти
— Репозиторий принимает объект для управления его жизненным циклом, и, что важно,
проверяет валидность его состояния при добавлении и обновлении;
Вариант 2 выглядит нелогичным из-за того, что
(1) добавление объекта в Репозиторий внутри Фабрики — это, фактически, сайд-эффект;
(2) Фабрика вынуждена знать о Репозитории, хотя создание объекта может и не предполагать
помещение его в Репозиторий;
(3) операция может завершиться исключением из-за невалидного состояния объекта;

Насколько вообще важна Фабрика в данном случае? Если она просто создаёт пустой объект,
то с этим и Репозиторий вполне справится внутри, например, Repository.CreateObject.

Вообще, этот сценарий не совсем очевиден:
S>1. Запрос создания фабрикой нового объекта
S>2. Добавление созданного объекта в репозитори

S>

S>dim NewObject = Factory.CreateObject
S>Repository.Add(NewObject)

S>'дальше модифицируются свойства объекта
S>

Означает ли это, что добавляется всегда пустой объект, затем ему задаются свойства?
По идее, правильный порядок действий таков:
— создать пустой объект
— задать свойства
— отдать в Репозиторий
Такой подход позволяет сделать Репозиторий ответственным за валидацию
как в случае добавления, так и в случае обновления.

BB>Насколько вообще важна Фабрика в данном случае? Если она просто создаёт пустой объект,
BB>то с этим и Репозиторий вполне справится внутри, например, Repository.CreateObject.

Фабрика отвечает:
1. за выбора фактического класса объекта для создания объекта
2. за выбор и вызов нужного конструктора выбранного класса объекта с определенными параметрами
3. за уведомление подписчиков о создании нового объекта

То есть фабрика — это совокупность параметров, достаточная для того, чтобы создать новый объект вызовом одного непараметризованного метода CreateObject.

BB>Означает ли это, что добавляется всегда пустой объект, затем ему задаются свойства?
BB>По идее, правильный порядок действий таков:
BB>- создать пустой объект
BB>- задать свойства
BB>- отдать в Репозиторий
BB>Такой подход позволяет сделать Репозиторий ответственным за валидацию
BB>как в случае добавления, так и в случае обновления.

Такая последовательность действий тоже возможна. Но в любом случае фабрика создает не совсем пустой объект. И в любом случае допускается, что клиент может подать в репозитори объект с некорректным состоянием, но должен исправить это состояние до завершения изменений.

Здравствуйте, Strategy, Вы писали:

BB>>Насколько вообще важна Фабрика в данном случае? Если она просто создаёт пустой объект,
BB>>то с этим и Репозиторий вполне справится внутри, например, Repository.CreateObject.

S>Фабрика отвечает:
S>1. за выбора фактического класса объекта для создания объекта
S>2. за выбор и вызов нужного конструктора выбранного класса объекта с определенными параметрами
S>3. за уведомление подписчиков о создании нового объекта

Фабрика уведомляет подписчиков? Не Репозиторий? Ему, по идее, видней, когда объект готов к использованию.

Здравствуйте, Strategy, Вы писали:


S>Фабрика отвечает:
S>1. за выбора фактического класса объекта для создания объекта
S>2. за выбор и вызов нужного конструктора выбранного класса объекта с определенными параметрами

И сколько сейчас классов и разных конструкторов? Откуда уверенность в том, что будет больше?

S>3. за уведомление подписчиков о создании нового объекта

Вот это вообще странно.

S>То есть фабрика — это совокупность параметров, достаточная для того, чтобы создать новый объект вызовом одного непараметризованного метода CreateObject.

И в разных местах кода это будет создание разных объектов? Или вы боитесь явных параметров?
По мне так, наоборот такие непараметризованные вызовы — адовый геморрой при разборе кода. И отладку ни разу не упрощает.


S>Такая последовательность действий тоже возможна. Но в любом случае фабрика создает не совсем пустой объект. И в любом случае допускается, что клиент может подать в репозитори объект с некорректным состоянием, но должен исправить это состояние до завершения изменений.

Чем проще и понятнее последовательность действий, тем проще это поддерживать. Все неявные вызовы и подстановки в неожиданных местах — лишняя головная боль для тех, кто код попытается прочитать или модифицировать. Наслоение таких вещей — источник грандиозных багов.

Здравствуйте, Strategy, Вы писали:

Если в думать в отрыве от БД, то репозиторий это просто шаблон "Information Expert" из шаблонов GRASP, тогда он вполне может содержать методы для создания объектов с нужными параметрами как и методы выборки объектов по параметрам.