c# - 推荐的方法来防止C#中的帮助程序类污染命名？

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

我想保持这些结构的名称尽可能整洁。因此，当我有一个称为CarFinder的类，该类大量使用仅在内部(或主要在内部)使用的某些特殊Key对象时，我想将该对象称为Key而不是CarFinderKey。

当我尝试在阅读类(class)时理解所有内容时，所有消除我分心的多余毛茸茸的东西。

当然，我不想使用一个名为Key的小型帮助程序类来污染其余的代码-它很可能会发生冲突和困惑。

在理想的情况下，我希望拥有一个像internal to this namespace这样的关键字，但是由于不存在，因此我想到了以下选项:

使用internal并将类放在另一个项目中。

优势:完美的封装。

劣势:大量的组织开销和不必要的复杂依赖关系。

注意:我并不是在谈论真正的大型自包含系统，这些系统无疑值得其自己组装。

将其放在其他子命名空间中，例如CarFinding.Internal

优势:易于实现。

缺点:当意外导入 namespace 时，它仍然会污染。

将帮助程序类作为子类放在CarFinder中。

的优势不会在内部造成污染，甚至可以通过CarFinder.Key提升为暴露于外界的公共(public)帮助结构。

缺点必须将帮助程序类放在同一文件中，或将其包装在带有public partial class的外部文件中。第一个使文件不必要的时间很长，第二个感觉真的很丑。

仍然称它为CarFinderKey

的优势易于实现。

劣势我认为CarFinder增加了太多的模糊性。仍然不必要地污染名称，只是使用不太可能发生冲突的名称。

推荐的准则是什么？

最佳答案

这是基于意见的。无论如何，我会:

尝试使其成为私有(private)的CarFinder嵌套类，该类通常会失败，因为Key需要传递给CarManager，您知道我的意思。不鼓励使用公共(public)嵌套类。

我会将它放到一个名为Core的子命名空间中，这是内部内容的通用名称。对我来说，Core是命名惯例的“内部命名空间”。

项目越大，所需的名称就越长。 CarFinderKey仍然是有效的选项。

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