CHAPTER 13 ■ DATABASE PATTERNS
are required to craft many similar but differing queries both within a single Mapper class and across
the mappers in your system.
An identity object encapsulates the conditional aspect of a database query in such a way that
different combinations can be combined at runtime. Given a domain object called Person, for example, a
client might be able to call methods on an identity object in order to specify a male, aged above 30 and
below 40, who is under 6 feet tall. The class should be designed so conditions can combined flexibly
(perhaps you’re not interested in your target’s height, or maybe you want to remove the lower age limit).
An identity object limits a client coder’s options to some extent. If you haven’t written code to
accommodate an income field, then this cannot be factored into a query without adjustment. The ability
to apply different combinations of conditions does provide a step forward in flexibility, however. Let’s
see how this might work:
Implementation
An identity object will typically consist of a set of methods you can call to build query criteria. Having set
the object’s state, you can pass it on to a method responsible for constructing the SQL statement.
Figure 13–9 shows a typical set of IdentityObject classes.
Figure 13–9. Managing query criteria with identity objects
You can use a base class to manage common operations and to ensure that your criteria objects
share a type. Here’s an implementation which is simpler even than the classes shown in Figure 13–9:
namespace woo\mapper;
//...
class IdentityObject {
private $name = null;
function setName( $name ) {
$this->name=$name;
}
function getName() {
return $this->name;
}