这是Adapter还是Proxy？

Question

您使用的是具有静态类UserDataAccess的遗留应用程序

public static class UserDataAccess
{
     public static void AddUser(User user) 
     {
        // Insert user into DB
     }
}

它由UserService类使用：

public class UserService 
{
   public bool AddUser(string firstName, string lastName)
   {
      User user = ...
      UserDataAccess.AddUser(user);
   }
}

您需要为UserService类添加单元测试，但是您不能修改UserDataAccess (您不被允许，您没有访问DB的权限)。

一个好的解决方案是创建一个接口并注入到UserService中

public interface IUserDataAccess {
     void AddUser(User user);
}

并添加一个将调用委托给静态类的实现：

public class UserDataAccessProxyOrAdapter : IUserDataAccess 
{
   public void AddUser(User user) { 
       UserDataAccess.AddUser(user);
   }
}

我的问题是，这是一个代理还是一个适配器？

Proxy应该添加一些功能。对静态资源的访问可以被视为一种功能吗？

它看起来像一个适配器，因为它使UserDataAccess适合于通过IUserDataAccess接口调用

正确的推理是什么?为什么？

编辑:这来自这个重构测试，特别是在这一步：https://youtu.be/U3QvTaw224o?t=944

Answer 1

这既不是Adapter，也不是Proxy设计模式。

Adapter很容易被删除，因为Adapter的API与它所适配的对象的API不同。IUserDataAccess和UserDataAccess共享相同的接口：AddUser(User user)，它排除了适配器模式。

由于OP中提到的原因，Proxy可以被取消:除了从UserDataAccessProxyOrAdapter到UserDataAccess的直接直通之外，什么也没有。不需要远程调用，不需要延迟实例化成本，不需要访问控制，也不需要额外的操作。

我们不想将这个简单的示例称为代理设计模式，因为这意味着每个组合都是一个代理，这将使模式完全贬值。

但是，请注意，proxy也是一个常见的英语单词；因此，尽管将此示例命名为代理设计模式没有任何意义，但根据更广泛的字典定义将其称为代理可能是有效的。我不确定这是否是作者的意图。