Discussing the article: "Building a Divergence System (Part IV): Creating a Reusable Divergence Engine for MQL5"

[MetaQuotes]

Check out the new article: Building a Divergence System (Part IV): Creating a Reusable Divergence Engine for MQL5.

The article extracts the series' divergence logic into DivergenceEngine.mqh, a reusable header for MQL5 indicators and Expert Advisors. It details the struct-based design, oscillator options (MPO4 or RSI), pivot and state handling, and the minimal access API. A Parabolic SAR EA demonstrates integration by adapting the acceleration factor from the detected divergence, providing a clear pattern you can reuse without duplicating code.

Across the first three parts, Adaptive SuperTrend accumulated everything needed to detect divergence: oscillator calculation (MPO4 or RSI), pivot detection, divergence classification, and state management. That state includes the last pivot price, the last oscillator reading, the last divergence type, and the bars-since-divergence count. Each component was added where the SuperTrend calculation needed it, using the same series-ordered arrays as the indicator.

That is a reasonable approach for a single, self-contained system, but it comes with a cost: none of these components exist independently. They are embedded in the SuperTrend loop, sized around its lookback, and initialized with SuperTrend-specific boundary values. If another indicator or an unrelated EA needs the same divergence behavior, there is no clean interface to provide it. The practical alternative is to copy the relevant code into the new project and adjust it until it compiles. That kind of "reuse" becomes a maintenance problem when one copy gets a bug fix and the other doesn't. The illustration below visually simplifies this:

Oscillator, pivot detection, divergence detection, and state memory live inside a single implementation and can only be used there.

Author: Solomon Anietie Sunday