Должен ли я избыточно проверять аргументы (например, пустота сбора)?

Question

Есть ли проблема с проверкой избыточного сбора здесь?:

SomeMethod()
{
    shapes = GetShapes();
    //maybe Assert(shapes.Any())?
    if(shapes.Any())
    {
        ToggleVisibility(shapes);
    }
}

ToggleVisibility(IEnumerable<Shape> shapes)
{
    //maybe Assert(shapes.Any())?
    if(shapes.Any())
    {
        //do stuff 
    }
}

Answer 1

Я не думаю, что здесь есть большая проблема, потому что вызов Any () не дорогая операция.

Существует небольшая проблема в том, что ответственность и поведение ToggleVisibility не объявлены. ToggleVisibility должна сообщать вызывающим сторонам, как он будет себя вести, если фигуры пустые или нулевые. Лучший способ сделать это - через XML-комментарии, чтобы он отображался в Intellisense. Это позволит вызывающим ToggleVisibility решить, нужно ли им проверять, является ли коллекция пустой или нулевой.

Answer 2

Если ToggleVisibility(IEnumerable<Shape>) является закрытым методом (таким образом, SomeMethod() должен находиться в той же библиотеке), то я определенно включил бы проверку только один раз в сборку выпуска.Будет ли проверка в том или ином методе, зависит от того, что имеет смысл для происходящего.Если ожидается, что коллекция никогда не будет пустой при правильном выполнении, возможно, проверка не требуется.Если ToggleVisibility(IEnumerable<Shape>) вызывается из десяти разных мест, и в любом из них может быть пустая коллекция, то я бы определенно освободил вызывающего пользователя от бремени выполнения проверки каждый раз и просто вставил бы его в сам метод.

Если ToggleVisibility(IEnumerable<Shape>) является частью общедоступного API, то он определенно должен делать все, что необходимо для проверки параметров, поскольку пользователи API, скорее всего, будут делать что-либо, и все параметры должны быть проверены всегда.Если в документации по методу говорится, что пустые коллекции будут игнорироваться, то SomeMethod(), очевидно, не нужно беспокоиться об этом.В противном случае SomeMethod() необходимо сделать все возможное, чтобы убедиться, что передаваемая коллекция действительна, даже если это означает, что выполняются избыточные проверки.

Answer 3

Я бы предположил, что ответ ... как обычно ... "это зависит". Во время вызова Any на IEnumerable это не дорого, действительно ли это необходимо? Это зависит от того, что вы планируете делать со своей коллекцией в методе.

Будет ли ваш метод генерировать исключение или что-то еще нежелательное из-за пустой коллекции? Вы перебираете свою коллекцию с foreach? Если это так, то наличие пустой коллекции не обязательно принесет вред, хотя это может противоречить вашим бизнес-правилам. Попытка перебрать коллекцию null явно отличается.

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

Answer 4

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

Со своей стороны, я бы проверил это внутри ToggleVisibility, потому что это делает код вызывающего абонента более чистым, и если вы вызываете функцию ToggleVisibility из 50 разных мест, у вас значительно меньше кода.

Answer 5

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

Answer 6

Если вы добавляете эти утверждения для тестирования и отладки, конечно, это имеет смысл.

В этих ситуациях вы хотите, чтобы вам говорили, когда дела идут не так, как вы ожидаете, что они всегда будут идти.

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