CHAPTER 12 ■ ENTERPRISE PATTERNS
)
CREATE TABLE 'space' (
'id' int(11) NOT NULL auto_increment,
'venue' int(11) default NULL,
'name' text,
PRIMARY KEY ('id')
)
CREATE TABLE 'event' (
'id' int(11) NOT NULL auto_increment,
'space' int(11) default NULL,
'start' mediumtext,
'duration' int(11) default NULL,
'name' text,
PRIMARY KEY ('id')
)
Clearly, the system will need mechanisms for adding both venues and events. Each of these
represents a single transaction. I could give each method its own class (and organize my classes
according to the Command pattern that you encountered in Chapter 11). In this case, though, I am going
to place the methods in a single class, albeit as part of an inheritance hierarchy. You can see the
structure in Figure 12–10.
So why does this example include an abstract superclass? In a script of any size, I would be likely to
add more concrete classes to this hierarchy. Since most of these will work with the database, a common
superclass is an excellent place to put core functionality for making database requests.
Figure 12–10. A Transaction Script class with its superclass
In fact, this is a pattern in its own right (Fowler has named it Layer Supertype), albeit one that most
programmers use without thinking. Where classes in a layer share characteristics, it makes sense to
group them into a single type, locating utility operations in the base class. You will see this a lot in the
rest of this chapter.
In this case, the base class acquires a PDO object, which it stores in a static property. It also provides
methods for caching database statements and making queries.
namespace woo\process;
//...