时间戳

首页 > 解决方案 > 这是适配器还是代理？

c# - 这是适配器还是代理？

问题描述

您在具有静态类的旧版应用程序上工作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);
   }
}

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

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

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

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

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

标签： c#design-patternsadaptercompositionproxy-pattern

解决方案

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

适配器很容易被解除，因为适配器的 API 与它所适应的对象的 API 不同。两者都IUserDataAccess共享UserDataAccess相同的 API: AddUser(User user)，这排除了适配器模式。

由于 OP 中提到的原因，代理可以被解雇：没有什么比从UserDataAccessProxyOrAdapterto的直接传递更重要的了UserDataAccess。没有远程调用，没有延迟实例化成本，没有访问控制，根本没有采取额外的行动。

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

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

推荐阅读