Message225880
In case it helps, I've experienced a similar refactoring.
we used a pattern of stages and services:
- stages represent a state of the application (like Pre-Initialization, Initializing, Initialized...), they are composed of services
- services represent a key responsability over the system (set program name, set python home...)
The launching sequence was determined by a game of dependencies.
ex: "Initialized" claims it requires "Initializing" which claims it requires Pre-Initialisation...
So when you ask to load stage Initialized the launcher can construct then run the sequence: Pre-Initialisation -> Initializing -> Initialized.
We used same mechanisms for Services.
This way you can insert/append new stages or services just by creating them and declaring they should be run after X and/or before Y.
Key benefits:
- easy to maintain and extend, flexible
- thread safe, launcher/runner can take the decision to parallelize. To serve this purpose each service can take a context object and return the context object that will be passed to the next service, between each stages contexts are merged if parallelized...
- easy to debug: you've got error messages like: At Stage X, service Y fails with error message Z.
- optimization friendly: while debugging you can measure the time taken by each service and compare it with and older version of the system for example.
- few changes to original code, it's just copy/pasting chunk of code.
Drawbacks:
- it's hard for developpers to have a picture of what happens, this require to make a launcher/debugger which can dump the launching sequence. |
|
Date |
User |
Action |
Args |
2014-08-25 17:30:42 | Gregory.Salvan | set | recipients:
+ Gregory.Salvan, barry, ncoghlan, sbspider |
2014-08-25 17:30:42 | Gregory.Salvan | set | messageid: <1408987842.56.0.520064628057.issue22257@psf.upfronthosting.co.za> |
2014-08-25 17:30:42 | Gregory.Salvan | link | issue22257 messages |
2014-08-25 17:30:42 | Gregory.Salvan | create | |
|