为什么在内部类中使用公共方法？

Question

我们的一个项目中有很多代码如下所示：

internal static class Extensions
{
    public static string AddFoo(this string s)
    {
        if (s == null)
        {
            return "Foo";
        }

        return $({s}Foo);
    }
}

除了“以后将类型公开更容易”之外，是否有任何明确的理由这样做？

我怀疑它只在非常奇怪的边缘情况（Silverlight 中的反射）中很重要，或者根本不重要。

Answer 1

更新：这个问题是the subject of my blog in September 2014。谢谢你的好问题！

即使在编译器团队内部也存在相当多的争论。

首先，了解规则是明智的。类或结构的公共成员是可以访问包含类型的任何对象的成员。所以内部类的公共成员实际上是内部的。

那么现在，给定一个内部类，您希望在程序集中访问的它的成员应该标记为公共还是内部？

我的意见是：将此类成员标记为公开。

我使用“public”来表示“此成员不是实现细节”。受保护的成员是一个实现细节；要使派生类工作，需要一些关于它的东西。内部成员是实现细节；该程序集内部的其他东西需要该成员才能正常工作。一个公共成员说“这个成员代表了这个对象提供的关键的、记录在案的功能。”

基本上，我的态度是：假设我决定把这个内部类变成一个公共类。为了做到这一点，我想只改变一件事：类的可访问性。如果将内部类转换为公共类意味着我还必须将内部成员转换为公共成员，那么该成员是该类的公共表面区域的一部分，它应该是首先公开。

其他人不同意。有一个特遣队说他们希望能够看一眼成员的声明并立即知道它是否只会从内部代码中调用。

不幸的是，这并不总是很好。例如，实现内部接口的内部类仍然必须将实现成员标记为公共，因为它们是类的公共表面的一部分。

Answer 2

如果类是internal，则从可访问性的角度来看，标记方法internal 还是public 都没有关系。但是，如果类是 public，则使用您将使用的类型仍然很好。

虽然有人说这可以简化从internal 到public 的转换。它也用作方法描述的一部分。 Internal 方法通常被认为对于不受限制的访问是不安全的，而 public 方法被认为是（大部分）免费游戏。

通过使用 internal 或 public 就像在 public 类中一样，您可以确保您传达预期的访问方式，同时还简化了在未来。

Answer 3

我经常在内部类中将我的方法标记为 public 而不是 internal 作为 a) 这并不重要 b) 我使用 internal 来表示该方法是内部故意的（有一些原因我不想要在公共类中公开此方法。因此，如果我有一个内部方法，我真的必须在将其更改为公共之前了解它是内部的原因，而如果我正在处理内部类中的公共方法，我真的必须考虑关于为什么类是内部的，而不是为什么每个方法都是内部的。

Answer 4

我怀疑“以后公开类型更容易吗？”是吗。

范围规则意味着该方法将仅以internal 可见 - 因此方法标记为public 还是internal 并不重要。

想到的一种可能性是该类是公开的，后来更改为internal，开发人员没有费心更改所有方法的可访问性修饰符。

Answer 5

在某些情况下，也可能是内部类型实现了公共接口，这意味着在该接口上定义的任何方法仍需要声明为公共。

Answer 6

同样，public 方法将被真正标记为 internal，因为它在一个内部类中，但它有一个优点（如您所说），如果您想将该类标记为 public，您必须更改更少的代码.

Answer 7

出于与在任何其他类中使用公共方法相同的原因 - 以便它们对包含类型的外部是公共的。

类型的访问修饰符与其成员的访问修饰符完全为零。这两个决定是完全独立做出的。

仅仅因为类型和成员修饰符的某些组合产生看似（或其他人称之为“有效”）相同的结果并不意味着它们在语义上是相同的。

实体的本地访问修饰符（在代码中声明）和它的全局有效访问级别（通过包含链评估）也是完全不同的东西。上锁的建筑物内的开放式办公室仍然开放，即使您无法真正从街上进入。

不要考虑最终效果。首先考虑您在本地需要什么。

• Public's Public：经典情景。
• Public's Internal：类型是公开的，但您希望在程序集中获得一些半合法的访问权限来做一些 hacky-wacky 的事情。
• Internal's Public: 你隐藏了整个类型，但在程序集中它有一个经典的公共表面
• Internal's Internal：我想不出任何现实世界的例子。也许很快就会在内部公开？

Internal's Public 与 Internal's Internal 是一个错误的两难选择。两者有完全不同的含义，应该在各自的情况下使用，不重叠。

Answer 8

internal 表示只能从同一个程序集中访问该成员。该程序集中的其他类可以访问internal public 成员，但不能访问private 或protected 成员，internal 或不。

Answer 9

我今天确实为此苦苦挣扎。到目前为止，我会说，如果类是 internal，则方法都应该用 internal 标记，并且会认为其他任何事情都只是糟糕的编码或懒惰，特别是在企业开发中；但是，我必须继承 public 类并覆盖其中一个方法：

internal class SslStreamEx : System.Net.Security.SslStream
{
    public override void Close()
    {
        try
        {
            // Send close_notify manually
        }
        finally
        {
            base.Close();
        }
    }
}

方法必须是 public，这让我想到将方法设置为 internal 确实没有逻辑意义，除非它们确实必须是，正如 Eric Lippert 所说。

直到现在我从来没有真正停下来思考过，我只是接受了它，但是在阅读了 Eric 的帖子后，它真的让我思考，经过深思熟虑，这很有意义。

Answer 10

确实有区别。 在我们的项目中，我们制作了很多内部类，但我们在另一个程序集中进行单元测试，并且在我们的程序集信息中，我们使用 InternalsVisibleTo 来允许 UnitTest 程序集调用内部类。 我注意到如果内部类有一个内部构造函数，由于某种原因，我们无法在单元测试程序集中使用 Activator.CreateInstance 创建实例。但是如果我们将构造函数更改为 public 但类仍然是内部的，它就可以正常工作。 但我想这是一个非常罕见的情况（就像 Eric 在原帖中所说：Reflection）。

Answer 11

我想我对此有额外的看法。起初，我想知道在内部类中向 public 声明一些东西有什么意义。然后我在这里结束了，读到如果您以后决定将课程更改为公开课程可能会很好。真的。于是，我的脑海中形成了一个模式：如果它不改变当前的行为，那就放任自流，允许在当前状态下没有意义（并且不会造成伤害）的事情发生代码，但稍后如果您更改类的声明，它会。

像这样：

public sealed class MyCurrentlySealedClass
{
    protected void MyCurretlyPrivateMethod()
    {
    }
}

根据我上面提到的“模式”，这应该是完全可以的。它遵循相同的想法。它表现为private 方法，因为您不能继承该类。但是如果你删除sealed约束，它仍然有效：继承的类可以看到这个方法，这绝对是我想要实现的。但是您会收到警告：CS0628 或 CA1047。他们俩都是关于不要在sealed 类中声明protected 成员。此外，我完全同意，这是毫无意义的：'Protected member in sealed class' warning (a singleton class)

因此，在此警告和讨论链接之后，我决定将所有内容都设置为内部或更少，在内部类中，因为它更符合这种想法，并且我们不会混合不同的“模式”。