Decision Needed on approach for Simulation Class

[HenryGeorgist]

@rnugent3 we need advice on the approach for the simulation class.

There are two basic paths:

1. We create objects for each relationship (Flow Frequency, Flow Stage, Stage Damage, etc)
2. We simply utilize PairedData and choose not to create objects for each relationship exclusively.

There is benefit in both paths. With the first path, things are separated and a bit clearer. We can customize behaviors for each relationship. With the second path, the code is simpler, we only have to bind to one object type in the VM. The behavior of the PairedData class is likely sufficient for all of the relationships, we don't likely need to customize it.

Either path is ok, we just need to decide one. We can always switch from one to another. If you want my advice, we do the simplest solution (solution 2) first, and add complexity if it is necessary for communication or added customization later.

Once this decision is made, I can get the simulation class finalized and develop unit tests.

@rnugent3 which option would you like us to pursue right now?

[rnugent3]

I like the idea of starting with a simple solution and adding complexity as needed.

…

On Oct 1, 2021, at 8:56 PM, Will Lehman ***@***.***> wrote:  @rnugent3 we need advice on the approach for the simulation class. There are two basic paths: We create objects for each relationship (Flow Frequency, Flow Stage, Stage Damage, etc) We simply utilize PairedData and choose not to create objects for each relationship exclusively. There is benefit in both paths. With the first path, things are separated and a bit clearer. We can customize behaviors for each relationship. With the second path, the code is simpler, we only have to bind to one object type in the VM. The behavior of the PairedData class is likely sufficient for all of the relationships, we don't likely need to customize it. Either path is ok, we just need to decide one. We can always switch from one to another. If you want my advice, we do the simplest solution (solution 2) first, and add complexity if it is necessary for communication or added customization later. Once this decision is made, I can get the simulation class finalized and develop unit tests. @rnugent3 which option would you like us to pursue right now? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[HenryGeorgist]

Sounds good - I think for now that means creating a branch to delete the following namespaces:

• flowfrequency
• flowstage
• flowtransform

We would want to make that commit really clear (maybe even reference this discussion) so that we can find it and revert it later if the complexity becomes warrented.