在 C# 中限制对枚举参数的访问的最佳做法
本文关键字：访问 最佳 参数 枚举 | 更新日期: 2023-09-27 18:36:06
考虑这个问题，这个问题String.Split重载，它接受StringSplitOptions枚举作为参数。
枚举本身是公共的，并且可以对包含 System 命名空间的所有内容进行访问，这不是不好吗？我的意思是，枚举完全特定于Split方法的选项，但它在其范围之外可用。
也许有更好的方法来对此进行建模，例如将枚举放在 String 类本身中，并使用 String.SplitOptions 访问它？我很少看到这种情况（我现在实际上不记得任何这种情况），所以我认为出于某种原因它不是首选。一般来说，我认为缩小事物的范围是一种最佳实践，因为可以这么说，通过在不正确的范围内使用类/成员可以降低出现问题的可能性。
我在这里使用 Split 作为示例，但Enum也只由我们代码库中的方法或类使用是很常见的。我通常像任何其他类一样在单独的 cs 文件中将枚举创建为公共类型，但我很想听到解决这个"问题"的其他方法。
更新：
我刚刚发现这篇文章用一个Folder类和一个Filter枚举来攻击这个确切的问题，但似乎再次违背了我认为在这种情况下更正确的内容（以某种方式将枚举放在类中）。ToddM的评论之一（我碰巧同意）指出：
。
但是，即便如此，我也觉得你的逻辑是错误的。您的主要投诉 反对将枚举嵌入到类中是因为它需要 太长，无法键入。考虑到 C# 趋于冗长，这并不是真的 一个合理的论点。在VS中，CTRL+SPACE是你的朋友。
从逻辑上讲，我觉得将枚举放在类中要多得多 正确。举个例子：什么是MyNameSpace.Filter？在哪里 它适用吗？我想这是您的命名空间的过滤器？不可能 告诉，特别是如果您的命名空间增长到包含数十个类。
现在考虑一下MyNameSpace.Folder.Filter - 在我看来，它远不止于此。 直观的是过滤器以某种方式、形状或形式应用于 文件夹类。实际上，可以使用 它自己的过滤器概念，其成员之一可能是"文件"。只 因为你在命名空间中引入了一个新类不会给出 您有权使用各种"帮助程序"类型污染该命名空间。 如果您是作为大型开发团队的一员进行开发的，您的风格 是，嗯，粗鲁。
。
enum是一个有趣的想法，以表明它的范围缩小，或者给它更好的语义。我以前使用过这个想法，以便在我开发的后编译器中同时具有错误代码和警告代码。这样，我可以使用相同的枚举名称Code嵌套在 Error 类或 Warning 类中。
另一方面，通常不鼓励使用公共嵌套类型。它们可能会让必须使用外部类名限定它们的客户端感到困惑。查看 MSDN 上的相关指南。一些相关的：
不要使用公共嵌套类型作为逻辑分组构造;为此请使用命名空间。
避免公开嵌套类型。唯一的例外是，嵌套类型的变量只需要在极少数情况下（如子类化或其他高级自定义方案）中声明。
如果嵌套类型可能在包含类型之外引用，则不要使用该类型。
例如，传递给类上定义的方法的枚举不应定义为类中的嵌套类型。
我相信在开发 StringSplitOptions 枚举以及 BCL 中的大多数其他枚举时都遵循了这些准则。
String.Split()是公开的，所以StringSplitOptions也必须是公开的。String 和 StringSplitOptions 都存在于 System 命名空间中。两者都有公共范围。两者都不是"在[对方]范围之外可用"。
原因是它会使使用嵌入式枚举的每次调用都更宽（类的名称成为强制性前缀）。
我个人不喜欢每次必须使用这个枚举时都必须使用ResultSetTransformer.ResultSetTransformerOptions，这会让我的行变得非常长。
但正如其他人指出的那样，我认为在类中嵌入枚举根本不是框架的标准，可能是出于这个原因。