此代码是否适合策略模式?
public function isValidEmail($email, $organization)
{
switch ($organization) {
case 'USAF':
case 'Army':
case 'USMC':
case 'Navy':
case 'SOCOM':
return (preg_match('/[.]mil$/i', $email) === 1);
break;
case 'Federal Gov.':
return (preg_match('/[.]gov$/i', $email) === 1);
break;
case 'State/Local Gov.':
$regionCollection = Mage::getModel('directory/region')
->getResourceCollection()
->addCountryFilter(array('US'))
->load();
$stateAbbr = array();
// Cycle through state abbreviations for match
foreach ($regionCollection as $region) {
$stateAbbr[] = strtolower($region->getCode());
}
$states = implode('|', $stateAbbr);
return (preg_match("/[\.|@]{1}($states){1}\.us$/i", $email) ===
break;
case 'USCG':
case 'DOD':
case 'Defense Industry':
return true;
break;
default:
return false;
break;
}
// It got past somehow?
return false;
}
我假设你可以有一个简单的界面来定义一个验证方法,但我对如何处理switch语句中的两个奇数球情况感到困惑,这些情况返回true / false w / no email logic。
interface ValidInterface
{
public function isValid($email);
}
答案 0 :(得分:2)
您使用验证器界面走在正确的轨道上(我会将其命名为更有意义的内容,如EmailValidator
)。然后,您可以创建组织到验证器的映射,并在执行验证时查看它:
private $validators = array(
'USAF' => new MilitaryEmailValidator(),
'Army' => new MilitaryEmailValidator(),
...
'Defense Industry' => new TrueEmailValidator()
);
public function isValidEmail($email, $organization) {
if (isset($this->validators[$organization]))
return $this->validators[$organization])->isValid($email);
// default return
return false;
}
答案 1 :(得分:0)
我认为这里的相关设计模式是责任链。它本质上是switch语句的面向对象版本。您有一个对象列表(或树)。他们每个人都有能力确定他们是否应该处理这个问题(相当于“案例”陈述)。如果他们不这样做,决定将传递给继任者(下一个“案例”陈述)。您可能有也可能没有全能,等同于“default:”声明。
为什么然后使用Chain of Responsibility而不是switch语句或建议的字符串映射到对象?
我认为它们是实现相同目标的特定实现。更通用的实现可以为您提供更多自由度或类型安全性。交换机解决方案对每种情况下可以放置的代码量/可以可靠处理和维护的案例数量施加了非常实际的限制。例证:在你的代码中,state / gov的分支非常复杂,把它放在一个对象或一个方法中会大大清理代码。