Best practices for modeling systems that evolve over time — mutability, patterns, and performance?

Specific Domains Modelling & Simulations
3

When it gets to modeling and you are in doubt you should follow @ChrisRackauckas advice. :grinning_face:

That being said, if you want to stick to your struct-based design or are interested in a general discussion, here are my thoughts about your example:

  • Often the “outer” structs need to be mutable for good performance, while the smaller “inner” structs can be immutable. In your case you probably could make CelestrialBody immutable and work with Ref if managing the updates is too complicated otherwise. The question is, whether it’s worth it in this case, because CelestrialBody seems to have object identity, so modeling it as a mutable struct seems to be the right thing.
  • Try to avoid abstract types in a struct definition. Your alternatives are
    • Concrete types (obviously)
    • Parameterized types
    • Union(All) types
  • Starting all field names with an underscore is not a typical Julia style. If you want to make sure that they are not accessed outside the module, a private-symbol check in Aqua.jl will probably be more robust (not implemented yet, however)
  • AbstractPoint might be misleading, as I would have assumed, that an AbstractPoint always has a position, which your objects do not seem to have. Maybe you find a better name (depending on your specific needs, maybe AbstractPointObject)
3 Likes