Question

我经常遇到这样的模式：我有一个主类和几个较小的辅助类或结构。

我希望尽可能保持结构的名称。因此，当我有一个名为CarFinder的类时，它大量使用了一些内部仅（或主要）使用的特殊Key对象，我想调用该对象而不是Key }}。

一切都要删除所有额外的模糊，当我在阅读时尝试理解课程时，这会分散我的注意力。

当然，我不想用一个名为CarFinderKey的小助手类来污染剩下的代码 - 它很可能会发生冲突和混淆。

在一个完美的世界中，我希望有一个像Key这样的关键字，但由于这不存在，我可以想到以下选项：

使用internal to this namespace并将课程放在另一个项目中。

优势：完美的封装。

缺点：很多组织开销和不必要的复杂依赖。

注意：我不是在谈论真正庞大的自包含系统，这些系统无疑应该得到自己的装配。

将其放在不同的子命名空间中，例如internal

优势：易于实施。

缺点：在意外导入名称空间时仍然会污染。

将帮助程序类作为子类放在CarFinding.Internal。

优势不会在内部受到污染，甚至可以作为使用CarFinder

缺点必须将帮助程序类放在同一个文件中，或将其封装在外围文件中，并在其周围加CarFinder.Key。第一个文件使文件不必要很长，第二个只是觉得非常难看。

无论如何称之为public partial class

优势易于实施。

缺点在我看来，将 fuzz 添加到CarFinderKey。仍然不必要地污染命名，只是名字不太可能发生冲突。

建议的指南是什么？

Answer 1

就个人而言，我不介意CarFinderKey引起的额外“模糊”，这就是为什么：曾经在一个非常大的项目中工作，我们试图使用名称空间来消除名称歧义。

因此，当您扩展系统时，您可以非常轻松地在代码编辑器中打开10个选项卡，这些选项卡都名为“Key.cs”。这真的很不好玩。

Answer 2

基于意见。无论如何，我会：

尝试将其设为CarFinder的私有嵌套类，这通常会失败，因为Key需要传递给CarManager，你知道我的意思。不鼓励使用公共嵌套类。
我会将它放入一个名为Core的子命名空间，这是内部资源的通用名称。对我来说，Core是＆＃34;名称空间内部＆＃34;通过命名约定。
项目越大，您需要的名字越长。 CarFinderKey仍然是有效选项。

我永远不会为此创建额外的程序集。它感觉不对。

Answer 3

我多次遭遇同样的困境，并亲自使用（3）和（4）的变体。

（3）：我没有把嵌套的类/结构放在同一个文件中（如果它很小并且真的与父类绑定），也没有在partial ParentClass声明中使用单独的文件 - 唯一的缺点是它有一个更多级别的缩进，但我可以忍受。我也没有违反FxCop规则或其他建议的问题 - 毕竟，它们只是建议，而不是强制性的。但是很多人确实遇到了全部或部分问题，所以继续前进。

（4）：你已经描述了缺点。我要分享的是我如何克服它们。同样，它是个人的，也可能不喜欢它，但在这里它是。

首先，假设我们为密钥类使用单独的文件，并将类命名为CarFinderKey。

然后，内部 CarFinder类的代码文件，我们将以下行放在using部分的末尾（或任何内部）：

using Key = CarFinderKey;

这样，仅在CarFinder类代码文件内，需要CarFinderKey，我们只需将其称为Key，目标。同时我们保留所有优势，没有冲突。 Intellisence无任何问题。在VS2015中，灯泡甚至建议简化名称＆＃34;在任何地方找到CarFinderKey在该文件中。

Answer 4

您的决定应取决于您的设计。您的Key类真的只是CarFinders的关键，还是可以用来寻找摩托车或房屋等等。

着名的四人组规定的第一条规则之一就是“改变设计”。如果你真的认为在不久的将来你的钥匙也可以用来寻找房屋或摩托车，那么让你的钥匙舱私密而其他人不能使用钥匙也不是一个好主意。

由于您正在谈论私人助手类，我认为您的密钥仅对CarFinders有用。

如果是这种情况，并且您的设计要求Key仅对CarFinders有用，或者甚至可能：如果它的设计使其在CarFinders外部甚至无用，则Key类应该是CarFinders类的一部分。将此与您在CarFinders类中使用的简单整数相比较，您会在CarFinders类中将其声明为私有吗？

让您遇到一个大文件或部分定义的问题。从设计的角度来看，没有区别。对于编译器也没有区别。唯一的区别是必须阅读它的人。如果您认为您的类的用户很少需要读取您的密钥类的定义，那么最好在单独的文件中定义它。但是，如果您在阅读CarFinder类时经常需要阅读密钥类，则应尽可能轻松地访问密钥类。如果您的开发环境是面向文件而不是面向类，那么我认为在这种情况下，大文件的缺点不是必须在文件之间切换的缺点。

Answer 5

我会把课程和他们的帮助＆＃34;在他们自己的名称空间 MyNamespace.CarFinding ，

所以你有：

MyNamespace.CarFinding.CarFinder
MyNamespace.CarFinding.Key

我将把这个命名空间放在项目的子文件夹中。

这不会阻止在项目的其他地方使用内部帮助器类，但是从父命名空间可以将您的帮助器引用为 CarFinding.Key

建议使用C＃中的助手类来命名污染？

5 个答案: