internal的一个非常有趣的用法(internal member当然仅限于声明它的程序集)是在某种程度上从它获得“好友”功能。友成员是仅对声明它的程序集之外的某些其他程序集可见的对象。c#没有内置对friend的支持，但是CLR有。

可以使用InternalsVisibleToAttribute来声明友程序集，并且来自友程序集中的所有引用将在友程序集中的范围内将声明的程序集的内部成员视为公共成员。这样做的一个问题是所有内部成员都是可见的;你不能挑三拣四。

InternalsVisibleTo的一个很好的用途是将各种内部成员暴露给单元测试程序集，从而消除了测试这些成员所需的复杂反射工作。所有内部成员都可见并不是什么大问题，但是采用这种方法确实会严重破坏类接口，并且可能会破坏声明程序集中的封装。

这个怎么样:通常建议不要向程序集的外部用户公开List对象，而是公开IEnumerable对象。但是在程序集中使用List对象要容易得多，因为您可以获得数组语法和所有其他List方法。因此，我通常有一个内部属性，公开要在程序集中使用的List。

欢迎对这种方法提出意见。

唯一一件事我曾经使用内部关键字是许可证检查代码在我的产品;-)

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

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

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

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

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

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.

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

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

internal的一个非常有趣的用法(internal member当然仅限于声明它的程序集)是在某种程度上从它获得“好友”功能。友成员是仅对声明它的程序集之外的某些其他程序集可见的对象。c#没有内置对friend的支持，但是CLR有。

可以使用InternalsVisibleToAttribute来声明友程序集，并且来自友程序集中的所有引用将在友程序集中的范围内将声明的程序集的内部成员视为公共成员。这样做的一个问题是所有内部成员都是可见的;你不能挑三拣四。

InternalsVisibleTo的一个很好的用途是将各种内部成员暴露给单元测试程序集，从而消除了测试这些成员所需的复杂反射工作。所有内部成员都可见并不是什么大问题，但是采用这种方法确实会严重破坏类接口，并且可能会破坏声明程序集中的封装。