Как проверяется параметр «высокий уровень» на стоп-кадре?

Question

Я читал книгу «Руководства по дизайну рамок», книгу по разработке фреймворков в .NET, с выдержками из дизайнеров фреймворка о решениях, которые они принимали в отношении каждого раздела (например, дизайн параметров, обработка исключений и т. Д.).

Один из советов, в соответствии с параметрами, заключается в том, чтобы проверить параметры как «высоко на стоп-кассе», насколько это возможно. Это связано с тем, что работа здесь не такая дорогостоящая, как низкая на стоп-кассе, так что штраф за производительность не так дорого стоит при проверке высоко в callstack.

Означает ли это, что когда я передаю параметры в метод или конструктор, я проверяю их перед тем, как делать что-либо еще, или делаю это непосредственно перед использованием параметров (так что может быть 100 строк кода между параметром в определение и использование параметра)?

Thanks

Answer 1

Я не читал конкретные рекомендации, которые вы упомянули, но я ожидаю, что они говорят о случае, когда метод A вызывает метод B, который вызывает метод C, и значение параметра передается через все три вызова. Лучше проверить этот параметр в начале метода A, чем где-то посреди метода C, потому что, если он недействителен, вы можете пропустить все, что происходит в A и B, а также начало C. Это особенно верно, если B или C называются внутренними циклами, потому что тогда проверка на низком уровне будет происходить много раз, а не только один раз в начале A.

Конечно, вы должны сбалансировать это с тем, насколько сложна проверка параметра. Это может быть проще понять, если вы подтвердите его в том же месте, где вы его используете.

Answer 2

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

Что касается проверки ввода, я считаю, что производительность является незначительной проблемой.

Answer 3

Подтвердите их как можно раньше в своем методе!

Answer 4

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

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

Answer 5

1. Предпочитает утверждать в публичном API сборки. Это означает общедоступные методы публичных занятий.

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

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