Припускаючи інтерфейс IReader, реалізацію інтерфейсу ReaderImplementation IReader та клас ReaderConsumer, який споживає та обробляє дані з читача.

public interface IReader
{
     object Read()
}

Впровадження

public class ReaderImplementation
{
    ...
    public object Read()
    {
        ...
    }
}

Споживач:

public class ReaderConsumer()
{
    public string location

    // constructor
    public ReaderConsumer()
    {
        ...
    }

    // read some data
    public object ReadData()
    {
        IReader reader = new ReaderImplementation(this.location)
        data = reader.Read()
        ...
        return processedData    
    }
}

Для тестування ReaderConsumer та обробки я використовую макет IReader. Тож ReaderConsumer стає:

public class ReaderConsumer()
{
    private IReader reader = null

    public string location

    // constructor
    public ReaderConsumer()
    {
        ...
    }

    // mock constructor
    public ReaderConsumer(IReader reader)
    {
        this.reader = reader
    }

    // read some data
    public object ReadData()
    {
        try
        {
            if(this.reader == null)
            {
                 this.reader = new ReaderImplementation(this.location)
            }

            data = reader.Read()
            ...
            return processedData    
        }
        finally
        {
            this.reader = null
        }
    }
}

У цьому рішенні глузування вводить фразу if для виробничого коду, оскільки лише макетний конструктор постачає екземпляри інтерфейсу.

Під час написання цього повідомлення я усвідомлюю, що блок "спроб нарешті" дещо не пов'язаний, оскільки він може управляти користувачем, що змінює місце розташування під час виконання програми.

В цілому він смердючий, як з цим можна впоратися краще?

Замість ініціалізації читача зі свого методу перемістіть цей рядок

{
    this.reader = new ReaderImplementation(this.location)
}

У конструктор без параметрів за замовчуванням.

public ReaderConsumer()
{
    this.reader = new ReaderImplementation(this.location)
}

public ReaderConsumer(IReader reader)
{
    this.reader = reader
}

Не існує такого поняття, як "макетний конструктор", якщо ваш клас має залежність, яку він потребує для роботи, то конструктору слід або надавати цю річ, або створювати її.

Вам потрібен лише один конструктор:

public class ReaderConsumer()
{
    private IReader reader = null

    public string location

    // constructor
    public ReaderConsumer(IReader reader)
    {
        this.reader = reader;
    }

у виробничому коді:

var rc = new ReaderConsumer(new ReaderImplementation(0));

у вашому тесті:

var rc = new ReaderConsumer(new MockImplementation(0));

Подивіться на введення залежностей та інверсію управління

І Еван, і RubberDuck мають відмінні відповіді. Але я хотів би згадати ще одну область, яку слід вивчити, яка є вприскуванням залежності (DI) та інверсією управління (IoC). Обидва ці підходи переміщують проблему, яку ви відчуваєте, у рамку / бібліотеку, щоб вам не довелося хвилюватися з цього приводу.

Ваш приклад простий і швидко не обходиться, але, неминуче, ви збираєтеся будувати на ньому, і ви закінчитеся з тоннами конструкторів або підпрограм ініціалізації, схожими на:

var foo = новий Foo (новий Bar (новий Baz (), новий Quz ()), новий Foo2 ());

За допомогою DI / IoC ви використовуєте бібліотеку, яка дозволяє вам прописати правила відповідності інтерфейсів реалізаціям, а потім просто скажіть "Дайте мені Foo", і він розробив, як прокласти все це.

Там є дуже багато дружніх контейнерів IoC (як їх називають), і я рекомендую поглянути на них, але, будь ласка, вивчіть, оскільки дуже багато варіантів.

Простим для початку є:

http://www.ninject.org/

Ось список для вивчення:

http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx