Is this an Adapter or a Proxy?

Question

You work on a legacy app which has a static class UserDataAccess:

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

which is used by a UserService class:

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

You need to add unit tests for the UserService class, but you cannot modify the UserDataAccess (you are not allowed, you do not have access to the DB).

A good solution is to create an interface and inject into UserService:

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

and add an implementation which delegates the call to the static class:

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

My question is, is this a Proxy or an Adapter?

Proxy is supposed to add some functionality. Can the access to the static resource be considered a functionality?

It looks like an Adapter because it adapts the UserDataAccess to be called through the IUserDataAccess interface

What is the correct reasoning and why?

EDIT: This is from this refactoring test, specifically at this step: https://youtu.be/U3QvTaw224o?t=944

Answer 1

This is neither an Adapter nor a Proxy design pattern.

Adapter can be dismissed easily because an Adapter's API differs from the API of the object it adapts. Both IUserDataAccess and UserDataAccess share the same API: AddUser(User user), which rules out the Adapter pattern.

Proxy can be dismissed for the reason mentioned in the OP: there is nothing more than a direct passthrough from UserDataAccessProxyOrAdapter to UserDataAccess. No remote call, no deferral of instantiation cost, no access control, no additional action taken at all.

We would not want to call this simple example a Proxy design pattern, because that would imply every composition is a Proxy, which would devalue the pattern entirely.

But, do note that proxy is also a general English word; so while it doesn't make sense to name this example a Proxy design pattern, calling it a proxy based on the broader dictionary definition could be valid. I'm not sure whether that was the author's intent or not.