在游戏开发中使用“朋友”类

通常，在C ++中，游戏开发的速度要高于封装，因此您会看到大量可公开访问的类成员，这些成员实际上不应该公开。

在大多数情况下，我似乎发现实际上只需要很少的几个类就可以知道其他类的内部工作原理，以至于修改或读取其私有数据。

为此私有数据创建公共获取者/设置者会暴露出一些不应该随意修改的东西。

这里的妥协是使用朋友类吗？还是我没有看到的朋友班有一些缺点。

朋友班有两个主要缺点。

1. 您无法选择要公开给朋友的内容。全部或全无。如果您要强制使用某种非无关紧要的设置器，这可能会带来问题。
2. 在您的朋友知道朋友的意义上，您的两个班级现在已经有些耦合。

话虽这么说，使用朋友类绝对可以改善封装，特别是如果替代方法是公共获取者/设置者。

另外，关于SO的相关问题：https : //stackoverflow.com/questions/521754/when-to-use-friend-class-in-c

封装很好，但关注点分离更好。

一个访问其他类的“某些私有部分”的类可能表明该代码首先没有被很好地设计。

每当您发现自己在“天哪，我需要在这里做朋友课”的地方时，您应该问自己的问题是“我是否正确执行此操作，或者有更清洁的方法？” （又名“以后会不会在屁股上咬我？”）。

如果您确定“友好”，请毫不犹豫地放在此处。

另一种选择是使用PIMPL习惯用法，其中结构实现的一部分是指向另一种类型的指针。该类的大多数用户将只包括普通的头文件，其中的实现是不透明的指针。需要访问私有数据的类可以包括定义其他类型的标头，并使用其提供的接口。

对于想要类似朋友功能的C程序员来说，这是一种常见的模式。在我看来，它还比考虑封装（关注对象分离（一种通用的良好设计原则，可导致可重用的正交代码））更紧密地考虑，而不是封装（一种用于实现关注点分离但又经常被误用的面向对象的技术）使事情变得过于复杂）。

与朋友相比，它有一个优势，那就是根本不将朋友与朋友耦合。某些人可能会声称这是一个缺点，因为现在任何人都可以与您的班级“成为朋友”。我认为这是不必要的恐惧，因为您仍在通过（包括标题）使关系明确化。如果您担心这一点，那么您将担心自己（或您的同事）做出明智的架构决策的能力。但是，如果您以后无法正确做出这些决定，那么为什么现在信任自己friend？

它具有运行时成本的缺点。通过将数据存储在指针中，您将具有较差的缓存一致性和更多的分配计数，并且还需要析构函数来清理它。