Лучший способ быстрой обработки - PullRequest
0 голосов
/ 03 декабря 2009

Как программист PHP сталкивался со многими (глубокими) утверждениями, мне любопытно, как вы справляетесь с этим. Вы используете структуры switch, if-elseif-else или if-else?

Лично я предпочитаю использовать переключатель при работе с более чем 2 случаями. Это также лучший способ с точки зрения производительности? А как насчет вложенных утверждений?

Мне любопытны ваши предпочтительные методы и ответы.

Пример

Необходимость выбора трех опций:

Использование переключателя:

switch($option)
{
  case 1 : $result= "foo"; break;
  case 2 : $result= "bar"; break;
  default : $result= "foobar";
}

Использование if-elseif-else

if($option == 1)
{
  $result= "foo";
} elseif ($option == 2)
{
  $result= "bar";
} else
{
  $result= "foobar";
}

Использование if-if-else

if($option == 1)
{ 
  $handle = "foo";
}
if($option == 2)
{
  $result = "bar";
}
else
{
  $result = "foobar";
}

Ответы [ 5 ]

1 голос
/ 03 декабря 2009

Если вам нужны такие микрооптимизации, вы должны использовать другой язык. Как ленивый программист, я люблю заниматься такими вещами:

class blabla{
  private $_actions;
  public function __construct(){
    $this->_actions = array(1 => '_firstAction',
                            2 => '_secondAction',
                            3 => '_thirdAction');

  }
  public function whatever($choice){
    if(isset($this->_actions[$choice])){
      $this->{$this->_actions[$choice]}();
    }
  }
  private function _firstAction(){}
  private function _secondAction(){}
  private function _thirdAction(){}
}
1 голос
/ 03 декабря 2009

Я обычно предпочитаю использовать самый красивый и понятный метод. Однако я стараюсь избегать необходимости задавать вопрос. Необходимость использования большого количества блоков if / else в вашем коде указывает на проблему с вашим дизайном.
Учитывая, что легко создавать ассоциативные массивы, нет никаких причин, по которым вы не можете сопоставить ключ с функцией или значением, которое, вероятно, превзойдет операторы switch для чего-либо, кроме тривиальных наборов данных. Или, что еще лучше, используйте полиморфизм , который намного удобнее и часто превращает большой блок if или switch в один вызов функции.

1 голос
/ 03 декабря 2009

Каждый, кроме начинающего программиста, знает, что switch быстрее, чем if..else, но switch не может заменить каждое составное выражение, которое вы можете вставить в оператор if (например, два выражения логическое И)

Кроме того, если вы говорите о глубоко вложенном коде, подобном этому

function foo()
{
  if ( /* expr1 */ )
  {
    // code

    if ( /* expr2 */ )
    {
      // code 

      if (  /* expr3 */ )
      {
        // code
        if ( /* expr4 */ )
        {
          // code          
        }
      }
    }
  } 
}

Тогда все, что я могу сказать, пожалуйста, прекрати это делать. Имейте некоторые защитные условия, которые заставят функцию выйти рано вместо этого. Вот вышесказанное переписано с этим стилем.

function foo()
{
  if ( !/* exp r1 */ )
  {
    return;
  }
  // code 1

  if ( !/* expr 2 */ )
  {
    return;
  }
  // code 2

  if ( !/* expr 3 */ )
  {
    return;
  }
  // code 3

  if ( !/* expr 4 */ )
  {
    return;
  }
  // code 4
}

Конечно, оба из них в реальном приложении, возможно, могут быть реорганизованы еще лучше, добавив больше функций.

1 голос
/ 03 декабря 2009

Я бы сказал, если вы посмотрите на три примера, самый красивый и чистый из них легко выбрать: оператор switch. Если вы можете жить со свободным сравнением коммутатора, выберите это. На этом уровне соображения производительности, как правило, не имеют смысла, поскольку потенциальные выгоды незначительны.

1 голос
/ 03 декабря 2009

Я нахожу переключатель удобным, когда у вас есть одна часть логики, используемая во многих случаях. то есть.

case 1:
case 2:
case 3:
    // do stuff for 1, 2 and 3
    break;
case 4:
    // other stuff just for 4
    break;
default:
    // fallback for everything else
    break;

также важно отметить, что переключатель не сравнивает , что может быть нежелательно в определенных сценариях

не слишком много, чтобы сказать с точки зрения производительности

...