关于信息，. net中另一个相关但不完全相同的东西是[InternalsVisibleTo]，它允许一个程序集指定另一个程序集(例如单元测试程序集)，该程序集(有效地)具有对原始程序集中的类型/成员的“内部”访问。

不要再为这种限制找借口了。朋友是坏的，但内在是好的?它们是一样的东西，只是那个朋友让你更精确地控制谁可以访问谁不能访问。

这是强制封装范式吗?所以你必须写访问器方法，然后呢?你应该如何阻止所有人(除了类B的方法)调用这些方法?你不能，因为你也控制不了，因为你失去了“朋友”。

No programming language is perfect. C# is one of the best languages I've seen, but making silly excuses for missing features doesn't help anyone. In C++, I miss the easy event/delegate system, reflection (+automatic de/serialization) and foreach, but in C# I miss operator overloading (yeah, keep telling me that you didn't need it), default parameters, a const that cannot be circumvented, multiple inheritance (yeah, keep telling me that you didn't need it and interfaces were a sufficient replacement) and the ability to decide to delete an instance from memory (no, this is not horribly bad unless you are a tinkerer)

Friend在编写单元测试时非常有用。

虽然这是以稍微污染类声明为代价的，但它也是一个编译器强制的提醒，提醒您测试实际上可能关心类的内部状态。

A very useful and clean idiom I've found is when I have factory classes, making them friends of the items they create which have a protected constructor. More specifically, this was when I had a single factory responsible for creating matching rendering objects for report writer objects, rendering to a given environment. In this case you have a single point of knowledge about the relationship between the report-writer classes (things like picture blocks, layout bands, page headers etc.) and their matching rendering objects.

Some have suggested that things can get out of control by using friend. I would agree, but that doesn't lessen its usefulness. I'm not certain that friend necessarily hurts the OO paradigm any more than making all your class members public. Certainly the language will allow you to make all your members public, but it is a disciplined programmer that avoids that type of design pattern. Likewise a disciplined programmer would reserve the use of friend for specific cases where it makes sense. I feel internal exposes too much in some cases. Why expose a class or method to everything in the assembly?

我有一个ASP。NET页面，它继承了我自己的基页，而基页又继承了System.Web.UI.Page。在本页中，我有一些代码，用于在受保护的方法中处理应用程序的最终用户错误报告

ReportError("Uh Oh!");

现在，我有了一个包含在页面中的用户控件。我希望用户控件能够调用页面中的错误报告方法。

MyBasePage bp = Page as MyBasePage;
bp.ReportError("Uh Oh");

如果ReportError方法是受保护的，它就不能这样做。我可以将它设置为内部的，但它会暴露给程序集中的任何代码。我只是想把它暴露给当前页面的一部分UI元素(包括子控件)。更具体地说，我希望我的基控件类定义完全相同的错误报告方法，并简单地调用基页中的方法。

protected void ReportError(string str) {
    MyBasePage bp = Page as MyBasePage;
    bp.ReportError(str);
}

我相信像friend这样的东西可以很有用，并且可以在语言中实现，而不会使语言变得不那么“面向对象”，比如作为属性，这样你就可以让类或方法成为特定类或方法的朋友，允许开发人员提供非常特定的访问。也许就像……(伪代码)

[Friend(B)]
class A {

    AMethod() { }

    [Friend(C)]
    ACMethod() { }
}

class B {
    BMethod() { A.AMethod() }
}

class C {
    CMethod() { A.ACMethod() }
}

在我之前的例子中，可能会有如下内容(有人可能会争论语义学，但我只是想让大家理解):

class BasePage {

    [Friend(BaseControl.ReportError(string)]
    protected void ReportError(string str) { }
}

class BaseControl {
    protected void ReportError(string str) {
        MyBasePage bp = Page as MyBasePage;
        bp.ReportError(str);
    }
}

在我看来，朋友概念并不比将事物公开，或创建公共方法或属性来访问成员更有风险。如果朋友允许数据可访问性的另一个粒度级别，并允许你缩小可访问性，而不是用内部或公共来扩大它。

你可以用c#关键字“internal”来接近c++的“朋友”。

这实际上不是c#的问题。这是IL中的一个基本限制。c#也受此限制，就像任何其他寻求可验证的。net语言一样。这个限制也包括c++ /CLI中定义的托管类(Spec第20.5节)。

话虽如此，我认为纳尔逊对为什么这是一件坏事有一个很好的解释。