我们应该根据地方而不是概念来组织课程吗？
假设我们编写了一个程序来模拟具有三个对象的真实世界环境：汽车、道路和树木。传统的 OOP 设计建议在概念上将这 3 个单独的类分开。
但是假设汽车和道路对象在其类成员数据和方法中进行数百万次计算。由于引用的位置，我们可以通过将 Car 和 Road 混入 CarRoad 类来提高性能吗？或者如果这个例子太荒谬了，如果我们有另一个单独的 Wheel 类，它与 Car 密切相关，如果 Car 和 Wheel 类的类成员交互非常频繁，我们是否应该将它们混在一起？
除非我真的分析两个不同的版本并比较性能，否则我不会决定。
否则，我想尝试一些事情，例如，1.如果另一个类中的一个具有模板参数并传递它，在编译时实例化它会更有意义。2.将一个类放在另一个类中，但内联其所有方法，并强制它（有编译器标志/属性实际上强制它..）以查看生成的二进制文件是否具有不同的位置。
只是随机的想法..
Car 和 Road 是否可以合并为一个类取决于您尝试建模的系统。永远不要仅仅为了获得良好的参考位置而尝试合并（尽管您的想法是多余的）。
当您实例化此类的对象时，引用的局部性就会出现。让我通过一个简单的示例向您展示：-
假设我们必须在容器中选择向量或映射。
1) 地图相对于矢量提供了较差的参考位置：-
map 是根据平衡二叉树在内部实现的。因此，这意味着 map 以及存储数据还存储两个指针，即左子树和紧子树（也可能有指向 parent 的指针）。这意味着每个元素需要更多空间来存储与向量相同的数据。因此，在这种情况下，较少的数据将适合单个虚拟内存页面。
2) 向量提供了良好的参考位置：-
由于在 vector 中存储指针和数据并不令人头疼，因此与 map 相比，它可以在每页存储更多元素。这就是为什么矢量在参考位置方面优于地图的原因。