Здравствуйте, Strategy, Вы писали:
S>В коде постоянно повторяется последовательность действий:
S>1. Запрос создания фабрикой нового объекта S>2. Добавление созданного объекта в репозитори
Вариант 3:
Выкинут нафиг фабрики и репозитории.
Re[2]: Взаимодействие фабрики и репозитори объектов
Здравствуйте, Strategy, Вы писали:
G>>Вариант 3: G>>Выкинут нафиг фабрики и репозитории.
S>Хм, интересно, а как это?
Оператор new
S>Можешь вкратце показать, как можно сделать без фабрики и репозитори, чтобы можно было менять метод создания объекта?
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>
Означает ли это, что добавляется всегда пустой объект, затем ему задаются свойства?
По идее, правильный порядок действий таков:
— создать пустой объект
— задать свойства
— отдать в Репозиторий
Такой подход позволяет сделать Репозиторий ответственным за валидацию
как в случае добавления, так и в случае обновления.
El pueblo unido jamás será vencido.
Re[2]: Взаимодействие фабрики и репозитори объектов
BB>Насколько вообще важна Фабрика в данном случае? Если она просто создаёт пустой объект, BB>то с этим и Репозиторий вполне справится внутри, например, Repository.CreateObject.
Фабрика отвечает:
1. за выбора фактического класса объекта для создания объекта
2. за выбор и вызов нужного конструктора выбранного класса объекта с определенными параметрами
3. за уведомление подписчиков о создании нового объекта
То есть фабрика — это совокупность параметров, достаточная для того, чтобы создать новый объект вызовом одного непараметризованного метода CreateObject.
BB>Означает ли это, что добавляется всегда пустой объект, затем ему задаются свойства? BB>По идее, правильный порядок действий таков: BB>- создать пустой объект BB>- задать свойства BB>- отдать в Репозиторий BB>Такой подход позволяет сделать Репозиторий ответственным за валидацию BB>как в случае добавления, так и в случае обновления.
Такая последовательность действий тоже возможна. Но в любом случае фабрика создает не совсем пустой объект. И в любом случае допускается, что клиент может подать в репозитори объект с некорректным состоянием, но должен исправить это состояние до завершения изменений.
Re[3]: Взаимодействие фабрики и репозитори объектов
Здравствуйте, Strategy, Вы писали:
BB>>Насколько вообще важна Фабрика в данном случае? Если она просто создаёт пустой объект, BB>>то с этим и Репозиторий вполне справится внутри, например, Repository.CreateObject.
S>Фабрика отвечает: S>1. за выбора фактического класса объекта для создания объекта S>2. за выбор и вызов нужного конструктора выбранного класса объекта с определенными параметрами S>3. за уведомление подписчиков о создании нового объекта
Фабрика уведомляет подписчиков? Не Репозиторий? Ему, по идее, видней, когда объект готов к использованию.
El pueblo unido jamás será vencido.
Re[3]: Взаимодействие фабрики и репозитори объектов
S>Фабрика отвечает: S>1. за выбора фактического класса объекта для создания объекта S>2. за выбор и вызов нужного конструктора выбранного класса объекта с определенными параметрами
И сколько сейчас классов и разных конструкторов? Откуда уверенность в том, что будет больше?
S>3. за уведомление подписчиков о создании нового объекта
Вот это вообще странно.
S>То есть фабрика — это совокупность параметров, достаточная для того, чтобы создать новый объект вызовом одного непараметризованного метода CreateObject.
И в разных местах кода это будет создание разных объектов? Или вы боитесь явных параметров?
По мне так, наоборот такие непараметризованные вызовы — адовый геморрой при разборе кода. И отладку ни разу не упрощает.
S>Такая последовательность действий тоже возможна. Но в любом случае фабрика создает не совсем пустой объект. И в любом случае допускается, что клиент может подать в репозитори объект с некорректным состоянием, но должен исправить это состояние до завершения изменений.
Чем проще и понятнее последовательность действий, тем проще это поддерживать. Все неявные вызовы и подстановки в неожиданных местах — лишняя головная боль для тех, кто код попытается прочитать или модифицировать. Наслоение таких вещей — источник грандиозных багов.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Если в думать в отрыве от БД, то репозиторий это просто шаблон "Information Expert" из шаблонов GRASP, тогда он вполне может содержать методы для создания объектов с нужными параметрами как и методы выборки объектов по параметрам.