拥有编程领域的朋友或多或少被认为是“肮脏的”，容易被滥用。它破坏了类之间的关系，破坏了OO语言的一些基本属性。

也就是说，这是一个很好的特性，我自己在c++中使用过很多次;并且也想在c#中使用它。但我敢打赌，因为c#的“纯”OOness(与c++的伪OOness相比)，MS决定因为Java没有朋友，关键字c#也不应该(开玩笑;))

严肃地说:内部关系不如朋友关系好，但它确实能完成工作。请记住，您很少会不通过DLL将代码分发给第三方开发人员;因此，只要您和您的团队了解内部类及其使用，就应该没问题。

让我来澄清一下friend关键字是如何破坏OOP的。

私有和受保护的变量和方法可能是OOP中最重要的部分之一。对象可以保存只有它们可以使用的数据或逻辑的思想允许您编写独立于环境的功能实现—并且您的环境不能更改它不适合处理的状态信息。通过使用friend，你将两个类的实现耦合在一起——这比仅仅耦合它们的接口要糟糕得多。

我以前经常使用friend，我不认为它违反了OOP，也不认为它有任何设计缺陷。在一些地方，它是用最少的代码达到正确目的的最有效的方法。

One concrete example is when creating interface assemblies that provide a communications interface to some other software. Generally there are a few heavyweight classes that handle the complexity of the protocol and peer peculiarities, and provide a relatively simple connect/read/write/forward/disconnect model involving passing messages and notifications between the client app and the assembly. Those messages / notifications need to be wrapped in classes. The attributes generally need to be manipulated by the protocol software as it is their creator, but a lot of stuff has to remain read-only to the outside world.

声明协议/“创建者”类对所有创建的类的亲密访问是违反OOP的，这是非常愚蠢的——创建者类不得不在上升的过程中对每一点数据进行修改。我发现最重要的是尽量减少“为了面向对象而面向对象”模型通常导致的所有多余的代码行。额外的意大利面只会产生更多的虫子。

人们知道您可以在属性、属性和方法级别应用内部关键字吗?它不仅仅用于顶级类声明(尽管大多数示例似乎都显示了这一点)。

如果你有一个使用friend关键字的c++类，并且想在一个c#类中模拟它: 1. 将c#类声明为public 2. 将c++中受保护的所有属性/属性/方法声明为c#内部的 3.为所有内部属性和属性的公共访问创建只读属性

我同意它并不完全等同于好友，单元测试是一个非常有价值的例子，说明了需要好友之类的东西(就像协议分析器日志代码一样)。然而，internal提供了您想要公开的类的公开，[InternalVisibleTo()]处理其余的—似乎它是专门为单元测试而生的。

至于朋友“更好，因为你可以显式地控制哪些类可以访问”——一堆可疑的邪恶类在同一个程序集中做什么呢?对程序集进行分区!

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类的朋友。

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

我怀疑这与c#编译模型有关——在运行时构建IL和JIT编译。也就是说:c#泛型与c++泛型有本质区别的原因是一样的。

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

例如

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()方法返回一个接口。

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