你會在這裏使用策略模式嗎？

此代碼是否適合策略模式？你會在這裏使用策略模式嗎？

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; 
}

我是假設你可以有一個簡單的界面來定義一個validate方法，但我對如何處理這兩個怪球的情況下在返回真/假瓦特/沒有電子郵件邏輯switch語句稍有困惑。

interface ValidInterface 
{ 
    public function isValid($email); 
}

來源

2012-08-28 veilig

''return'後面不需要'break'。 – xdazz

使用'\ .'而不是'[。]'。它更清晰，更簡潔。 –

你在正確的軌道上你的驗證界面（我將它命名爲更有意義的事情像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; 
}

來源

2012-08-28 02:33:47 casablanca

您的'TrueEmailValidator :: isValid（）'和'FalseEmailValidator :: isValid（）'方法的外觀如何？他們是否仍然符合接口並接受'$ email'參數，然後忽略它並分別返回true/false？這是我最初走下坡路的道路，但是質疑這種非常具體的方法來忽略這些參數。這被認爲是良好的做法？ – veilig

@veilig：是的，他們會忽略'$ email'。這種方法沒有什麼本質上的錯誤 - 具有接口的整個想法是你不關心它是如何實現的。 – casablanca

我認爲這裏的相關設計模式是責任鏈。它本質上是switch語句的面向對象版本。你有一個對象列表（或樹）。他們每個人都有能力確定他們是否應該處理這個問題（相當於「案例」聲明）。如果他們不這樣做，那麼決定就會轉交給繼任者（下一個「案例」聲明）。您可能會或可能沒有全面的，相當於「默認：」聲明。

爲什麼然後使用責任鏈而不是開關語句或建議的字符串映射對象？

我提交他們是實現相同的事情的具體實現。更通用的實現可能會給你更多的自由度或類型安全。交換機解決方案對您可以在每種情況下放置的代碼數量/可以可靠處理和維護的情況數量施加了非常實際的限制。例如：在你的代碼中，state/gov的分支非常複雜，把它放在一個對象或方法中可以清理代碼。

來源

2012-08-28 05:08:57

我很抱歉地說，但_Chain of Responsibility_在這裏並不相關 – Drona

關心你爲什麼這麼想？這是解決這類問題的通用解決方案，但由於我陳述的原因，這可能是過度的。 –

你會在這裏使用策略模式嗎？

回答

相關問題