Rule of thumb for naming wrapper classes

jpoh picture jpoh · Jul 24, 2009 · Viewed 16.2k times · Source

I find myself creating a significant number of wrapper classes, purely because I want to mock out the behaviour of

  • Classes that don't lend themselves well to the RhinoMocks isolation model (for instance like DirectoryInfo or WindowsIdentity)
  • Native Win API methods (I normally collect all the methods I need into a single class and wrap the native calls as a class method)

I then find myself appending the class that is wrapped with a 'W' (to indicate that it's a wrapper) and so I end up with DirectoryInfoW (as opposed to DirectoryInfoWrapper which seems rather verbose). Similarly, I end up with wrapped native methods called NativeMethods.DuplicateTokenW.

What would be a good rule of thumb to follow when naming wrapper classes?

Answer

aberrant80 picture aberrant80 · Jul 24, 2009

Naming conventions are whatever works for the team that you're working with. As long as everyone's ok with a particular convention, then it's ok.

I tend to prefer the more verbose version though, i.e. DirectoryInfoWrapper, rather than having a single letter that doesn't explain anything to anyone who's not familiar with the code. But that's just me.