When it gets to modeling and you are in doubt you should follow @ChrisRackauckas advice.
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 withRef
if managing the updates is too complicated otherwise. The question is, whether it’s worth it in this case, becauseCelestrialBody
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 anAbstractPoint
always has a position, which your objects do not seem to have. Maybe you find a better name (depending on your specific needs, maybeAbstractPointObject
)