这是一种设计模式吗？它有一个通用名称吗？答案

【问题标题】：Is this a design pattern and does it have a common name?这是一种设计模式吗？它有一个通用名称吗？
【发布时间】：2011-12-07 16:54:30
【问题描述】：

我有一个只有接口和基本对象的库，我们称之为 API。 API 有一些已知的实现，它们的数量可能会根据应用程序的需要而增加。应用程序一次只能使用一种实现。我有另一个库，我们称之为 PROXY，它提供 API 库的基本实现，并将逻辑委托给 API 的实际实现。真正的实现由配置提供，PROXY 库负责创建适当的真实类并包装它们。这个想法是在我的代码中使用 API 和 PROXY 库，这样我就可以在不重新编译应用程序的情况下更改实现 - 只需更改配置并在类路径中提供真正的实现库。这是 C# 中的示例代码：

API：

public interface IFoo
{
    void Bar();
}

代理：

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 来包裹真正的实现。如果整个方法有一个特定的名称，我会更感兴趣？

【问题讨论】：

名字里有什么？
这将帮助我为我将编写的库命名一个合理的名称，我在这里称之为 PROXY，并将帮助我更好地解释我的想法。
也可以根据使用情况来命名。如果 PROXY 是为了测试而创建的，您可以将其称为测试替身或假实现。
我的目的是在生产项目中使用它作为更新的一部分。作为客户部署和批准的项目，我不能使用 DI 和其他东西，并且不是为使用 DI 而设计的。我需要一些组件更容易维护，所以我打算使用这里描述的方法。每次更新一个组件，我只替换组件库和更改配置，而不重新部署整个应用程序。幸运的是，可以不费吹灰之力地隔离 API，这是一种更易于维护的潜在投资。

标签： design-patterns

【解决方案1】：

这不是使用装饰器模式的原因有很多，最重要的是意图。

这是一个代理。一般是代理模式

为要控制的另一个对象提供代理或占位符访问它

您使用它来动态加载您的实现并因此与基于配置的实现松散耦合这一事实也使其类似于依赖注入。您的版本不同之处在于中间有一个代理对象。相反，如果您的客户持有对 RealFoo 的引用，但该引用是通过您所说的那种机制获得的，那么这将更接近于依赖注入。

【讨论】：

谢谢，看来我并没有把它命名为proxy 弄错。

【解决方案2】：

我将 IoC/DI 用于完全相同的事情，并将 Castle Windsor 用作我的 IoC 容器。

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

【讨论】：

是的，它有点像Inversion of Control，但比 DI 更麻烦、更不灵活。它仍然让我发痒，我该如何命名它。

【解决方案3】：

我认为您将代理模式与某种工厂方法模式混合在一起。

在普通代理模式中，代理对象本身不会创建主要目标。但是，一些工厂类应该创建目标类型的对象，创建目标实例并将其传递给代理实例，最后返回代理。

还有不同的方法可以创建代理对象。以 Castle Dynamic Proxy 为例，它旨在提供 ASPECTS。

【讨论】：

是的，我可能混合了你提到的模式。但是我不能使用普通的 DI，请参阅我对这个问题的最后评论，所以我采用了我描述的方法。
我不太明白你的问题。您是在寻找模式的名称还是在寻找特定问题的解决方案？
主要是为了它的名字。我已经成功地将它用作我的案例的解决方案，但它让我有点困扰，因为我称之为proxy。无论如何，这不是紧急问题。
我不同意“在普通代理模式中，代理对象本身不会创建主要目标”。此用法是 GoF 的“设计模式”中的代理部分中列出的实现示例之一。