Вы кое-что упускаете: вполне разумно, чтобы объект Mailbox зависел от интерфейса, предоставляемого во время выполнения. «Не зависеть от служб времени выполнения» правильно, поскольку у вас не должно быть зависимостей во время компиляции.

Поскольку единственной зависимостью является интерфейс, вы можете использовать контейнер IoC, например StructureMap , Unity и т. Д., Чтобы передать вашему объекту тестовый экземпляр, а не экземпляр среды выполнения.

В конце ваш код для AutoRespondingMailbox может выглядеть следующим образом:

public class AutoRespondingMailbox {
    private IEmailSender _sender;

    public AutoRespondingMailbox(IEmailSender sender){
        _sender = sender;
    }

    public void addMessage(Message message){
        String response = getAutoResponse();
        _sender.Send(response);
}

Обратите внимание, что этот класс действительно от чего-то зависит, но он не обязательно предоставляется средой выполнения - для модульного теста вы может легко предоставить фиктивный IEmailSender, который записывает в консоль и т. д. Кроме того, если ваша платформа изменится или требования изменятся, вы можете легко предоставить при создании другой IEmailSender, который использует другую методологию, чем оригинал. Это является причиной позиции "предельных зависимостей".

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