Guard классы — использовать или нет?

в 6:46, , рубрики: .net, C#, guard, Проектирование и рефакторинг, Совершенный код

На днях мне довелось делать довольно крупные изменения в одном C# проекте — удаление сторонней сборки. Самое "замечательное", что львиную долю времени я потратил на изменение мест, где использовались helper'ы из этой сборки (так сказать бонус к основной функциональности).

Helper'ы такого вида:

Guard.ArgumentNotNull(myobject, "myobject");

Такие классы встречаются очень часто, они могут оформляться в common libraries и кочевать из проекта в проект. Но нужны ли они? Распространенное мнение, что подобные guard'ы уменьшают количество строк кода и увеличивают ясность, но, как по мне, это очень субъективное мнение. Вот пример:

class Manager(IEventProvider eventProvider, IDataSource dataSource)
{
    Guard.ArgumentNotNull(eventProvider, "eventProvider");
    Guard.ArgumentNotNull(dataSource, "dataSource");

    this.eventProvider = eventProvider;    
    this.dataSource = dataSource;    
}

class Manager(IEventProvider eventProvider, IDataSource dataSource)
{
    if (eventProvider == null)
        throw new ArgumentNullException("eventProvider");

    if (dataSource == null)
        throw new ArgumentNullException("dataSource");

    this.eventProvider = eventProvider;    
    this.dataSource = dataSource;    
}

Да количество строк кода больше, но пострадала ли ясность? Нет.

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

Интересное рассуждение на эту тему есть в блоге Марка Симана.

А что вы думаете?

P.S. Есть еще code contracts, которые в самом простом варианте могут использоваться для подобного рода проверок.

Автор: Lardite

Источник

Поделиться

* - обязательные к заполнению поля