Передовые практики IoC и интерфейсов

Я экспериментирую с IoC на пути к TDD, возясь с существующим проектом. Вкратце, мой вопрос заключается в следующем: каковы лучшие практики использования IoC, когда интерес представляют общедоступные и непубличные методы?

Есть два класса:

public abstract class ThisThingBase
{
    public virtual void Method1() {}
    public virtual void Method2() {}

    public ThatThing GetThat()
    {
        return new ThatThing(this);
    }
    internal virtual void Method3() {}
    internal virtual void Method4() {}
}

public class Thathing
{
    public ThatThing(ThisThingBase thing)
    {
        m_thing = thing;
    }
    ...
}

ThatThing делает некоторые вещи, используя свою ссылку ThisThingBase для вызова методов, которые часто перегружаются потомками ThisThingBase.

Method1 и Method2 являются общедоступными. Method3 и Method4 являются внутренними и используются только ThatThings.

Я хотел бы протестировать ThatThing без ThisThing и наоборот.

Изучая IoC, моей первой мыслью было определить интерфейс IThing, реализовать его с помощью ThisThingBase и передать конструктору ThatThing. IThing может быть общедоступным интерфейсом, который могут вызывать клиенты, но он не включает Method3 или Method4, которые также нужны ThatThing.

Должен ли я определить второй интерфейс - возможно, IThingInternal - для этих двух методов и передать ОБА интерфейса в ThatThing?


interface tdd inversion-of-control
person n8wrl    schedule 02.12.2008    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Проблема с контейнерами IoC заключается в том, что они не могут контролировать жизненный цикл объектов. Почему фабричный метод в ThisThingBase? Если бы было возможно иметь конструкцию контейнера IoC Thatthing, это повысило бы тестируемость.

На примере сложно сказать, но, возможно, у вас есть ненужная связь между Thatthing и ThisThingBase.

Интерфейсы могут быть хорошими, но иногда достаточно виртуальных методов в классе, от которого вы зависите, чтобы включить тестирование.

person Cristian Libardo    schedule 02.12.2008
comment
Отличное замечание о фабрике ThatThing - на самом деле она есть, но я беспокоился, что мой пост становится слишком длинным. Может, мне не стоило выдумывать всю эту-то штуку. Проект предназначен для радиолюбителей и сопряжения с физическими устройствами. Я думал, что это слишком. - person n8wrl; 02.12.2008
comment
Проблема в том, что эти вещи очень сложно обсуждать абстрактно, потому что вариантов очень много, и какие из них имеют смысл, зависит от деталей. Поэтому я бы посоветовал вам на самом деле основывать свой вопрос на вашем реальном коде. - person Ilja Preuß; 02.12.2008