0

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

jaco0646
  • 15,303
  • 7
  • 59
  • 83
Don Box
  • 3,166
  • 3
  • 26
  • 55

1 Answers1

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.

jaco0646
  • 15,303
  • 7
  • 59
  • 83
  • I was thinking it can be a Proxy maybe that it controls the access (albeit in a very limited way) to the static instance of `UserDataAccess`? A remote proxy for example only serializes calls and deserializes responses. – Don Box Jun 16 '21 at 12:10
  • 1
    There is a powerful incentive to label every (trivial) piece of code with a pattern name: famous names lend legitimacy to the code. Resist this temptation. It incentivizes the devaluation of patterns. – jaco0646 Jun 16 '21 at 13:52
  • I was only trying to see if the guy is correct or not. He said it's a Proxy pattern – Don Box Jun 18 '21 at 12:59