Битва между TDD / Injection и сокрытием информации - возможный компромисс? - PullRequest
2 голосов
/ 23 февраля 2011

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

public class ClassThatUseInjection
{
    private readonly SomeClass _injectedClass;

    public ClassThatUseInjection(): this(new SomeClass()) {}

    internal ClassThatUseInjection(SomeClass injectedClass)
    {
        _injectedClass = injectedClass;
    }
}


public class SomeClass
{
    public object SomeProperty { get; set; }
}

Моя идея заключалась в том, что, поскольку пустой ctor не делает ничего, кроме пересылки с новым экземпляром, мое преступление не так уж и плохо.Как вы думаете?Это слишком вонючий?

С уважением, Мортен

Ответы [ 3 ]

3 голосов
/ 23 февраля 2011

Я думаю, что все в порядке. Фактически, то, что вы делаете с введением класса, это инъекция зависимости и практическое использование принципа Открыто / Закрыто.
Я даже не вижу никакого вреда в превращении этого внутреннего ctor в публичный.
Моя проблема с этим всегда в том, что я не хочу заставлять других создавать экземпляр внедренного класса, следовательно, ctor по умолчанию. Но если они хотят создать экземпляр, они могут пойти дальше и сделать это.

На заметку: IMHO, вы должны использовать интерфейс вместо класса, в противном случае, я не вижу большого преимущества в передаче этого класса в первую очередь ...

1 голос
/ 23 февраля 2011

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

ДжиммиУ Богарда хорошая запись здесь

1 голос
/ 23 февраля 2011

хотел, чтобы этот черный ход (в некоторой степени) был невидим для посторонних

Сделать это internal успешно, IMO.

Недостатком является то, что он помещает ваши тесты в одну сборку.

См. Также Скрыть открытый метод, используемый для помощи в тестировании сборки .NET о том, как скрыть публичные методы, если ваши тесты находятся во внешней сборке.


Редактировать: то, что вы сделали, особенно уместно, если SomeClass является логически внутренним ... если это деталь реализации, которую не нужно / не нужно показывать в открытом интерфейсе сборки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...