naming-conventions - 命名包装类的经验法则

Question

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

不适合 RhinoMocks 隔离模型的类（例如 like DirectoryInfoor WindowsIdentity）
本机 Win API 方法（我通常将我需要的所有方法收集到一个类中，并将本机调用包装为类方法）

然后我发现自己附加了一个用“W”包装的类（表明它是一个包装器），所以我最终得到了DirectoryInfoW（而不是DirectoryInfoWrapper看起来相当冗长）。同样，我最终得到了名为NativeMethods.DuplicateTokenW.

在命名包装器类时要遵循什么好的经验法则？

score 20 · Accepted Answer

命名约定适用于您正在使用的团队。只要每个人都同意特定的约定，就可以了。

不过，我更喜欢更详细的版本，即DirectoryInfoWrapper，而不是有一个字母对不熟悉代码的人没有任何解释。但这只是我。

score 3 · Accepted Answer

我同意 aberrant80 ，如果每个人都同意您使用的约定，那么它会起作用。

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

一个更好的例子可能是包装一个 HttpRequest；定义一个 IRequest 来声明“这对我的应用程序很重要”，然后 Request、HttpRequestWrapper、Request 等将成为实现者。

因此，总而言之，尝试使用描述性、不过分冗长的接口名称。

score 0 · Accepted Answer

顺便说一句，我发现了一种更美观（对我而言）包装本机方法调用的方式：

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 的建议并明确调用我的包装器包装器。

score 0 · Accepted Answer

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

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

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

naming-conventions - 命名包装类的经验法则

4 回答 4

Related

Reference