Результаты работы с шаблоном Domain Object Factory

Шаблон Domain Object Factory отделяет необработанные данные базы данных от данных полей объектов. Вы можете осуществлять любое количество корректировок внутри метода createObject() . Этот процесс прозрачен для клиента, обязанность которого — предоставлять необработанные данные. Если забрать эти функциональные возможности из класса Mapper, то они становятся доступными для других компонентов. Например, вот измененная реализация Collection.

abstract class woo_mapper_Collection {

protected $dofact;

protected $total = 0;

protected $raw = array();

// …

function _construct( array $raw=null,

woo_mapper_DomainObjectFactory $dofact=null ) {

if ( ! is_null ( $raw ) && ! is_null ( $dofact ) ) {

$this->raw = $raw;

$this->total = count( $raw );

}

$this->dofact = $dofact;

}

// …

Объект DomainObjectFactory можно использовать для генерации объектов по запросу.

if ( isset( $this->raw[$num] ) ) {

$this->objects[$num]=$this->dofact->createObject( $this->raw[$num] );

return $this->objects[$num];

}

Поскольку объекты DomainObjectFactory отделены от базы данных, их можно более эффективно использовать для тестирования. Мы можем, например, создать фиктивный объект DomainObjectFactory, чтобы протестировать код Collection. Сделать это намного проще, чем имитировать целый объект Mapper.

Один общий результат разбиения единого компонента на составные части — это неизбежное размножение классов. Поэтому нельзя недооценивать вероятность путаницы. Даже если каждый компонент и его связи с другими равноправными компонентами логичны и явно определены, мне часто бывает трудно составлять пакеты, содержащие десятки компонентов с похожими названиями.

Ситуация сначала ухудшится, а затем — улучшится. Я уже вижу еще одно проблемное направление в Data Mapper. Метод Mapper: :getCollection() был удобным, но опять-таки другим классам может понадобиться получить объект Collection для определенного типа приложения, не используя класс, обращенный к базе данных. Итак, у нас есть два связанных абстрактных компонента: Collection и DomainObjectFactory. В соответствии с доменным объектом, с которым мы работаем, мы будем требовать другой набор конкретных реализаций: например, VenueCollection и VenueDomainObjectFactory или SpaceCollection и SpaceDomainObjectFactory. Конечно, эта проблема приводит нас непосредственно к шаблону Abstract Factory. На рисунке показан класс PersistenceFactory. Я буду использовать его для организации различных компонентов, из которых состоят несколько следующих шаблонов.
Scr07 Результаты работы с шаблоном Domain Object Factory

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