建议使用C#中的辅助类来命名污染？

Question

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

我想尽可能地保持结构的名称.因此,当我有一个被调用的类时,CarFinder它大量使用了一些仅在内部使用(或主要)的特殊Key对象,我想调用该对象Key而不是CarFinderKey.

当我在阅读时尝试理解课程时,一切都可以消除所有让我分心的额外模糊.

当然,我不想用一个被调用的小帮助程序来污染剩下的代码Key- 它很可能会发生冲突和混淆.

在一个完美的世界里,我本来希望有一个像这样的关键字internal to this namespace,但由于不存在,我可以想到以下选项:

---

1. 使用internal并将该类放在不同的项目中.

优点:完美的封装.

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

注意:我不是在谈论真正大型的自包含系统,这些系统无疑应该得到自己的装配.

---

2. 把它放在一个不同的子命名空间中,比如 CarFinding.Internal

优点:易于实施.

缺点:在意外导入命名空间时仍然会污染.

---

3. 将辅助类作为子类CarFinder.

优势不会在内部污染,甚至可以作为暴露于外部世界的公共帮助结构进行推广CarFinder.Key

缺点必须将帮助程序类放在同一个文件中,或将其封装在public partial class周围的外部文件中.第一个文件使文件不必要很长,第二个只是觉得非常难看.

---

4. 无论如何称之为 CarFinderKey

优势易于实施.

缺点添加在我看来太模糊到CarFinder.仍然不必要的污染命名,只是一个不太可能发生冲突的名字.

---

建议的指导原则是什么？

Answer 1

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

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

Answer 2

这是基于意见的.无论如何,我会:

1. 尝试使它成为一个私有的嵌套类CarFinder,它通常会失败,因为Key需要传递给CarManager你,你知道我的意思.不鼓励使用公共嵌套类.

2. 我会把它放入一个名为子命名空间的子命名空间中Core.对我来说,Core命名约定是"命名空间内部".

3. 项目越大,您需要的名称越长.CarFinderKey仍然是一个有效的选择.

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

Answer 3

我多次遇到同样的困境,并亲自使用(3)和(4)的变体.

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

(4):你已经描述了缺点.我要分享的是我如何克服它们.同样,它是个人的,可能或可能不喜欢它,但在这里它是.

首先,假设我们为密钥类使用单独的文件并命名该类CarFinderKey.

然后,在类的代码文件中CarFinder,我们将以下行放在该部分的末尾(或任何内部)using:

using Key = CarFinderKey;

这样一来,只有内部的CarFinder类代码文件,随时随地CarFinderKey需要,我们就可以将它简称为Key,究竟是什么目的.同时我们保留所有优势,没有冲突.Intellisence无任何问题.在VS2015中,灯泡甚至会建议CarFinderKey在文件内找到的任何地方"简化名称" .