这是适配器还是代理？

编程问答 2022-04-24

问题描述

您使用具有静态类 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（您不被允许，您无权访问数据库）。

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

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

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

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

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

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

它看起来像一个Adapter，因为它适配了通过IUserDataAccess接口调用的UserDataAccess

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

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

解决方法

这既不是适配器也不是代理设计模式。

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

由于 OP 中提到的原因，可以解除代理：只不过是从 UserDataAccessProxyOrAdapter 到 UserDataAccess 的直接传递。无需远程调用，无需延迟实例化成本，无需访问控制，无需采取任何额外措施。

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

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

adapterc#c#compositioncompositioncompositiondesign-patternsproxy-pattern