Тип возврата метода

Question

В моей компании система рассчитана на 3 слоя.Уровень 1 отвечает за обработку бизнес-логики.Уровень 3 вызывает бэкэнд-системы.Layer2 находится между двумя слоями, так что layer1 не нужно знать о внутренних системах.Чтобы передать информацию из layer3, layer2 должен определить интерфейс для layer1.

Например, layer1 хочет проверить, правильный ли PIN-код от пользователя.Он вызывает метод layer2 checkPin (), а затем layer2 вызывает соответствующую внутреннюю систему.Результатом checkPin () могут быть: correctPin, inCorrectPin и internalError.На данный момент мы определили тип возвращаемого значения int.Поэтому, если layer2 возвращает 0, это означает, что correctPin;если 1 возвращается, это означает inCorrectPin;если возвращается 9, это означает internalError.

Работает.Однако я чувствую себя немного неловко из-за этого подхода.Есть ли лучшие способы сделать это?Например, определить перечисление CheckPinResult {CORRECT_PIN, INCORRECT_PIN, INTERNAL_ERROR} и вернуть тип CheckPinResult?

Спасибо, Сара

Answer 1

Это вопрос стиля.То, как вы описали, является своего рода стилем Си для достижения цели.Стиль Java следующий: checkPin (pin) должен возвращать логическое значение.Истинное значение означает, что штифт в порядке, а ложное значение - не в порядке.Если происходит ошибка, вы бросаете исключение.Исключения являются стандартным способом устранения ошибок в Java.Исключения полезны, потому что они могут иметь типы и сообщения об ошибках, чтобы помочь в отладке.

Я говорю, что описываемый вами механизм - это стиль C, потому что в C стандартный способ обработки ошибок - возвращать целое число, отображающееопределить, а затем передать по ссылке искомое значение (в данном случае логическое).Таким образом, в c вы получите

int checkPin(int pin, bool &ans); //returns an error value.

. В любом случае, я настоятельно рекомендую не возвращать значение ошибки в том же месте, где вы возвращаете логическое значение.Это создает путаницу, потому что одно значение (возвращаемое значение) должно действительно представлять только одну вещь.Состояние ошибки и ответ на вопрос - две разные вещи, поэтому их следует возвращать по разным каналам.

Надеюсь, это помогло.

Answer 2

Мне нравится подход enum. Самодокументируемый и легко расширяемый. Вы можете установить значение, возвращаемое каждым из них, в соответствии с принятым соглашением 0, 1, 9.

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

Но если процент отказов больше порядка 1%, я бы сказал, что возвращаемое значение может быть лучше. Возможно, вы захотите перебрать большое количество значений и просто накапливать номера деталей с ошибочными выводами в виде большого пакета. Это зависит от того, как вы используете код ошибки.

Answer 3

Enum, безусловно, является улучшением по сравнению с целочисленными типами возвращаемых данных и совершенно правильным подходом. Другой вариант будет иметь подпись уровня 2, такую ​​как:

public boolean isPINValid() throws InternalErrorException();

Поскольку, я полагаю, внутренние ошибки являются исключением, почему бы не рассматривать их как таковые?

Answer 4

Разумно ли распространенный случай, когда вы получаете внутреннюю ошибку? Если нет, я бы checkPin возвратил логическое значение и выдал исключение, если есть внутренняя ошибка (но тогда я бы, вероятно, вместо этого вызвал бы метод pinIsValid или что-то подобное).

Если это (по какой-то причине) ожидаемый результат с внутренней ошибкой, тогда перечисление из трех состояний, вероятно, может сработать хорошо (у меня похожий случай в моем текущем проекте).