内部类应该放在哪里？

Question

假设我正在创建一个名为Jokes的新库，它有一个小的API。为了使我的API易于使用，我将其放在基本命名空间中：

namespace Jokes

    --> public interface IJoker
        --> string Joke();

    --> public static class Jokers
        --> public static IJoker NewSlapstickJoker()
        --> public static IJoker NewAbsurdJoker()
        --> public static IJoker NewCheesyJoker()

Jokers的实现是内部的：

--> internal class SlapstickJoker : IJoker
--> internal class AbsurdJoker : IJoker
--> internal class CheesyJoker : IJoker

---

现在我非常确定以下是需要遵循的准则（请问有人可以验证一下吗？）：

• 不要从根命名空间访问子命名空间中的类型。（例如，System 中的类型不知道 System.Drawing 中的类型）。

这个准则适用于内部类吗？为了避免污染我的根命名空间，我想将我的内部类放在 Jokes.Internal 中。这意味着 Jokes 命名空间中的类型（Jokers）会知道子命名空间 Jokes.Internal 中的类型。这样可以吗？

- xofz

---

Jokers类是一个小丑工厂吗？如果是，也许应该更改名称。 - Mitch Wheat

Answer 1

为了避免污染我的根命名空间，我希望将我的内部类放在Jokes.Internal中。 这意味着Jokes命名空间中的类型（Jokers）将知道子命名空间Jokes.Internal中的类型。这样可以吗？

是的，没问题。不将类型放入命名空间依赖于“子”命名空间中的类型的主要指导方针实际上更多地涉及公共API。仅由内部类型使用的内部类和命名空间实际上是实现细节，并且不受任何此类指导方针的影响。

我建议您坚持一致的做法，以使其更加合理。使用Internal命名空间似乎很合理（尽管我可能会使用命名空间Jokes.Implementations）。

此外，考虑到您的Jokers类正在构造新实例，它基本上是一个工厂。 您可能需要考虑像JokerFactory这样更明显的名称。 对我来说，Jokers会暗示类中包含一组Joker实例，而不是一组工厂方法。

- Reed Copsey

Answer 2

命名空间有几个关键作用：

1. 它们有助于避免不同开发人员和组织创建和共享的类型之间的命名冲突。
2. 它们有助于将类型组织成组，以便更容易理解它们的功能以及哪些类型彼此相关或一起使用。

现在回答你具体的问题。从外部命名空间引用内部命名空间中的类型并不是非常理想的做法，但也不是很糟糕。虽然我现在想不到一个例子，但我不会感到惊讶，如果在.NET框架本身中存在这种情况。作为一般的设计原则，构建代码时分层是一个好主意；而且通常这些层次结构是这样构造的，即较少“专业化”的代码不知道更多“特定的”代码。

命名空间嵌套是将更专业的类型与不太专业的类型分离的一种方式。因此，命名空间System包含非常通用和广泛适用的类型，而System.Drawing则更加专业化，包含与图像和视觉处理相关的类型。

但是，您应该避免使用命名空间根据可访问性对类型进行分组。这绝对是滥用命名空间的行为，并且可能会在长期内引起问题（特别是因为扩大类型的可访问性很常见，但更改其所属的命名空间可能非常困难）。

在我看来，只要您在做事情时保持一致，并且在命名空间之间有明确的类型划分，我认为您就不会有问题。

- LBushkin

Answer 3

为了避免污染您的根命名空间，我建议采用以下两种方法之一：

• 将类声明为internal而不是public（这样它们对于API的用户在程序集外部是不可见的）

• 将它们声明为Jokers的嵌套内部类（这样它们在Jokers类外部是不可见的）

- ChrisW

---

如果可以的话，我建议将它们嵌套在Jokers中。 - Timwi

Answer 4

如果您按照自己的计划去做，这并不是什么大问题，但我认为最好避免使用"Jokes.Internal"命名空间。我不认为内部类会"污染"您的根命名空间。

无论如何，我认为创建与可见性声明匹配的命名空间绝对是不正常的。

- Brent Arias