The current step interface in gale encompasses setup, pre, main and post execution methods and their conditional checks. Not all types of steps within the application make use of the pre and post-execution methods, leading to unnecessary boilerplate code and potential confusion.
A modular approach, potentially using hooks or functional interfaces, may help streamline the implementation, making it more intuitive and reducing redundancies.
Current Behavior:
All types of steps need to implement the entire Step interface, even if they don't utilize pre and post-execution methods.
Desired Behavior:
Steps should only need to implement the parts of the interface they actively use, avoiding unnecessary boilerplate.
The system should remain extensible, allowing for future additions or modifications to step types.
High-Level Suggestions:
Functional Interface Decomposition: Break down the Step interface into smaller functional interfaces, such as PreExecutable, PostExecutable, etc. This allows steps to implement only the interfaces that are relevant to their operation.
Hook-based System: Instead of having separate methods in the interface, consider having a central execution method that uses hooks or listeners. These hooks can be registered dynamically based on the type of step. For instance, if a step has pre-execution logic, it can register a pre-execution hook.
Base and Extended Step Classes: Another object-oriented approach could involve having a base Step class with the most common methods and then extended classes or interfaces that add pre and post-execution capabilities. Steps can then extend or implement as needed.
Decorator Pattern: Use the decorator pattern to add pre and post-execution capabilities around a core step. This allows for flexible composition and avoids altering existing code.
Tasks:
Review the current usage and necessity of the Step interface's methods across different step types
Decide on the most suitable approach (from the suggestions or another identified method)
Implement the chosen approach and refactor existing steps to align with the new structure.
Ensure comprehensive tests to validate that the steps function correctly post-refactoring.
Description
The current step interface in
galeencompasses setup, pre, main and post execution methods and their conditional checks. Not all types of steps within the application make use of the pre and post-execution methods, leading to unnecessary boilerplate code and potential confusion.A modular approach, potentially using hooks or functional interfaces, may help streamline the implementation, making it more intuitive and reducing redundancies.
Current Behavior:
Stepinterface, even if they don't utilize pre and post-execution methods.Desired Behavior:
High-Level Suggestions:
Functional Interface Decomposition: Break down the
Stepinterface into smaller functional interfaces, such asPreExecutable,PostExecutable, etc. This allows steps to implement only the interfaces that are relevant to their operation.Hook-based System: Instead of having separate methods in the interface, consider having a central execution method that uses hooks or listeners. These hooks can be registered dynamically based on the type of step. For instance, if a step has pre-execution logic, it can register a pre-execution hook.
Base and Extended Step Classes: Another object-oriented approach could involve having a base
Stepclass with the most common methods and then extended classes or interfaces that add pre and post-execution capabilities. Steps can then extend or implement as needed.Decorator Pattern: Use the decorator pattern to add pre and post-execution capabilities around a core step. This allows for flexible composition and avoids altering existing code.
Tasks:
Stepinterface's methods across different step types