这是哪种设计模式?

6
在当前的(C#)项目中,我们有一个包含非接口连接对象的第三方程序集。使用IoC等技术,我们可以将这个具体实例注入到我们的代码中,但是这证明是一个噩梦来进行单元测试等。我们正在使用MoQ作为我们的模拟框架,因此最好能够使用接口来工作,而不想使用类似Moles这样的东西,因为我们想尽量减少技术。
如果我们创建一个接口来模仿第三方连接对象所需的功能,然后创建一个实现该接口的实现者,其中包含第三方对象的实例,那么这将允许我们的代码使用接口,我们的IoC和单元测试都将很高兴。然而,在一次讨论中,我们围绕着它到底是哪种设计模式而打转!
因此,问题是,“上述情况并在下面的代码中说明是否是:”
  1. 适配器因为我们正在提供对现有功能的包装器。
  2. 代理因为我们正在提供对其他东西的接口。
  3. 外观因为作为过程的一部分,我们将为较大对象提供一个简化的接口。

 

namespace ExampleCode
{
    public interface IConnector
    {
       void Open();
    }

    public class ConnectorWrapper : IConnector
    {
       ThirdPartyConnector _instance;

       public ConnectorWrapper(ThirdPartyConnector instance)
       {
          _instance = instance;
       }

       void Open()
       {
         _instance.Open();
       }
    }
}
2个回答

2

快速回答,门面模式。

从我的GoF来看:

适配器:

将一个类的接口转换成客户端所期望的另一种接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

看起来并不是出于互操作性的原因,这里要说不。

代理:

为另一个对象提供一个替身或占位符以控制对它的访问。

也不太对,这不是一个访问问题。

门面模式:

为子系统中的一组接口提供一个统一的接口。门面模式定义了一个更高层次的接口,这使得子系统更易于使用。

这看起来更像。您可以使用接口来抽象不同的实现、测试和应用程序。


1

这肯定是一个外观。我经常这样做来简化过度设计的API。


你认为这只是一个外观,还是一个同时也是适配器或代理的外观? - Paul Hadfield
@Paul - 这取决于您简化示例代码的程度。通常还需要一个适配器来与需要特定接口的现有类一起使用。这是这种情况吗? - ChaosPandion
不,情况并非如此,引入接口是为了在单元测试中方便模拟,第三方对象本身并没有实现任何接口。感谢您的评论。 - Paul Hadfield

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接