Clean-up main model: job dispatch interface and adapter

[figueroa1395]

Relates to #1063

Part 2 of the split-up of MainModelImpl into the following design: create the job_dispatch_interface and job_dispatch_adapter

[Jerry-Jinfeng-Guo]

Is there already test cases that demonstrate how easily this new adapter-interface scheme can be tested with mocks?

[figueroa1395]

Is there already test cases that demonstrate how easily this new adapter-interface scheme can be tested with mocks?

Not yet. That would be part 3 of the saga. But in summary, we just need to test the job_dispatch calls (which should be easy to mock - just make a fake adapter that "implements" the interface and the result/update datasets can be "empty" structs or something simple), and then potentially evaluate if we need to test the job_dispatch_adapter or to what extend to do so, as it is mostly a collection of calls to main model (which should be unit tested); probably constructors and such might need testing and if we do some actual relevant logic as well.

[petersalemink95]

Just went through the PR - was quite hard to review. Not complaining - it is inherit to the nature of the PR -> shifting around code 😄

That said: I don't see anything weird in the structure, so if both @figueroa1395 and @mgovers are happy with the content it would be good to go for me as well

[Jerry-Jinfeng-Guo]

I know that most of the requires come from existing code, but when would be a good moment to replace them with named concepts?

[figueroa1395]

I know that most of the requires come from existing code, but when would be a good moment to replace them with named concepts?

It is good that you raised this question, because in a follow up PR (#1071) I decided to silence sonar about that, so maybe that isn't the right approach.

My thought process was that these requieres clauses are very specific to this interface, and we probably won't ever use them elsewhere, so I don't think it is worth making them a named concept. On the other hand, if it would add more clarity or you have a different take, we can do it. However, if we change them, I would do it at #1071, as the concepts in the interface are cleaned up a bit, so it's probably a good place to deal with that.

[nitbharambe]

LGTM post resolving of all comments.

[sonarqubecloud]

Quality Gate passed

Issues
7 New issues
0 Accepted issues

Measures
0 Security Hotspots
91.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud