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