与朋友在课堂上进行内部功能，以隐藏公共细节

Internal functions in class with friends to hide public detail

本文关键字：隐藏 细节 功能 内部 朋友 课堂      更新时间：2023-10-16

我相信有一种更好的设计方法：

我有一个班，他生活的主要目的是照顾其他照顾小事的班。这些较小的类具有数量有限的公共数据、一些只能从管理器类访问的方法，以及一组只能从自身访问的内部函数。

我本来打算让manager类成为一个朋友，但这将允许manager查看（并使用）较小类的内部功能，这并不理想。

class child
{
public:
  int x;
private:
  friend class manager;
  doSomething();
  internalWork();
};
class manager
{
  public:
    child c;
};
manager m;
int i = m.c.x; // OK
c.doSomething(); // From method inside 'manager': OK
c.internalWork(); // Not allowed, only 'child' can use this function

有什么想法吗？

我以编程为生；我在一家软件公司工作。我有一个老板，他偶尔会给我一项任务

当他给我一个任务时，他只是简单地说："去写这个小部件，然后把它提交给源代码管理。然后告诉QA测试它。"

他没有做的是告诉我"去写这个小部件，然后把它提交给源代码管理。然后告诉QA测试它"，然后来到我的办公桌开始写代码。他在告诉我该做什么，而不是自己做。

但这基本上就是您的管理器类在执行以下操作时所做的：c.internalWork();——管理器没有告诉子对象该做什么；经理正在做。

friends是一种代码气味。它们不一定是坏事，当然也有其用途——但它们应该让你坐下来思考，"我们真的需要这个吗？"在这种情况下，friend的使用是围绕设计缺陷进行的黑客攻击。设计缺陷在于，你的子类没有一个公共接口，管理员可以通过这个接口告诉他们该做什么。破解的原因是，你的管理员类只是举起手来自己做工作。

修复你的类，使它们有一个合适的接口，并在friend发布时删除。

除了manager之外，还有其他东西需要查看child类吗？为什么不完全隐藏child的实现，使其只能从使用pimpl习惯用法的manager访问呢？

如果这是不可接受的，为什么要将child的成员函数耦合到公共数据？为什么不让它成为一个只有公共数据成员的结构，再加上一堆用于操作这些数据成员的免费函数呢？然后，您可以以类似的方式控制对所述自由函数的访问，只需使它们在manager实现所在的翻译单元中可见。

经理不是孩子，也不是孩子的朋友。他是一名经理。经理需要孩子的接口来管理，或者更具体地告诉孩子该做什么，并在工作完成时学习，但他不需要微观管理，他不需要查看孩子的内部数据。子级需要保护其内部数据，但它需要公共接口来从管理器获取任务，除了管理器之外没有其他人，并且需要能够在任务完成时告诉管理器。
相关文章：