2015-01-02 1 views
1

с помощью конструктора инъекции, зависимость получает инъекции потребителю, как это (по крайней мере, я надеюсь, я правильно понял):пункт охраны и Нуль шаблон объекта в Dependency Injection и С #

public class SomeConsumer 
{ 
    private IDependency someDependency; 
    public SomeConsumer(IDependency someDependency) 
    { 
     if (someDependency != null) 
     { 
      this.someDependency = someDependency; 
     } 
     else 
     { 
      throw new ArgumentNullException("someDependency"); 
     } 
    } 

    public void Baz() 
    { 
     someDependency.DoSomething(); 
    } 
    (...) 
} 

Если бы я использовать шаблон Null Object for IDependency, мне нужно предложение охраны? Или неправильно вводить нулевой объект?

UPDATE: Для уточнения, давайте предположим, что у меня есть классы и интерфейсы, как это:

public interface IDependency 
{ 
    void DoSomething(); 
} 

public class NullDependency : IDependency 
{ 
    public void DoSomething() 
    { 
     //Do nothing... 
    } 
} 

public class RealDependency : IDependency 
{ 
    public void DoSomething() 
    { 
     Console.WriteLine("Did something"); 
    } 
} 

public class Foo 
{ 
    public void Bar() 
    { 
     IDependency dependency = new NullDependency(); 
     SomeConsumer sc = new SomeConsumer(dependency); 
     sc.Baz(); 
    } 
} 

Могу ли я тогда безопасно удалить пункт охраны от SomeConsumer, делая его похожим на:

public class SomeConsumer 
{ 
    private IDependency someDependency; 
    public SomeConsumer(IDependency someDependency) 
    { 
     this.someDependency = someDependency; 
    } 

    public void Baz() 
    { 
     //if someDependency is a NullDependency, this does nothing 
     someDependency.DoSomething(); 
    } 
    (...) 
} 

Или я должен использовать предложение guard, потому что не могу быть уверенным, что null никогда не будет введено?

ответ

2

ИМХО я бы отказаться от оговорки сторожевую при следующих обстоятельствах:

  • SomeConsumer используется только внутри вашего продукта
  • Null модель объекта тщательно жил вашей командой и/или зависимость инъекции контейнера конфигурация

я бы, вероятно, не отказаться от оговорки охраны, если:

  • необходимость нулевой объект не документировано достаточно для целевой аудитории
  • SomeConsumer является частью открытого API, который будет использоваться разработчиками, которые не знают о нулевой шаблон объекта
  • Я хотел бы получить обратная связь с моим контейнером для инъекций с зависимостями к моменту, когда он инициирует SomeConsumer, что я допустил ошибку
0

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

Я бы, скорее всего, заменил отметку null с броском исключения или вообще удалил его. В настоящее время он ничего не делает, поскольку значение по умолчанию для переменной someDependency равно null.

+1

Я забыл добавить исключение, вопрос обновлен. – Thaoden

1

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

Вопрос не в том, является ли этот класс внутренним, либо нет. Вопрос в том, будете ли вы удостовериться, что во всех местах принимаются все меры для получения непустого значения при вызове конструктора? Даже если ваш ответ «да», следующий вопрос: почему вы тратите время и энергию на проверку?

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

В соответствующей заметке некоторые причины охраны (те, которые проверяют условия, отличные от нуля), часто являются причиной пересмотра дизайна. Вы можете найти эту статью интересной - Why do We Need Guard Clauses?