#javascript #design-patterns
#javascript #шаблоны проектирования
Вопрос:
Случай 1 (выдает ошибку, если регистр switch не сопоставлен):
function getColorName(c) {
switch(c) {
case Color.Red:
return 'red, red wine';
case Color.Green:
return 'greenday';
case Color.Blue:
return "Im blue, daba dee daba";
default:
throw new Error('error');
}
}
getColorName(Color.Yellow); // this results in an error thrown
Случай 2 (регистр по умолчанию возвращает null, и это обрабатывается в вызывающем):
function getColorName(c) {
switch(c) {
case Color.Red:
return 'red, red wine';
case Color.Green:
return 'greenday';
case Color.Blue:
return "Im blue, daba dee daba";
default:
return null;
}
}
if (getColorName(Color.Yellow)) {
// do stuff here
}
Возможно, это не идеальный пример. Однако, цель вопроса — понять, каков подход, который охватывает как можно больше вариантов использования, избегая чрезмерной сложности при существовании логики переключения?
Хотя это выходит за рамки вопроса, в качестве средства разъяснения возможных вариантов использования переключатель будет реализован либо
- с помощью
switch
(как указано выше) - как
if-elseif-else
функция (если регистры switch сложны или их всего несколько)
пример if-elseif-else (для справки):
function getColorName(c) {
if (Color.Red) {
return 'red, red wine';
}
else if (Color.Green) {
//...
}
// etc. (--cut--)
else {
return null;
}
}
Комментарии:
Ответ №1:
Моя предпочтительная практика — выдавать исключение и не возвращать null, и пусть функция-вызывающий объект определяет следующие шаги. Ваша вызываемая функция должна беспокоиться только о вводимых данных, имеет ли она подходящую информацию на основе ввода данных для выполнения своей работы и либо возвращает действительный ответ на основе ввода, либо сообщает вызывающей функции, что она не может обработать ввод.
В вашем примере возврат null означал бы, что ваша вызывающая функция должна была бы обрабатывать null другим условным циклом, а затем на основе этого либо возвращать null далее своей собственной вызывающей функции, либо делать что-то еще. Это делает код довольно громоздким, в то время как конкретные исключения могут быть легко расширены по мере необходимости и оказаться весьма полезными для протоколирования и устранения проблем.