Refactoring capture module | process extraction
This step extract a significant amount of business logic from Capture and moves it all to the new class CaptureProcess
. The idea behind is that all actions and processes for preparation and execution of capture sequence jobs moves to CaptureProcess and Capture holds all the UI related logic, i.e. updating UI elements due to the results of the execution of process steps.
The general pattern for this is that processes are initiated from central methods like Capture::start() and communicate their results through events. The following table shows the major activities of this refactoring:
new in CaptureProcess | Capture counterpart | Event | Comment |
---|---|---|---|
startNextJob() | -- | -- | determines which job to be started next |
prepareJob() | jobPrepared() | jobPrepared() | |
prepareActiveJobStage() | -- | -- | two methods |
processPreCaptureCalibrationStage() | -- | -- | two methods |
prepareJobExecution() | jobExecutionPreparationStarted() | jobExecutionPreparationStarted() | |
executeJob() | execute() | renamed from execute() | |
checkLightFramePendingTasks() | -- | -- | |
checkNextExposure() | -- | -- | |
startNextExposure() | -- | -- | calls checkLightFramePendingTasks() |
scriptFinished() | scriptFinished() | ||
captureImage() | captureImageStarted() | captureImageStarted() | |
imageCapturingCompleted() | -- | -- | renamed from setCaptureComplete() |
processFITSData() | processingFITSfinished() | processingFITSfinished() | |
resumeSequence() | -- | -- | |
processJobCompletion() | -- | -- | two methods, renamed from processJobCompletionState..() |
checkPausing() | -- | -- | pause handling moved to CaptureProcess |
processCaptureError() | -- | -- | |
processCaptureTimeout() | -- | -- |
The extraction shows how complicated and sometimes confusing the methods and their interaction is. After this extraction it should be possible to clean up these methods and use a state model instead of a very complicated calling structure.