Rule of thumb for naming wrapper classes

Question

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 1

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.

Answer 2

I'll agree with aberrant80 , if everyone agrees with the convention you are using, then it'll work.

I personally prefer using names that are shorter and descriptive to the class's purpose. At least at the interface level. If you're using a mock framework, then IDirectory or IDirectoryInfo would be a decent set of names, while DirectoryInfoW or DirectoryInfoWrapper would be an interface implementer.

A better example might be wrapping an HttpRequest; define an IRequest to state 'this is what is important to my application', then Request, HttpRequestWrapper, Request, etc would be implementers.

So, to summarize, try and use descriptive, non-overly-verbose interface names.

Answer 3

Just as a side note, I found a more aesthetically pleasing (well, to me) way of wrapping native method calls:

public class NativeMethods
{
        // made virtual so that it can be mocked - I don't really want
        // an interface for this class!
        public virtual bool RevertToSelf()
        {
            return WinApi.RevertToSelf();
        } 

        ...

        private static class WinApi
        {
            [DllImport("advapi32.dll")]
            public static extern bool RevertToSelf();

            ...
        }
}

i.e. avoid name collision by encapsulating native method calls in a private nested class.

No 'good' solution to the wrapper class naming issue though, I'd probably go with aberrant80's suggestion and explicitly call my wrappers wrappers.