Design variability: Use getters and setters

[bmaclach]

Currently when the user chooses Bundled input or constants, we generate InputParameters and/or Constants classes with public state variables, which are then accessed directly where used.

An alternative design would make the state variables private, then generate getter and setter methods for each one, and use those where the variables need to be accessed/modified. This could be made a design choice in the Choices structure.

GOOL provides getMethod and setMethod for defining getters and setters, and get and set for calling them, so I don't expect anything will need to be added to GOOL for this choice.

[smiths]

I like this suggestion for a future variability. Good idea. I get the impression that it wouldn't be that hard to do.

[balacij]

The nice thing about this is that it would allow us to make the input variables 'final'/immutable once they're defined. Rather than using 'setters' however, it might be good to just leave all the parameters to the constructor, or to use the 'builder' pattern.

[smiths]

In our current examples the input variables do not change, so final/immutable would be appropriate. It would make it explicit that the values cannot be changed. Any example following the Input -> Calculate -> Output pattern would work with this. However, there will be future examples where we need the inputs to be variable. For instance, if we have an optimization problem we will be running many different values of the inputs.