Discussing the article: "Implementing the Decorator Pattern in MQL5: Adding Logging, Timing, and Filtering to Any Indicator Non-Invasively"
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: Implementing the Decorator Pattern in MQL5: Adding Logging, Timing, and Filtering to Any Indicator Non-Invasively.
Cross-cutting concerns like logging, timing, and threshold filtering should not live inside indicator classes. We show how to apply the decorator pattern in MQL5 with a shared IIndicator interface, an owning CBaseDecorator, and concrete CLoggingDecorator, CTimingDecorator, and CThresholdFilterDecorator layers. You can stack behaviors per EA, keep computation code closed to modification, and get deterministic cleanup by deleting only the outermost decorator.
To add execution timing to an existing RSI indicator class, a developer typically inserts GetMicrosecondCount() calls around the computation. When a second developer needs logging, they open the same file and add Print() calls. When a third developer needs threshold filtering, they add conditional return logic. After a few iterations, the RSI class accumulates code unrelated to RSI computation. It contains infrastructure concerns that belong to the calling context, not to the indicator.
This pattern violates the Open-Closed Principle, which states that a class should be open for extension but closed for modification. Each source-code modification to add a cross-cutting concern increases the risk of regressions in the indicator's core computation. The modification must be tested against all existing use cases. If the indicator class is shared across multiple EAs, the change affects all of them simultaneously. If the class is under version control and another developer has made unrelated changes to the same file, merge conflicts become more likely.
The deeper problem is that the concerns being added are not properties of the indicator. Timing, logging, and filtering are properties of how the indicator is used in a specific context. A different EA might need timing but not logging. A backtesting harness might need neither. The indicator class should not carry these concerns at all.
Author: Ushana Kevin Iorkumbul