我们应该根据地点而不是概念来组织类(class)吗？
假设，假设我们编写了一个程序来模拟具有三个对象的真实世界环境:汽车、道路和树木。传统的 OOP 设计建议在概念上将这 3 个独立的类分开。
但假设汽车和道路对象在其类成员数据和方法中进行了数百万次计算。由于引用的位置，我们可以通过将 Car 和 Road 混入 CarRoad 类来提高性能吗？或者如果这个例子太荒谬了，如果我们有另一个与 Car 密切相关的单独的 Wheel 类，如果 Car 和 Wheel 类的成员交互非常频繁，我们是否应该将它们混在一起？
最佳答案
除非我真的分析了两个不同的版本并比较了性能，否则我不会做出决定。
否则我想尝试一些事情，比如， 1. 如果另一个类有模板参数并传递它，在编译时实例化它，会更有意义吗？ 2. 将一个类放在另一个类中，但内联它的所有方法，并强制它(有编译器标志/属性实际强制它..)以查看生成的二进制文件是否具有不同的局部性。
只是随意的想法..
关于C++ 混淆类以增强引用的局部性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26879429/