《PHP设计模式介绍》第十章规范模式(2)--一起PHP技术联盟

《PHP设计模式介绍》第十章规范模式(2)

当你的应用程序必须加工处理一个表单，你可以先把$_POST过来的数据值装载到数据源DataSource，然后使用参数化规范来完成表单的验证。（同样的方法也可以用到配置文件上，把配置文件的数据装载到DataSource数据源，然后使用规范来验证）。

现在，让我们构造一个参数化规范的示例类，主要用来搭建一个数据块。首先，我们要建一个规范，这个规范得满足“某一个字段和指定的值等价”的条件。

class FieldEqualSpecification {
protected $field;
protected $value;
public function __construct($field, $value) {
$this->field = $field;
$this->value = $value;
}
public function isSatisfiedBy($datasource) {
return ($datasource->get($this->field) == $this->value);
}
}

这个思路是很简单的：在构造（construction）期间，存储一个字段和它期望的值，从数据源(DataSource)中获取到期望的值传递到方法isSatisfiedBy()，然后比较。

为了测试这个规范，写一个测试实例来演示这个数据源（DataSource）：

class SpecificationsTestCase extends UnitTestCase {
protected $ds;
function setup() {
$this->ds = new DataSource;
$this->ds->set(‘name’, ‘Jason’);
$this->ds->set(‘age’, 34);
$this->ds->set(‘email’, ‘jsweat_php@yahoo.com’);
$this->ds->set(‘sex’, ‘male’);
}
}

在上面的例子里，方法setup()创建了一个数据源对象，并设置了相应的属性。这个测试还包含一个方法，这个方法要么返回pass要么返回fail。

class SpecificationsTestCase extends UnitTestCase {
// ...
function TestFieldEqualSpecification() {
$name_jason = new FieldEqualSpecification(‘name’, ‘Jason’);
$this->assertTrue($name_jason->isSatisfiedBy($this->ds));
$sex_other = new FieldEqualSpecification(‘sex’, ‘other’);
$this->assertFalse($sex_other->isSatisfiedBy($this->ds));
}
}

通常在评估字符串的时候，一个正则表达式比一系列严格的比较关系能够更好的帮助你来定义你的需求。那么，让我们在FieldMatchSpecification中使用正则表达式来匹配我们的规范工具集。

class FieldMatchSpecification {
protected $field;
protected $regex;
public function __construct($field, $regex) {
$this->field = $field;
$this->regex = $regex;
}
public function isSatisfiedBy($datasource) {
return preg_match($this->regex, $datasource->get($this->field));
}
}

在这个例子里，这个字段对应的值和PCRE表达式都在构造的时候保存好了。然后方法isSatisfiedBy()从传递过来的数据源DataSource获取到这个字段，并且使用preg_match()方法来比较它的值是否满足对应的正则表达式。

下面这个例子演示了如何为FieldMatchSpecification字段匹配规范书写测试实例。

class SpecificationsTestCase extends UnitTestCase {
// ...
function TestFieldMatchSpecification() {
$valid_email = new FieldMatchSpecification(
‘email’,
‘/^[^\s@]+@[^\s.]+(?:\.[^\s.]+)+/’);
$this->assertTrue($valid_email->isSatisfiedBy($this->ds));
$name_ten_letters = new FieldMatchSpecification(
‘name’,
‘/^\w{10}$/’);
$this->assertFalse($name_ten_letters->isSatisfiedBy($this->ds));
}
}

上面例子中的email正则要求“在@前是一串不包含空格、@的字符，在@后是两组或者两组以上不包含可个空格或者句点的字符串，这些字符串之间由句点间隔着”。而变量$name_ten_letters规范要求输入的值必须恰好是由10个字符组成。

注：正则表达式

有许多书籍单独开一章来讲解正则表达式，甚至有些整本书都在讨论这个话题（译者注：作者是为了说明正则表达式的重要性和难度）。所以，请认识到上面的代码只是一个过于简单化的例子，而不是一个检查email的完善的正则表达式。

下面让我们搭建最后一个具体的规范用来检验一个字段值是否大于或者等于对应的值。我们毫无疑问的把它命名为FieldGreaterThanOrEqualSpecification.。

class FieldGreaterThanOrEqualSpecification {
protected $field;
protected $value;
public function __construct($field, $value) {
$this->field = $field;
$this->value = $value;
}
public function isSatisfiedBy($datasource) {
return ($datasource->get($this->field) >= $this->value);
}
}

这里没有太多的不可思议的：在构造器里面存储相应的要被比较的字段和值，然后在方法isSatisfiedBy()里面验证提取出来的字段。

下面是一个测试实例，用来演示如何应用FieldGreaterThanOrEqualSpecification。

class SpecificationsTestCase extends UnitTestCase {
// ...
function TestFieldGreaterThanOrEqualSpecification() {
$adult =
new FieldGreaterThanOrEqualSpecification(‘age’, 18);
$presidential_age =
new FieldGreaterThanOrEqualSpecification(‘age’, 35);
$this->assertTrue($adult->isSatisfiedBy($this->ds));
$this->assertFalse($presidential_age->isSatisfiedBy($this->ds));
}
}

你是否已经注意到在规范对象被标识上合理的名称时候，这些代码是如何开始证明自己的吗？你是否能够通过规范对象的名称来理解到代码的相应的功能？ $adult->isSatisfiedBy($something)你看一眼就会明白，根本无需深入详细的钻研代码。这也是规范模式的优点之一吧。

到现在为止，你应该很清楚的明白规范模式就如一个接口。使用PHP5明确的表示出这个规范模式：

interface Specification {
public function isSatisfiedBy($datasource);
}

我们把这些基本的模块按照一定的格式集中起来，这甚至是非常有用的。因为从一个规范类的方法isSatisfiedBy()中返回的结果是一个布尔值(boolean)，把这些布尔值运用到具体不同的规范类的效果都是相当好的。

为了实现逻辑与，我们创建一个类，把两个具体的规范实例类组合起来，当给出的数据源参数同时满足给定的条件后就返回true。

class AndSpecification implements Specification {
protected $spec;
protected $andSpec;
public function __construct($spec, $andSpec) {
$this->spec = $spec;
$this->andSpec = $andSpec;
function isSatisfiedBy($datasource) {
return ($this->spec->isSatisfiedBy($datasource)
&& $this->andSpec->isSatisfiedBy($datasource));
}

你也可以类似的实现逻辑或。

class OrSpecification implements Specification {
protected $spec;
protected $orSpec;
public function __construct($spec, $orSpec) {
$this->spec = $spec;
$this->orSpec = $orSpec;
function isSatisfiedBy($datasource) {
return ($this->spec->isSatisfiedBy($datasource)
|| $this->orSpec->isSatisfiedBy($datasource));
}

利用已经给出的“逻辑”规范和最初的一些规规范集合，你可以实现一些复杂的验证。

class PolicyFactory {
public function createJasonPolicy() {
$name_jason = new FieldEqualSpecification(‘name’, ‘Jason’);
$age_at_least_thirty =
new FieldGreaterThanOrEqualSpecification(‘age’, 30);
$male = new FieldEqualSpecification(‘sex’, ‘male’);
$jasons_email = new OrSpecification(
new FieldEqualSpecification(‘email’, ‘jsweat_php@yahoo.com’)
, new FieldEqualSpecification(‘email’,
‘jsweat@users.sourceforge.net’));
return new AndSpecification(
$name_jason, new AndSpecification(
$age_at_least_thirty,
new AndSpecification($male, $jasons_email)
));
}
}

一开始，策略工厂看起来有点零乱，主要是因为临时变量的数量阻止了单个具体规范的实例化。然而，代码中最有趣的部分是使用或规范（OrSpecification）和与规范（AndSpecification）类（在上面高亮显示了）。对email进行FieldEqualSpecification字段等价规范的两个实例化都被当作参数传递到或规范（OrSpecification）的构造方法中。因为或规范（OrSpecification）执行了规范接口，这个$jasons_email对象可以象任何其他具体的规范实例一样处理。事实上，在4行后它在又按照同样的方式被使用，具体在new AndSpecification($male, $jasons_email)。

使用上面给出的方法器PolicyFactor（上面的PolicyFactory），我们可以做到：

$jason = PolicyFactory::createJasonPolicy();
$jason->isSatisfiedBy($datasource);

这两行代码用于验证数据源$datasource的name字段的值是否是“jason”，它的age字段的值是否至少大于30而且它的email是否是jsweat_php@yahoo.com或者jsweat@users.sourceforge.net。

从审美观点上来说，所有在构建具体规范过程中所出现的中间变量都是令人不高兴的。那么，有没有方法来清除这些中间变量使得代码更加容易读和维护？是的，当然有！简单的利用PHP5的一个新特征来链接到对象的方法并返回这个方法。

具体方法的第一步可能是允许单个具体的规范知道如何“与”和“或”它自身。这可以通过引入Factory方法（具体请看第三章——工厂方法模式）来创建或规范（OrSpecification）和与规范（AndSpecification）对象。由于这些特点对所有的规范来说都是通用的，所以把它们封装到一个抽象的基类里绝对是个很好的主意。

abstract class BaseSpecification implements Specification {
protected $field;
public function and_($spec) { return new AndSpecification($this, $spec); }
public function or_($spec) { return new OrSpecification($this, $spec); }
}

这有趣的方法名字add_()和or_()是必须的，因为”add”和”or”在PHP中是关键字。

通过引入这个基类，那些在前面书写的具体的类都必须修改，得让它们都继承于BaseSpecification：

class FieldEqualSpecification extends BaseSpecification {

// ...}

接下来要引入Factory方法来更加容易的创建单个具体的规范类。这可能会在单独的factory类里面实现，但是为了更加方便，你可以把这个方法增加到PolicyFactory类里面。

class PolicyFactory {
protected function equal($field, $value) {
return new FieldEqualSpecification($field, $value);
}
protected function gTorEq($field, $value) {
return new FieldGreaterThanOrEqualSpecification($field, $value);
}
}

现在，让我们联合这些所有的Factory方法来创建一个综述，就象下面显示的一样：

class PolicyFactory {
// ..
public function createJasonPolicy() {
return $this->equal(‘name’, ‘Jason’)->and_(
$this->gTorEq(‘age’, 30)->and_(
$this->equal(‘sex’, ‘male’)->and_(
$this->equal(‘email’, ‘jsweat_php@yahoo.com’)->or_(
$this->equal(‘email’, ‘jsweat@users.sourceforge.net’)
))));
}
}

就和前面一样，方法createJasonPolicy()创建了一个策略（Policy）,但是这代码的可读性好很多了。

在经过所有的重组后，类的图表就如下所示：

规范模式能让你在应用程序里更加容易的组织和架构你的商业逻辑。我把这个模式包含在这本书里面的一个原因就是因为它开始显示了在真正的显示世界应用中模式是如何修改和组合的。

	页数1/1: 首页 « 1 » 末页
发表回复：您还没有登陆，无法发表回复。请先[登陆]