Которые сокращаются (Дизайн контракта) лучше?
Мне наконец удалось это сделать. это не лучшее решение, но оно работает. Также, если у нас более 10 элементов, процесс начинает замедляться, потому что он умножается каждый раз, когда мы добавляем новый элемент:
public function generateAllCases($arr1, $arr2, $resultArr, &$index, $firstCall = false)
{
$shifted = false;
foreach ($arr1 as $elm)
{
foreach ($arr2 as $i => $vis)
{
if(!$shifted)
{
array_shift($arr1);
$shifted = true;
}
if(!isset($resultArr[$index]) || !isset($resultArr[$index][$elm]))
{
$resultArr[$index][$elm] = $vis;
}
else
{
$prevItem = $resultArr[$index];
$index++;
$resultArr[$index] = $prevItem;
$resultArr[$index][$elm] = $vis;
}
$resultArr = $this->generateAllCases($arr1, $arr2, $resultArr, $index);
}
break;
}
if($firstCall)
{
$allResults = [];
foreach ($resultArr as $k => $v)
{
$allResults[implode('.', $v)] = $v;
}
$allResults = array_values($allResults);
return $allResults;
}
return $resultArr;
}
называется так:
$index = 0;
$cases = $rpd->generateAllCases(['a', 'b', 'c'], [true, false], [], $index, true);
9 ответов
Следует иметь в виду, что движение "по проводу" к другому уровню (ли база данных или сервер приложений) будет одной из самых дорогих операций, которые можно сделать - обычно, то сетевой вызов возьмет несколько порядков величины дольше, чем вызовы в оперативной памяти.
Поэтому имеет смысл структурировать Ваш API для предотвращения избыточных вызовов.
Рассмотрите, если Ваш API похож на это:
// Check to see if a given patient exists
public bool PatientExists(int id);
// Load the specified patient; throws exception if not found
public Patient GetPatient(int id);
Затем Вы, вероятно, поразите базу данных дважды - или быть уверенными в хорошем кэшировании для предотвращения этого.
Другое соображение - это: В некоторых местах Ваш код может иметь "известный - хороший" идентификатор в других местах нет. Каждое местоположение требует различной политики в отношении того, должно ли исключение быть выдано.
Вот шаблон, который я использовал успешно в прошлом - имеют два метода:
// Load the specified patient; throws exception if not found
public Patient GetExistingPatient(int id);
// Search for the specified patient; returns null if not found
public Patient FindPatient(int id);
Очевидно, GetExistingPatient () может быть создан путем вызова FindPatient ().
Это позволяет Вашему коду вызова получать соответствующее поведение, выдавая исключение, если что-то пошло не так, как надо, и избегающий обработки исключений в случаях, где это не нужно.
Другая опция была бы шаблоном Несуществующего объекта.
Необходимо, вероятно, выдать исключение. Если Вы имеете id это не указывает допустимому пациенту, куда это прибывало из? Что-то очень плохо, вероятно, произошло. Это - исключительное обстоятельство.
Править: Если Вы делаете что-то другое, чем основанное на целом числе извлечение, как поиск на основе текста, то возврат null прекрасен. Тем более, что в этом случае Вы возвращаете ряд результатов, которые могли быть больше чем одним (больше чем один пациент с тем же именем, той же датой рождения, или независимо от того, что Ваши критерии).
Поисковая функция должна иметь другой контракт от функции извлечения.
Это зависит:
Если Вы полагаете, что нормальное функционирование приведет к pation числу, не соответствующему файлу в DB затем должна быть возвращена, пустая (ПУСТАЯ) запись.
Но если Вы ожидаете, что данный идентификатор должен всегда поражать запись затем, когда каждый не найден (который должен быть редким), затем используют исключение.
Другие вещи как ошибка соединения с БД должны генерировать исключение.
Поскольку Вы ожидаете под нормальными ситуациями, что запрос к DB всегда будет работать (хотя он может возвратить 0 записей или не).
P.S. Я не возвратил бы указатель. (Кто владеет указателем??)
Я возвратил бы объект, который может или не может иметь записи. Но это Вы можете опрошенный для существования записи в. Потенциально интеллектуальный указатель или что-то немного более умное, чем интеллектуальный указатель, который понимает cotext.
Для этого обстоятельства у меня был бы пустой указатель возврата метода для несуществующего пациента.
Я склонен предпочитать использовать исключения для помощи graeful неисправности, когда существует проблема с самой системой.
В этом экземпляре это - mosdt, вероятно:
- опечатка в идентификаторе пациента, если это вводилось в поисковую форму,
- ошибка ввода данных, или
- проблема рабочего процесса в этом он запись пациента еще не была введена.
Следовательно, возвращая пустой указатель, а не исключение.
Если бы была проблема, связывающаяся с базой данных, то у меня было бы повышение метода исключением.
Править: Просто видел, что идентификатор пациентов в подписи был целым числом, Steven Lowe спасибо, таким образом, я исправил свой список причин.
Мой основной пункт о формировании рисунка, когда использовать исключения (для системных ошибок) по сравнению с другими методами возврата ошибки (для простых опечаток ввода данных) все еще, стоит все же. По моему скромному мнению.
HTH
удачи,
Ограбить
В простой такой ситуации 1. кажется, более, чем достаточен. Можно хотеть реализовать что-то как метод обратного вызова, который клиент называет для знания, почему он возвратил пустой указатель. Просто предложение.
беря Ваш descriptiong по номиналу, Вам, вероятно, нужны оба:
- плохие идентификаторы являются ошибками/исключениями, как Adam указал, но
- при предоставлении идентификаторов в другом месте, которые, возможно, исчезли, Вам будет нужен метод запроса проверить на них
При принятии я считал это правильно... При вызове Пациента (100), это возвратит ссылку на объект для Пациента с идентификатором 100. Если никакой пациент с идентификатором 100 не существует, я думаю, что он должен возвратить пустой указатель. Исключения злоупотребляются, IMO и этот случай не призывают к нему. Функция просто возвратила пустой указатель. Это не создало некоторый случай с ошибками, который может разрушить Ваше приложение (если, конечно, Вы не закончили тем, что не обработали тот пустой указатель и раздали его к некоторой другой части Вашего приложения).
У меня определенно был бы тот функциональный возврат 'пустым указателем', особенно если бы это была часть некоторого поиска, где пользователь искал бы пациента с конкретным идентификатором и если бы ссылка на объект закончила тем, что была пустой, то он просто указал бы, что никакой пациент с тем идентификатором не существует.
Выдайте исключение.
Если Вы возвращаете пустой указатель, кодируете как это:
Console.WriteLine(Patient(id).Name);
перестал бы работать с NullReferenceException, если идентификатор не существует, который не так полезен как мнение PatientNotFoundException (идентификатор). В этом примере все еще относительно легко разыскать, но рассмотреть:
somePatient = Patient(id)
// much later, in a different function:
Console.WriteLine(somePatient);
О добавлении функции, которая проверяет, существует ли пациент: Обратите внимание, что это не предотвратит PatientNotFoundExceptions полностью. Например:
if (PatientExists(id))
Console.WriteLine(Patient(id).Name);
- другой поток или другой процесс могли удалить пациента между вызовами к PatientExists и Пациента. Кроме того, это означало бы два запроса базы данных вместо одного. Обычно, лучше просто попробовать вызов и обработать исключение.
Обратите внимание, что ситуация отличается для запросов, которые возвращают несколько значений, например, как список; здесь, уместно возвратить пустой список, при отсутствии соответствий.