Рекомендации по IoC и интерфейсам - PullRequest
Новая
       35

Рекомендации по IoC и интерфейсам

0 голосов
/ 02 декабря 2008

Я экспериментирую с 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?

1 Ответ

0 голосов
/ 02 декабря 2008

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

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

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

...