#Modularization and Partial Classes

1 messages · Page 1 of 1 (latest)

dawn sage
#

I'm working on a De-Spaghettifying pass over my code base, and I'm finding a situation in which it'd be quite nice to be able to split a class across multiple files. I'm divying out the project into "Modules" that have a strictly one-way data access through the use of asmdefs. For the sake of demonstration, we have Core, Selection and MeshParser. Core has no dependencies on anything and contains all of the completely standalone, while both Selection and MeshParser reference Core, but not each other.

I have a script, FooterTooltip that updates a UI text with the following information: Where the camera currently is, the element you have selected (if one is selected), and the Facility Mesh you're inside of (if one is loaded). This code touches all three things - the camera controls are part of Core, you can only select an element if Selection is included, and there's only facilities loaded if MeshParser is included.

Currently, the script just runs Update to look for that information, and if it has changed, it modifies some UI Text. I know partial exists to basically split a class across multiple files and when it compiles, they fuse into one big Voltron-class containing everything, but I'm not sure how to get them all to run something in Update. I don't think I can just put Update in each of them and expect them all to run (and them running in an arbitrary order could clobber the data instead of checking them in order). I could pretty easily make each one a separate function, but how would I call the functions only if they're included, without needing to reference those other assemblies?

dim chasm
#
  1. Partial classes make me sad, unless it's for code generation purposes. Splitting a class this way just "hides" that it's one big thing, which is imo worse than being one big thing.
  2. Partial classes must still be in one assembly, so it won't work with separate asmdefs.
#
  1. I'd probably just say FooterTooltip is a higher level thing and should just "know" about the other ones. Not sure you need to overcomplicate your life
#

If FooterTooltip isn't a higher level thing that's just allowed to know about the others... then it needs interfaces / way of interaction defined in Core, so that the other classes can "match" it. Or the interface would be defined on the same level and place as FooterTooltip, but you'll still need some implementation on a higher level that can connect these things, if that makes sense.

fleet geyser
#

On phone rn but any chance you could have a barebones one in your base assembly that has a function that could return additional info? Then each module could listen “somehow” and add to the results?

tough cargo
#

Since it depends on all three assemblies, place it in its own UI assembly with all three as a dependency . . .