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

Question

我们的一个项目中有很多代码看起来像这样：

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

        return $({s}Foo);
    }
}

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

Answer 1

更新：这个问题是我 2014 年 9 月博客的主题。感谢您提出的好问题！

即使在编译器团队内部，对于这个问题也存在相当多的争论。

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

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

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

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

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

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

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

Answer 2

如果该类是internal，则从可访问性的角度来看，将方法标记为internal 还是public 并不重要。然而，如果类是 public，那么使用您将使用的类型仍然是好的。

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

通过像在 public 类中一样使用 internal 或 public，您可以确保传达预期的访问方式，同时还可以简化将来使该类公开所需的工作。

Answer 3

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

作用域规则意味着该方法只能作为 internal 可见 - 因此这些方法标记为 public 还是 internal 并不重要。

我想到的一种可能性是该类曾经是公共的，后来更改为内部，并且开发人员没有费心去更改所有方法的可访问性修饰符。

Answer 4

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

Answer 5

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

Answer 6

相同的是，公共方法实际上会被标记为内部，因为它位于内部类内部，但它有一个优点（如您所言），如果您想将类标记为公共，则必须更改更少的代码。

Answer 7

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

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

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

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

不要考虑最终效果。首先考虑一下您当地需要什么。

• 公众的公众：经典情况。
• Public's Internal：类型是公共的，但您希望程序集中有一些半合法的访问权限来执行一些古怪的事情。
• Internal's Public：隐藏整个类型，但在程序集中它有一个经典的公共表面
• Internal's Internal：我想不出任何现实世界的例子。也许很快就会成为公众内部的事情？

内部的公共与内部的内部是一个错误的困境。两者具有完全不同的含义，应该在各自的情况下使用，不能重叠。

Answer 8

它与您的示例无关，但对于在 C# 直至 7.3（含） 中实现接口的类来说，它是：

internal interface IAmOnlyInternalViewable
{
    void CallMeOnlyInsideAssembly();
    //internal void CallMeOnlyInsideAssembly();  // <-- is not possible up to C# 7.3 inclusive
}

internal class OnlyInternalVisible : IAmOnlyInternalViewable
{
    public void CallMeOnlyInsideAssembly() { } //Must be public to implement the interface
}

因此，如果您想要一个内部类，它实现了接口，实现的方法需要是public。

Answer 9

我参加聚会有点晚了，但我想我愿意捐两分钱。

我总是倾向于让一切都尽可能受到限制，直到确实需要开放为止。我不相信走捷径只是因为它可能会或可能不会让我未来的生活变得更加轻松。遵循这一准则，我永远不会将内部类的方法公开，除非由于继承而被迫这样做。否则的话，在那个时间点公开它是没有意义的。

如果您偶然将内部类转换为公共类，则该转换并不自动意味着您希望您的方法是公共的。相反，更好的做法是仔细检查并明确决定哪些方法应该公开。否则，您可能会懒惰地公开所有内容，直到有人抱怨该类的某些行为或滥用行为时才意识到这是一个错误。

话虽如此，我确实认为先发制人地完成该过程是有效的，并考虑如果该类是公共的，哪些方法将是公共的。这很好，但这是一个需要严格执行的过程，这通常比将所有内容都保留在内部直到实际上需要公开更困难。

我的建议以及我将给出的所有编程建议的要点是不要成为一个懒惰的程序员。您在代码中遇到的大多数问题都是由于懒惰造成的。在这种情况下，不偷懒意味着尽可能限制访问，直到实际需要更加开放为止。

Answer 10

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

Answer 11

今天我实际上为此苦苦挣扎。到目前为止，我会说，如果类是 internal，那么所有方法都应该用 internal 标记，并且会认为其他任何事情都只是糟糕的编码或懒惰，特别是在企业开发中；但是，我必须对 public 类进行子类化并重写它的方法之一：

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

该方法必须是 public 这让我想到设置方法确实没有逻辑点正如埃里克·利珀特 (Eric Lippert) 所说，除非确实必须如此，否则将其视为内部。

到目前为止，我从未真正停下来思考过它，我只是接受了它，但在阅读了埃里克的帖子后，它确实让我思考，经过深思熟虑，它很有意义。

Answer 12

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

Answer 13

我想我对此还有一点补充意见。起初，我想知道在内部类中向 public 声明某些内容有何意义。然后我就到这里了，读到如果你以后决定将课程改为公开课程可能会很好。真的。因此，我的脑海中形成了一种模式：如果它不能改变当前的行为，那么就宽容一些，并允许在当前状态下没有意义（且无害）的事情代码，但稍后，如果您更改类的声明，就会这样。

就像这样：

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

根据我上面提到的“模式”，这应该完全没问题。它遵循同样的想法。它的行为类似于 private 方法，因为您无法继承该类。但如果删除sealed约束，它仍然有效：继承的类可以看到这个方法，这绝对是我想要实现的。但您会收到警告：CS0628 或 CA1047。它们都是关于不要在 sealed 类中声明 protected 成员。此外，我已经完全同意，这是毫无意义的： “密封类中受保护的成员”警告（单例类）

因此，在这个警告和相关讨论之后，我决定在内部类中将所有内容都内部化或更少化，因为它更符合这种思维，并且我们不会混合不同的“模式”。