Шаблон Domain Object Factory

Шаблон Data Mapper очень хорош, но у него есть некоторые недостатки. В частности, класс Mapper берет на себя слишком много. Он составляет SQL-операторы, преобразует массивы в объекты и, конечно, преобразует объекты обратно в массивы, готовые для добавления в базу данных. Такая многосторонность делает класс Mapper удобным и функциональным. Но она может уменьшить степень гибкости.

Это особенно верно, если Mapper должен обрабатывать много различных видов запросов или если другим классам нужно совместно использовать функциональные возможности Mapper.

Давайте начнем с основной функции: генерации объектов приложения.

Проблема шаблона Domain Object Factory

Мы уже сталкивались с ситуацией, когда класс Mapper демонстрирует естественное ошибочное поведение. Конечно, метод createObject () используется Mapper внутри, но объектам Collection он тоже нужен для создания объектов приложения по запросу. Это требует от нас передать ссылку на Mapper при создании объекта Collection. Хотя нет ничего плохого в том, чтобы разрешить обратные вызовы (как мы делали в шаблонах Visitor и Observer, а также в других), лучше передать ответственность за создание объекта приложения его собственному типу. Затем его могут совместно использовать классы Mapper и Collection.

Советую прочитать также