为什么C＃不提供C ++样式的“ friend”关键字？[关闭]

在C ++朋友关键字允许class A指定class B作为其朋友。这允许Class B访问的private/ protected成员class A。

我从来没有读过任何关于为什么C＃（和VB.NET）不包含此内容的信息。对于这个较早的StackOverflow问题的大多数答案似乎都是在说它是C ++的有用组成部分，并且有充分的理由使用它。以我的经验，我必须同意。

在我看来，另一个问题确实是在问如何friend在C＃应用程序中执行类似的操作。尽管答案通常围绕嵌套类，但似乎并不像使用friend关键字那样优雅。

原始的《设计模式》一书在整个示例中都定期使用它。

因此，总而言之，为什么friendC＃缺少它？在C＃中模拟它的“最佳实践”方法是什么？

（顺便说一句，internal关键字不是同一回事，它允许整个程序集中的所有类访问internal成员，而friend允许您为某个类提供对另一个类的完全访问权限）

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

话虽这么说，这是一个很好的功能，我自己在C ++中已经使用了很多次。并且也想在C＃中使用它。但是我打赌，因为C＃的“纯” OOness（与C ++的伪OOness相比），MS决定因为Java没有朋友关键字，C＃也不应（只是在开玩笑；））

值得一提的是：内部工作不如朋友好，但确实可以完成工作。请记住，很少会不通过DLL将代码分发给第三方开发人员；因此，只要您和您的团队了解内部类及其使用，您就可以了。

编辑让我澄清一下，Friend关键字如何破坏OOP。

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

附带说明。使用friend并不是在违反封装，而是相反地是在强制执行。像访问器+更改器，运算符重载，公共继承，向下转换等一样，它经常被滥用，但这并不意味着该关键字没有坏的目的，或者更糟的是，它的目的不好。

在其他线程中查看Konrad Rudolph的消息，或者，如果您愿意，请参见C ++ FAQ中的相关条目。

对于信息，.NET中的另一个相关但不完全相同的东西是[InternalsVisibleTo]，它使程序集可以指定另一个（有效地）“内部”访问类型/成员的程序集（例如单元测试程序集）。原始装配体。

通过使用C＃中的接口，您应该能够完成与“朋友”在C ++中相同的工作。它要求您显式定义在两个类之间传递的成员，这是额外的工作，但也可能使代码更易于理解。

如果有人举了一个合理使用“朋友”的示例，而该示例不能使用界面来模拟，请分享一下！我想更好地了解C ++和C＃之间的区别。

使用friendC ++，设计人员可以精确控制private *成员所面向的对象。但是，他被迫公开每个私人成员。

使用internalC＃时，设计师可以精确控制他要公开的一组私人成员。显然，他只能公开一个私人成员。但是，它将在程序集中的所有类中公开。

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

如您所见，我们有2个维度可以破坏封装。 friend沿着一个维度违反它，沿着另一个维度internal做到。封装概念中哪一个是更严重的违反？很难说。但是同时拥有friend和internal可用会很好。此外，这两个关键字的一个很好的补充是关键字的第三种类型，该关键字将在每个成员的基础上使用（如internal）并指定目标类（如friend）。

*为简洁起见，我将使用“私有”而不是“私有和/或受保护”。

-尼克

实际上，C＃提供了以纯OOP方式获得相同行为的可能性，而无需使用特殊词-它是私有接口。

就问题而言，朋友的C＃等效项是什么？被标记为与本文重复，并且没有人提出很好的实现-我将在此处显示两个问题的答案。

主要思想是从这里获取的：什么是私有接口？

假设，我们需要一些可以管理另一个类的实例并对其调用一些特殊方法的类。我们不想给任何其他类调用此方法。朋友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();
    }
}

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

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

尽管这样做会以稍微污染类声明的代价为代价，但它还是由编译器强制提醒您哪些测试实际上可能关心类的内部状态。

我发现的一个非常有用且简洁的习惯用法是，当我拥有工厂类时，使他们成为自己创建的具有受保护的构造函数的项目的朋友。更具体地说，这是当我只有一个工厂负责为报表编写器对象创建匹配的呈现对象，并呈现给定环境时。在这种情况下，您对报告编写器类（如图片块，布局带，页面标题等）及其匹配的呈现对象之间的关系具有单一的了解。

C＃缺少“朋友”关键字的原因与丢失确定性销毁的原因相同。不断变化的约定使人们感到聪明，好像他们的新方法优于别人的旧方法一样。这都是关于骄傲。

说“朋友班不好”与其他不合格的语句（如“不要使用gotos”或“ Linux比Windows更好”）一样短视。

“ friend”关键字与代理类结合使用是一种仅将类的某些部分暴露给特定的其他类的好方法。代理类可以充当针对所有其他类的可信任屏障。“公共”不允许进行任何此类定位，并且如果确实没有概念上的“是”关系，则使用“受保护”来获得继承效果是尴尬的。

您可以使用C＃关键字“ internal”接近C ++“ friend ”。

这实际上不是C＃的问题。这是IL中的一个基本限制。C＃受到此限制，其他任何可验证的.Net语言也受到此限制。此限制还包括C ++ / CLI（规范第20.5节）中定义的托管类。

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

停止为此限制找借口。朋友不好，但内部好吗？它们是一回事，只有那个朋友才可以让您更精确地控制允许访问的人和不允许访问的人。

这是强制执行封装范例吗？所以您必须编写访问器方法，现在呢？您应该如何阻止所有人（B类的方法除外）调用这些方法？您不能，因为您也无法控制它，因为缺少“朋友”。

没有一种编程语言是完美的。C＃是我见过的最好的语言之一，但是为缺少的功能提供愚蠢的借口并不能帮助任何人。在C ++中，我错过了简单的事件/委托系统，反射（+自动反序列化）和foreach，但是在C＃中，我错过了运算符重载（是的，一直告诉我您不需要它），默认参数，一个const不能回避的多重继承（是的，告诉我您不需要它，并且接口可以替代），并具有决定从内存中删除实例的能力（不，除非您是继承人，否则这并不算糟糕）小叮当）

从.Net 3开始有InternalsVisibleToAttribute，但是我怀疑他们只是在单元测试兴起之后才将其添加到测试装配中。我看不到其他许多原因来使用它。

它可以在组装级别工作，但可以在内部不工作的地方工作；也就是说，您要在其中分发程序集，但又希望另一个未分发的程序集具有对该程序集的特权访问。

正确地，它们要求对朋友程序集进行强键锁定，以避免有人在您受保护的程序集旁边创建一个伪装的朋友。

我已经读过许多关于“ friend”关键字的聪明评论，我同意这是有用的，但是我认为“ internal”关键字不太有用，并且它们都对纯OO编程不利。

我们有什么？（说到“朋友”，我也说到“内部”）

• 使用“朋友”会使代码对oo的纯度降低？

• 是;

• 是不是使用“朋友”使代码更好？

• 不，我们仍然需要在类之间建立一些私人关系，并且仅当我们破坏漂亮的封装时才可以这样做，所以它也不是一件好事，我可以说比使用“朋友”更邪恶。

使用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) { }
}

你怎么看待这件事？我认为这是最常见，最纯粹的面向对象解决方案。您可以打开选择的任何方法访问所需的任何类。

我只会回答“如何”问题。

这里有很多答案，但是我想提出一种“设计模式”来实现该功能。我将使用简单的语言机制，其中包括：

• 介面
• 嵌套类

例如，我们有2个主要班级：学生和大学。学生拥有GPA，只有大学才可以访问。这是代码：

public interface IStudentFriend
{
    Student Stu { get; set; }
    double GetGPS();
}

public class Student
{
    // this is private member that I expose to friend only
    double GPS { get; set; }
    public string Name { get; set; }

    PrivateData privateData;

    public Student(string name, double gps) => (GPS, Name, privateData) = (gps, name, new PrivateData(this);

    // No one can instantiate this class, but Student
    // Calling it is possible via the IStudentFriend interface
    class PrivateData : IStudentFriend
    {
        public Student Stu { get; set; }

        public PrivateData(Student stu) => Stu = stu;
        public double GetGPS() => Stu.GPS;
    }

    // This is how I "mark" who is Students "friend"
    public void RegisterFriend(University friend) => friend.Register(privateData);
}

public class University
{
    var studentsFriends = new List<IStudentFriend>();

    public void Register(IStudentFriend friendMethod) => studentsFriends.Add(friendMethod);

    public void PrintAllStudentsGPS()
    {
        foreach (var stu in studentsFriends)
            Console.WriteLine($"{stu.Stu.Name}: stu.GetGPS()");
    }
}

public static void Main(string[] args)
{
    var Technion = new University();
    var Alex     = new Student("Alex", 98);
    var Jo       = new Student("Jo", 91);

    Alex.RegisterFriend(Technion);
    Jo.RegisterFriend(Technion);
    Technion.PrintAllStudentsGPS();

    Console.ReadLine();
}

我怀疑这与C＃编译模型有关-在运行时构建IL JIT进行编译。即：C＃泛型与C ++泛型根本不同的相同原因。

您可以将其设为私有并使用反射来调用函数。如果您要求测试框架测试私有功能，则测试框架可以执行此操作

我以前经常使用朋友，但我认为这不违反OOP或任何设计缺陷的迹象。在很多地方，它是用最少的代码来达到正确结果的最有效方法。

一个具体的示例是在创建提供与某些其他软件的通信接口的接口程序集时。通常，有一些重量级类可以处理协议的复杂性和对等特性，并提供相对简单的连接/读取/写入/转发/断开连接模型，该模型涉及在客户端应用程序与程序集之间传递消息和通知。这些消息/通知需要包装在类中。通常，属性是属性的创建者，因此必须由协议软件对其进行操作，但是许多内容必须对外界保持只读状态。

声明对协议/“创建者”类进行所有创建的类的亲密访问是违反OOP的做法，这简直是愚蠢的。创建者类必须在不断上升的过程中逐一点处理所有数据。我发现最重要的是最小化“ OOP for SOP Sake”模型通常导致的所有BS额外代码行。多余的意大利面条只会使更多的错误。

人们是否知道您可以在属性，属性和方法级别应用内部关键字？它不仅用于顶层类声明（尽管大多数示例似乎都表明了这一点。）

如果您有一个使用friend关键字的C ++类，并且想在C＃类中模拟它：1.声明C＃类public 2.声明所有在C ++中受保护并因此可以作为朋友访问的属性/属性/方法C＃3中的internal。创建只读属性以供公众访问所有内部属性和属性

我同意与朋友不是100％一样，并且单元测试是需要像朋友这样的非常有价值的示例（协议分析器日志记录代码也是如此）。但是internal提供了您要公开的类的公开信息，而[InternalVisibleTo（）]处理其余部分-似乎它是专门为单元测试而生的。

至于朋友“变得更好，因为您可以显式地控制哪些类可以访问” –一堆在同一程序集中执行的可疑邪恶类到底是什么呢？对程序集进行分区！

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

例如

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该类的具体实例。它具有私有构造函数，而factory New()方法则返回一个接口。

有关详细信息，请免费阅读我的文章“ 朋友和内部接口成员”，其中包括对接口进行编码。

有些人建议通过使用朋友可以使事情失去控制。我会同意，但这并不会减少它的用处。我不确定朋友是否会比公开所有班级成员更伤害OO范式。当然，这种语言可以使您将所有成员公开，但是它是一个有纪律的程序员，可以避免这种类型的设计模式。同样，训练有素的程序员会在有意义的特定情况下保留使用Friend的权限。在某些情况下，我感到内部暴露过多。为什么将类或方法公开给程序集中的所有内容？

我有一个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);
}

我相信类似“朋友”之类的东西可以在该语言中有用并实现，而又不会使该语言减少“ OO”之类的（也许作为属性），以便您可以让类或方法成为特定类或方法的朋友，从而使开发人员能够提供具体的访问权限。也许类似...（伪代码）

[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 ++，并且使用friend关键字找到了自己，这是一个非常有力的信号，表明您遇到了设计问题，因为为什么某个类需要访问其他类的私有成员？

s

据说，朋友伤害纯粹的OOness。我同意。

也有人说，朋友帮助封装，我也同意。

我认为应该将友情添加到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类的朋友的原因。

也可以通过使用“代理”（某些内部类）来模拟友谊。考虑以下示例：

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

当仅用于访问静态成员时，它可能会更简单。这种实现的好处是，所有类型都在友谊类的内部范围中声明，并且与接口不同，它允许访问静态成员。