PHP Objects, Patterns and Practice (3rd edition)

CHAPTER 12 ■ ENTERPRISE PATTERNS

source of problems. If you’re not careful, you can end up modeling the database, rather than the
problems and forces you are attempting to address.
Just because a Domain Model often mirrors the structure of a database does not mean that its
classes should have any knowledge of it. By separating the model from the database, you make the entire
tier easier to test and less likely to be affected by changes of schema, or even changes of storage
mechanism. It also focuses the responsibility of each class on its core tasks.
Here is a simplified Venue object, together with its parent class:

namespace woo\domain;

abstract class DomainObject {
private $id;

function __construct( $id=null ) {
$this->id = $id;
}

function getId( ) {
return $this->id;
}

static function getCollection( $type ) {
return array(); // dummy
}

function collection() {
return self::getCollection( get_class( $this ) );
}
}

class Venue extends DomainObject {
private $name;
private $spaces;

function construct( $id=null, $name=null ) {
$this->name = $name;
$this->spaces = self::getCollection("\woo\domain\Space");
parent::construct( $id );
}

function setSpaces( SpaceCollection $spaces ) {
$this->spaces = $spaces;
}

function getSpaces() {
return $this->spaces;
}

function addSpace( Space $space ) {