c ++中的朋友类/功能

时间:2009-04-09 12:51:39

标签: c++ friend

  

可能重复:
  When should you use 'friend' in C++?

虽然还有其他选择,但我看到有很多人推荐将功能/类别作为其他类别的朋友。难道不应该在C ++中谨慎使用朋友吗?在决定使用好友功能之前,我觉得必须考虑其他选项。欢迎提出意见/建议。

5 个答案:

答案 0 :(得分:10)

有人说friend违反了封装。在我看来,这恰恰相反。如果没有friend,我们最终会得到:

  • 巨大的整体课程,它做了许多他们不应该做的事情,只是为了避免外部课程访问他们的内部
  • 严重封装的类:为了分离关注点并编写具有一个且只有一个责任的类,我们需要提供对相关类集所需的内部数据的公共访问。

friend是解决此问题的好方法,因为它允许您自由地将多个类中的响应分开,同时允许您将对实现细节的访问权限限制为需要它们的少数函数或类型

答案 1 :(得分:4)

我同意。应该谨慎使用friend关键字。

如果您希望将干净的api从这些类公开给用户,但是当这些类可以使用更丰富的接口相互交互时,可能会有一组可以交互在一起的类。

例如:

class Folder
{
public:
  int GetFileCount();
private:
  void IncrementFileCount();  // users of this class have no right to use this

  friend class File;
};

class File
{
public:
  File(string name, Folder& containingFolder)
  {
     containingFolder.IncrementFileCount(); // except for indirectly when they create a file
  }
};

答案 2 :(得分:3)

如果没有具体的例子,这很难决定。虽然friend并非绝对必要,但确实有其用途。如果您声称有更好的选择,那么显然可以使用他们,简单地定义“更好”这个词。或者也许决定哪种解决方案更好,毕竟不是那么简洁。

就个人而言,我更愿意在可能的情况下避免使用它,但我更喜欢将其用于方法复制:例如,我不想编写print方法只是为了避免使operator <<成为{{1} 1}}因为我没有看到重复方法的好处。

答案 3 :(得分:1)

对于那些认为朋友违反封装的人来说,这就是Bjarne Stroustup所拥有的say

但我个人不会使用朋友,除非这是不可避免的。像Iterator模式的实现这样的场景没有其他选择。

如果使用得当,朋友就是朋友,否则他就是敌人!

答案 4 :(得分:0)

如果您想要调用需要访问类成员的第三方库函数,请考虑朋友函数,例如:

class A {
private:
     int x,y;
     double result;
public:
     friend void *power(void *x);
}

您现在可以使用此友元函数调用math.h中的pow函数。您的幂函数现在可以定义为:
class A {
private:
     int x,y;
     double result;
public:
     friend void *power(void *x);
}
尽管有更简单的方法来调用pow函数。这个例子只是为了说明友元函数在调用库函数中的重要性。 希望它有用。