从。net 3开始就有了InternalsVisibleToAttribute，但我怀疑他们只是在单元测试兴起后才添加它来迎合测试程序集。我想不出还有什么其他理由来使用它。

它在组装层工作但它能完成内部不能完成的工作;也就是说，您希望分发一个程序集，但希望另一个非分布式程序集具有对该程序集的特权访问。

很正确地，他们要求好友程序集是强键的，以避免有人在你受保护的程序集旁边创建一个假装的好友。

您可以保持它为私有，并使用反射来调用函数。测试框架可以做到这一点，如果你要求它测试一个私有函数

如果有朋友，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

我读过许多关于“朋友”关键字的聪明评论，我同意它是有用的东西，但我认为“内部”关键字没有那么有用，而且它们对纯OO编程来说都很糟糕。

我们有什么?(说到“朋友”，我也说到“内部”)

使用“friend”是否会使代码对于oo不那么纯粹? 是的, 不使用“friend”会使代码更好吗? 不，我们仍然需要在类之间建立一些私人关系，而且只有打破了我们美丽的封装才能做到，所以这也不好，我可以说它比使用“朋友”更邪恶。

使用friend会产生一些局部问题，不使用friend会给代码库用户带来问题。

在我看来，编程语言的通用解决方案是这样的:

// c++ style
class Foo {
  public_for Bar:
    void addBar(Bar *bar) { }
  public:
  private:
  protected:
};

// c#
class Foo {
    public_for Bar void addBar(Bar bar) { }
}

你觉得怎么样?我认为这是最常见的纯面向对象的解决方案。你可以对你想要的任何类打开任何方法的访问。

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

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.
  }
}

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

B.s.d。

有人说，朋友伤害纯粹的孤独。我同意这一点。

还有人说，朋友会帮助封装，我也同意这一点。

我认为友谊应该添加到OO方法中，但不像在c++中那样。我想有一些字段/方法，我的朋友类可以访问，但我不希望他们访问我所有的字段/方法。在现实生活中，我会让我的朋友们进入我的私人冰箱，但我不会让他们进入我的银行账户。

我们可以按照下面的方法实现它

    class C1
    {
        private void MyMethod(double x, int i)
        {
            // some code
        }
        // the friend class would be able to call myMethod
        public void MyMethod(FriendClass F, double x, int i)
        {
            this.MyMethod(x, i);
        }
        //my friend class wouldn't have access to this method 
        private void MyVeryPrivateMethod(string s)
        {
            // some code
        }
    }
    class FriendClass
    {
        public void SomeMethod()
        {
            C1 c = new C1();
            c.MyMethod(this, 5.5, 3);
        }
    }

这当然会生成一个编译器警告，并将损害智能感知。但它会起作用的。

另一方面，我认为一个自信的程序员应该在不访问私有成员的情况下进行测试单元。这已经超出了本文的范围，但请尝试阅读TDD。 然而，如果你仍然想这样做(有c++喜欢的朋友)，尝试一些像

#if UNIT_TESTING
        public
#else
        private
#endif
            double x;

所以你写的所有代码都没有定义UNIT_TESTING，当你想要进行单元测试时，你在文件的第一行添加#define UNIT_TESTING(并在#if UNIT_TESTING下编写所有进行单元测试的代码)。这应该小心处理。

因为我认为单元测试对于朋友的使用是一个不好的例子，所以我想举一个例子来说明为什么我认为朋友可以是好的。假设你有一个破碎的系统(类)。随着使用，破碎系统磨损，需要翻新。现在，你希望只有有执照的技工才能修理它。为了让这个例子不那么琐碎，我想说机械师会用他的私人螺丝刀来修理它。这就是为什么机制类应该是breakingSystem类的朋友。