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

假设您想让另一个程序集看到一个抽象类，但不希望有人能够继承它。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();
    }
  }
}

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

internal关键字的一个用途是限制程序集用户对具体实现的访问。

如果您有一个工厂或其他用于构造对象的中心位置，则程序集的用户只需处理公共接口或抽象基类。

此外，内部构造函数允许您控制实例化公共类的位置和时间。

我有一个项目，使用LINQ-to-SQL的数据后端。我有两个主要的名称空间:Biz和Data。LINQ数据模型存在于数据中，并标记为“内部”;Biz命名空间拥有围绕LINQ数据类的公共类。

这就是数据。Client和business .Client;后者公开了数据对象的所有相关属性，例如:

private Data.Client _client;
public int Id { get { return _client.Id; } set { _client.Id = value; } }

Biz对象有一个私有构造函数(强制使用工厂方法)和一个内部构造函数，看起来像这样:

internal Client(Data.Client client) {
    this._client = client;
}

库中的任何业务类都可以使用它，但是前端(UI)无法直接访问数据模型，从而确保业务层始终充当中介。

这是我第一次真正使用内部，它被证明是非常有用的。

我发现内部被过度使用了。您真的不应该只向某些类公开某些功能，而不向其他使用者公开。

在我看来，这打破了界面，打破了抽象。这并不是说永远不应该使用它，而是更好的解决方案是重构到不同的类，或者在可能的情况下以不同的方式使用。然而，这并不总是可能的。

The reasons it can cause issues is that another developer may be charged with building another class in the same assembly that yours is. Having internals lessens the clarity of the abstraction, and can cause problems if being misused. It would be the same issue as if you made it public. The other class that is being built by the other developer is still a consumer, just like any external class. Class abstraction and encapsulation isnt just for protection for/from external classes, but for any and all classes.

另一个问题是，许多开发人员会认为他们可能需要在程序集中的其他地方使用它，并将其标记为内部，即使他们当时并不需要它。另一个开发商可能会认为它就在那里。通常，在有明确的需要之前，您希望将其标记为私有。

但其中有些可能是主观的，我并不是说永远不应该使用它。只在需要的时候使用。

当您有方法、类等需要在当前程序集范围内访问，而不能在当前程序集范围外访问时。

例如，一个DAL可能有一个ORM，但对象不应该暴露给业务层，所有交互都应该通过静态方法完成，并传递所需的参数。

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

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