事实上，c#提供了在纯面向对象的方式下获得相同行为的可能性，没有特殊的词语——它的私有接口。

至于这个问题，c#中朋友的对等物是什么?这篇文章被标记为重复，没有人提出真正好的实现-我将在这里给出这两个问题的答案。

主要思想是从这里开始的:什么是私有接口?

比方说，我们需要一些类来管理另一个类的实例，并对它们调用一些特殊的方法。我们不想给任何其他类调用这个方法的可能性。这与friend c++关键字在c++世界中所做的事情完全相同。

我认为在实际实践中的一个很好的例子是全状态机模式，其中一些控制器更新当前状态对象并在必要时切换到另一个状态对象。

你可以:

使Update()方法公开的最简单和最糟糕的方法是希望 每个人都明白它为什么不好。 第二种方法是将其标记为内部。如果你把你的 类到另一个程序集，但即使是该程序集中的每个类 可以调用每个内部方法。 使用私有/受保护的接口——我就是这样做的。

Controller.cs

public class Controller
{
    private interface IState
    {
        void Update();
    }

    public class StateBase : IState
    {
        void IState.Update() {  }
    }

    public Controller()
    {
        //it's only way call Update is to cast obj to IState
        IState obj = new StateBase();
        obj.Update();
    }
}

Program.cs

class Program
{
    static void Main(string[] args)
    {
        //it's impossible to write Controller.IState p = new Controller.StateBase();
        //Controller.IState is hidden
        var p = new Controller.StateBase();
        //p.Update(); //is not accessible
    }
}

那么遗产呢?

我们需要使用在显式接口成员实现中描述的技术，因为不能将其声明为虚拟并将IState标记为受保护，以提供从Controller派生的可能性。

Controller.cs

public class Controller
{
    protected interface IState
    {
        void Update();
    }

    public class StateBase : IState
    {
        void IState.Update() { OnUpdate(); }
        protected virtual void OnUpdate()
        {
            Console.WriteLine("StateBase.OnUpdate()");
        }
    }

    public Controller()
    {
        IState obj = new PlayerIdleState();
        obj.Update();
    }
}

PlayerIdleState.cs

public class PlayerIdleState: Controller.StateBase
{
    protected override void OnUpdate()
    {
        base.OnUpdate();
        Console.WriteLine("PlayerIdleState.OnUpdate()");
    }
}

最后是如何测试类Controller抛出继承的例子: ControllerTest.cs

class ControllerTest: Controller
{
    public ControllerTest()
    {
        IState testObj = new PlayerIdleState();
        testObj.Update();
    }
}

希望我涵盖了所有情况，我的回答是有用的。

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

我以前经常使用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()]处理其余的—似乎它是专门为单元测试而生的。

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

我读过许多关于“朋友”关键字的聪明评论，我同意它是有用的东西，但我认为“内部”关键字没有那么有用，而且它们对纯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) { }
}

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

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

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

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

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

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

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