其思想是，当您设计一个库时，只有打算从外部(由库的客户端)使用的类应该是公共的。这样你就可以隐藏

可能在未来的版本中更改(如果它们是公开的，您将破坏客户端代码) 对客户是无用的，可能会造成混乱 不安全(所以使用不当会严重破坏你的库)

etc.

如果你在开发内部解决方案，那么使用内部元素就不是那么重要了，因为通常客户会经常与你联系，并且/或访问代码。不过，它们对库开发人员来说相当重要。

当你的类或方法不完全符合面向对象范式，它们做危险的事情，需要从你控制下的其他类和方法调用，而你不想让其他人使用它们时。

public class DangerousClass {
    public void SafeMethod() { }
    internal void UpdateGlobalStateInSomeBizarreWay() { }
}

内部类使您能够限制程序集的API。这有很多好处，比如让你的API更容易理解。

此外，如果程序集中存在错误，修复程序引入破坏性更改的可能性就会降低。如果没有内部类，您将不得不假设更改任何类的公共成员都将是破坏性的更改。对于内部类，您可以假设修改它们的公共成员只会破坏程序集的内部API(以及InternalsVisibleTo属性中引用的任何程序集)。

我喜欢在类级和程序集级进行封装。有一些人不同意这一点，但很高兴知道功能是可用的。

在“使用尽可能严格的修饰符”规则的驱动下，我在需要访问的任何地方都使用internal，比如，从另一个类中访问方法，直到我显式地需要从另一个程序集访问它。

由于程序集接口通常比类接口的总和更窄，所以我在很多地方使用它。

前几天，也许是一个星期，在一个我不记得的博客上看到了一个有趣的东西。基本上这不是我的功劳，但我认为它可能有一些有用的应用。

假设您想让另一个程序集看到一个抽象类，但不希望有人能够继承它。Sealed不能工作，因为它是抽象的，这个程序集中的其他类确实从它继承。Private将不起作用，因为您可能希望在另一个程序集中声明一个Parent类。

namespace Base.Assembly
{
  public abstract class Parent
  {
    internal abstract void SomeMethod();
  }

  //This works just fine since it's in the same assembly.
  public class ChildWithin : Parent
  {
    internal override void SomeMethod()
    {
    }
  }
}

namespace Another.Assembly
{
  //Kaboom, because you can't override an internal method
  public class ChildOutside : Parent
  {
  }

  public class Test 
  { 

    //Just fine
    private Parent _parent;

    public Test()
    {
      //Still fine
      _parent = new ChildWithin();
    }
  }
}

如您所见，它有效地允许某人使用父类而不能够继承。

如果您正在编写一个DLL，它将大量复杂的功能封装到一个简单的公共API中，那么“internal”将用于不公开的类成员。

隐藏复杂性(又称封装)是高质量软件工程的主要概念。