我正在尝试使用OOP范例设计一些简单的实时模拟。我面临的问题是，由于我缺乏这种方法的经验，我不知道如何以自然的方式定义“正确”的对象及其关系。因此，我的问题更接近于软件架构，而不是更具技术性的“如何实现这一点或那样”。请注意，我正在进行此练习，以了解此编程范例。
模拟试图解决空2D空间中粒子之间的相互作用（碰撞，吸引等）。我想到的第一个对象是Particle。我已经用位置，速度，质量等实现了这个类。我已经创建了启动它们的方法，更新它们的位置（根据一些物理规则），甚至在画布中绘制它们。现在，我的问题在于设置物理常数或绘图参数（画布大小，窗口编号，每秒帧数等）。现在我正在使用全局变量，如重力或画布大小。这就是人们在非OOP方法中所做的事情，并且它的工作原理很远。但我正在苦苦思索纯粹的OOP如何处理粒子之间的共享参数。我可以预见各种选择。
Canvas，使用重力等常量创建Universe。然后，类Particle将是一个扩展类。但我应该从哪个遗产？不过，这个课程会得到扩展，但不是对象本身...... Universe和Particle创建为独立的类。然后，我将通过创建一个独特的Universe对象来关联它们。每个粒子都包含一个指向此类Universe对象的指针，因此他们可以访问物理参数。我不确定这个指针方法是否甚至都是OOP ...... 虽然我知道有很多方法可以做到这一点，但我想知道是否有一个更直观和“标准”，至少从学术角度来看。我想它并没有包含在我提出的解决方案中，因此任何关于如何在这种简单模拟中设计结构的提示都将非常受欢迎。
答案 0 :(得分：1)
这是一个更实际的考虑，主要是根据我自己的经验，并严格尝试在基本设计考虑的水平。我会对反馈感兴趣。
首先，从设计的角度来看，你的“ Canvas ”和“ Universe ”似乎有所不同：我可以想象 Canvas 参数可能需要改变，而物理常数可能不会。
假设 Canvas 实体可能会改变，对我来说这将是一个单独的类。我没有看到你希望你的粒子继承这个;在我的理解中，这些是逻辑上完全独立的实体。至于在画布上放置粒子的方便性，我会在不同的层面处理，而不是通过继承。
粒子本身可以用类的层次结构来实现，但这取决于你的项目以及你是否有不同种类（或行为）的粒子。
对于固定参数，我在C++项目中使用了具有显式名称空间的单独头文件。我没有看到这个在Fortran中不可行的设计，使用带常量的单独模块的原因。从这个意义上说，它们是全球性的，但可以在使用中进行控制，这就是它们的本质。这种方法也有灵活性，如果你的常量集合比单纯的数字更复杂。此外，如果证明需要，您可以稍后将其升级为类。
然后有一些问题，这些问题究竟与其他类有什么关系，以及如何编写它们的许多细节。这会在其他地方提出问题，而且我不熟悉Fortran的完整OO功能（除了编写类）。
所以我会说：“ Canvas ”是一个类，“ Universe ”是一个模块，它们都与 Particle 分开。