Это шаблон дизайна, и у него есть общее название?

Question

У меня есть библиотека только с интерфейсами и базовыми объектами, назовем ее API. API имеет несколько известных реализаций, число которых может увеличиться для нужд приложения. Приложение может использовать только одну реализацию за раз. У меня есть другая библиотека, давайте назовем ее PROXY, которая обеспечивает базовую реализацию библиотеки API, и она делегирует логику реальной реализации API. Реальная реализация обеспечивается конфигурацией, а библиотека PROXY заботится о создании соответствующих реальных классов и их обертывании. Идея состоит в том, чтобы использовать библиотеки API и PROXY в моем коде, чтобы я мог изменять реализации без перекомпиляции приложения - просто изменяя конфигурацию и предоставляя реальную библиотеку реализации в classpath. Вот пример кода в C #:

API:

public interface IFoo
{
    void Bar();
}

PROXY:

public class Foo : IFoo
{
    private IFoo _realFoo;

    public Foo()
    {
        _realFoo = ...; // Assume reading the config and creating the real implementation with reflection here.
    }

    void Bar()
    {
        _realFoo.Bar();
    }
}

Реальная реализация:

public class RealFoo : IFoo
{
    void Bar()
    {
        // Some specific logic 
    }
}

Я предполагаю, что класс Foo выше использует Decorator Pattern, чтобы обернуть реальную реализацию. Меня больше интересует, если у всего подхода есть конкретное имя?

Answer 1

Это не использование шаблона Decorator по ряду причин, наиболее важно в намерениях.

Это прокси. Обычно шаблон прокси

Предоставляет суррогат или заполнитель для другого объекта для контроля доступ к нему

Тот факт, что вы используете его для динамической загрузки вашей реализации и, следовательно, имеет слабую связь с вашей реализацией, основанной на конфигурации, также делает ее похожей на внедрение зависимостей. Ваша версия отличается тем, что у вас есть прокси-объект в середине. Если вместо этого у вашего клиента есть ссылка на RealFoo, но эта ссылка была получена с помощью механизмов, о которых вы говорите, то это будет более точно соответствовать внедрению зависимости.

Answer 2

Я думаю, что вы смешали шаблон Proxy с каким-то шаблоном Factory Method.

В простом шаблоне прокси объект прокси не создает саму главную цель. Но вместо этого некоторый класс Factory, который должен создавать объекты целевого типа, создает целевой экземпляр, передает его в экземпляр прокси и, наконец, возвращает прокси.

Существуют также разные способы создания прокси-объектов. взгляните на Castle Dynamic Proxy, например, - Это предназначено для обеспечения АСПЕКТОВ.

Answer 3

Я использую IoC / DI для той же вещи и Castle Windsor, что и мой контейнер IoC.

http://martinfowler.com/articles/injection.html