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