通过使用c#中的接口，您应该能够完成在c++中使用“friend”的相同种类的事情。它要求您显式地定义在两个类之间传递的成员，这是额外的工作，但也可能使代码更容易理解。

如果有人有一个合理使用“朋友”的例子，不能用界面模拟，请分享!我想更好地理解c++和c#之间的区别。

这种友谊也可以通过使用“代理”——一些内部类来模拟。考虑下面的例子:

public class A // Class that contains private members
{
  private class Accessor : B.BAgent // Implement accessor part of agent.
  {
    private A instance; // A instance for access to non-static members.
    static Accessor() 
    { // Init static accessors.
      B.BAgent.ABuilder = Builder;
      B.BAgent.PrivateStaticAccessor = StaticAccessor;
    }
    // Init non-static accessors.
    internal override void PrivateMethodAccessor() { instance.SomePrivateMethod(); }
    // Agent constructor for non-static members.
    internal Accessor(A instance) { this.instance = instance; }
    private static A Builder() { return new A(); }
    private static void StaticAccessor() { A.PrivateStatic(); }
  }
  public A(B friend) { B.Friendship(new A.Accessor(this)); }
  private A() { } // Private constructor that should be accessed only from B.
  private void SomePrivateMethod() { } // Private method that should be accessible from B.
  private static void PrivateStatic() { } // ... and static private method.
}
public class B
{
  // Agent for accessing A.
  internal abstract class BAgent
  {
    internal static Func<A> ABuilder; // Static members should be accessed only by delegates.
    internal static Action PrivateStaticAccessor;
    internal abstract void PrivateMethodAccessor(); // Non-static members may be accessed by delegates or by overrideable members.
  }
  internal static void Friendship(BAgent agent)
  {
    var a = BAgent.ABuilder(); // Access private constructor.
    BAgent.PrivateStaticAccessor(); // Access private static method.
    agent.PrivateMethodAccessor(); // Access private non-static member.
  }
}

如果只用于访问静态成员，则会简单得多。 这种实现的好处是，所有类型都在友谊类的内部作用域中声明，并且与接口不同，它允许访问静态成员。

这种友谊可以通过分离接口和实现来模拟。其思想是:“需要一个具体实例，但限制该实例的构造访问”。

例如

interface IFriend { }

class Friend : IFriend
{
    public static IFriend New() { return new Friend(); }
    private Friend() { }

    private void CallTheBody() 
    {  
        var body = new Body();
        body.ItsMeYourFriend(this);
    }
}

class Body
{ 
    public void ItsMeYourFriend(Friend onlyAccess) { }
}

尽管ItsMeYourFriend()是公共的，但只有Friend类可以访问它，因为其他人不可能获得Friend类的具体实例。它有一个私有构造函数，而工厂New()方法返回一个接口。

有关详细信息，请参阅我的文章《朋友和内部接口成员，免费为接口编码》。

顺便说一句。 使用friend并不是违反封装，相反，它是加强封装。就像访问器+突变器、操作符重载、公共继承、向下强制转换等一样，它经常被误用，但这并不意味着关键字没有，或者更糟，没有一个坏的目的。

请参阅Konrad Rudolph在另一个线程中的消息，或者如果您愿意，请参阅c++常见问题解答中的相关条目。

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

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

如果有朋友，c++设计人员可以精确控制私有*成员暴露给谁。但是，他被迫暴露了每一个私人成员。

对于内部，c#设计器可以精确控制他所公开的私有成员集。显然，他只能暴露单个私有成员。但是，它将暴露给程序集中的所有类。

通常，设计人员只希望将少数私有方法暴露给选定的少数其他类。例如，在类工厂模式中，可能希望类C1只由类工厂CF1实例化。因此类C1可能有一个受保护的构造函数和一个友类工厂CF1。

As you can see, we have 2 dimensions along which encapsulation can be breached. friend breaches it along one dimension, internal does it along the other. Which one is a worse breach in the encapsulation concept? Hard to say. But it would be nice to have both friend and internal available. Furthermore, a good addition to these two would be the 3rd type of keyword, which would be used on member-by-member basis (like internal) and specifies the target class (like friend). * For brevity I will use "private" instead of "private and/or protected". - Nick