命名包装类的经验法则

时间:2009-07-24 03:48:09

标签: naming-conventions wrapper

我发现自己创建了大量的包装类,纯粹是因为我想模仿

的行为
  • 不适合RhinoMocks隔离模型的类(例如DirectoryInfoWindowsIdentity
  • Native Win API方法(我通常会将所需的所有方法收集到一个类中,并将本机调用作为类方法包装)
然后我发现自己附加了一个用'W'包装的类(表示它是一个包装器),所以我最终得到DirectoryInfoW(而不是DirectoryInfoWrapper,这似乎相当冗长)。同样,我最终使用名为NativeMethods.DuplicateTokenW的包装本机方法。

命名包装类时要遵循的经验法则是什么?

4 个答案:

答案 0 :(得分:17)

命名约定适用于您正在使用的团队。只要每个人都有一个特定的约定,那就没关系。

我倾向于选择更详细的版本,即DirectoryInfoWrapper,而不是只有一封不向任何不熟悉代码的人解释任何内容的字母。但那只是我。

答案 1 :(得分:3)

我同意异常80,如果大家都同意你正在使用的惯例,那么它就会起作用。

我个人更喜欢使用较短且描述类目的的名称。至少在界面层面。如果您使用的是模拟框架,那么IDirectory或IDirectoryInfo将是一组不错的名称,而DirectoryInfoW或DirectoryInfoWrapper将是一个接口实现者。

更好的例子可能是包装HttpRequest;定义一个IRequest来声明'这是对我的应用程序很重要',然后Request,HttpRequestWrapper,Request等将是实现者。

因此,总而言之,请尝试使用描述性的,非过于冗长的界面名称。

答案 2 :(得分:0)

就像旁注一样,我发现了一种更美观(对我来说)包装本机方法调用的方法:

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();

            ...
        }
}

即。通过在私有嵌套类中封装本机方法调用来避免名称冲突。

对于包装类命名问题没有'好'的解决方案,我可能会选择aberrant80的建议,并明确地调用我的包装器包装器。

答案 3 :(得分:0)

如果您使用的是C ++,则可以使用命名空间,然后重复使用相同的类名。例如:

namespace WrapperNamespace
{
    class MyClass {...};
}

namespace InternalNamespace
{
    class MyClass {...};
}