MQL4, Code layout for big EA

Question

It is mostly a theoretical question ( but example code is always welcome ).

The real question is: how to correctly code the 'frame' of an EA that tests multiple scenarios from multiple custom indicators?

The way I'm ( busy ) building an EA, is not very much focused on 1 strategy, but is gonna try to 'test' multiple strategies and 'picks' the most appropriate one.

So I have created a few custom indicators, that are all returning an array of 'status data'.

For example I have the following indicators:

• Crossing moving average indicator, that gives a signal when the average is crossed and also the current position in percentage moved from MA.
• Bollinger Bands indicator, that returns the 'room' between the bands and gives a signal when the bands starts 'squeezing'.
• Multi timeframe 'direction/trend' indicator ( is a certain timeframe moving toward up or down ). That returns current directions and gives a signal, if a timeframe direction changes.
• ADX indicator, for checking 'small-scale' movement and picking best buy/sell points.

I could write one HUGE scenario, but I think it can be done much better. Because if, lets say, all timeframes are going down ( down trend ) You could have a special scenario to handle lots of down movement. But if there is no current trend, a different scenario would fit best.

So, I feel like its best to make multiple scenarios ( still in 1 EA ). First all custom indicator data is collected and then each scenario uses that data to calculate its stuff. It then returns a 'score' and the best one is picked.

But how can I layout the code in the best 'overview' way?

Should I create a Class for each scenario and give them a manual 'tick' with data? And just split them into multiple files and #include them?

Or maybe event-driven? Created classes that just keeps on running, calculating and setting listeners to certain indicator events and go there own way (that would be awesome)

Any thoughts are much welcome!

---

UPDATE_{2016-01-11,12:00}

I don't have time right now to create a UML.. But I do the following for now ->

• Order ( Order is a singleton, just performing order requests )
• Indicator ( Base class that each indicator extends )

• Strategy ( Base class that each strategy extends )

• IndicatorFetcher ( Holds all indicators, gets run on each tick )

• StrategyRunner ( Holds all strategies, gets run on each tick, after IndicatorFetcher )

Each Strategy instance gets an access to the IndicatorFetcher ( Holding an overview with all indicators' data, and uses the Order singleton to perform trading ).

Answer 1

For complex scenarios, splitting each scenario into classes will be useful. Classes are separated into Tasks and Data that interacts with each other. An indicator could be wrapped within a Data-class, which is fed into a Monitor-Task. A big Action-task-class can be created to react to multiple monitor classes.

Answer 2

_{. . . a remark on creeping subject}

StackOverflow encourages users to post MCVE-related questions, as the Community is motivated to provide MCVE-related answers.

algorithmic-trading, quantitative-finance and particularly MQL4 domains are very, very specific with respect to narrow-band specialisation & ultimate profit-oriented motivation of the problem domain.

That said, StackOverflow seems not to be the very best place to discuss the high-level architecture and development strategy of trading-strategy development efforts and one may occasionally face a strong negative feedback from some self-constitued hardliners' policy enforcers.

While all above was mentioned, the last update of the question moves the subject another step farther from the said theoretical promoted StackOverflow ideal. _{( ... 've been warned )}

Ad-hoc last Update:
on class-inheritance and singleton +other patterns architecture

You might reconsider a few facts, that are not Software-engineering evangelisation theory or best-practice oriented, but are very cardinal for Quant modelling, the trading domain is all about.

- OOD/OOP ideals may and will suffer from MQL4 language limited extensibility ( by far !C++)

- design patterns, common in other domains, need not work under MQL4 event-triggered restricted code-execution facility ( you have no means to control mainloop()-alike constructs with custom added event-listeners and have indeed many issues if trying to design an "MQL4-viable" MVC-alike frameworks living just "hung-under" OnTick() external event-injector.

- "multi"-strategy mode-of-operation idea devastates the whole StrategyTester framework for quantitative modelling and optimisation services. If indeed interested in Quant-modelling portfolio-aggregated strategies, there are other tools for doing this, but definitely not an MQL4-coding bottom-up.

- there is literally zero benefits from assembling many strategies under the same process, while risks of not executed XTO-operations are both out of your control and grow exponentially, which is exactly what a good design practice strives to avoid and principally prevent.

---

_{Initial note:} architecture is your enemy ^{( not the "layout"-of-MQL4-code )}

As discussed in your earlier question, a proper understanding if the MetaTrader Terminal 4 code-execution ecosystem is your best road-map.

---

Process Management limitations on MT4

this is the core alpha and omega for any larger scale project.

While having done GPU / GPU-grid / hybrid dual event-controllers on top of the MT4 event-scheme with GUI-Finite-State-Automaton Layer, feeding it's actual state into a distributed back-end processing for really fast MQL4-EAs, all these grand Projects are doable and work fine right due to a proper care taken onto shared-resources usage stability ( avoiding race conditions ) & onto a principally non-blocking design ( collision avoidance as a preferred concurrency aspect ).

For an introduction to the process management limitations on MT4, check this post

---

#include or not #include? ^{( that's a question... )}

Without having to ask Hamlet, the prince of Denmark, the #include directive is ready for your code-base, however it does not handle all your stress efficiently on it's own.

Based on an experience of providing a development and maintenance for code-base spanning a bit more than a few hundreds man*years, the #include is not the Jack-of-all-trades.

A well thought selection of ... The IDE _{plus some home brew lexers and syntax-validators} ... is the key, because this is your team real productivity tool ( or performance brake, if chosen bad ).

Do not hesitate to read a few notes on this in this post

---

Final remark:

While the inital post
was motivated by
"how to program something HUGE in MQL4"
_{[kindly forgive my knowingly over-simplification made in a name of having a bit sharper contrast & focus on the merit]}

IMHO

the trading has absolutely different goal - it is a for-profit discipline,
for which quantitative methods
are typically used before designing any code,
not vice-versa

This means
the quantitatively modelled Trading Strategy
_{( and due to reasons outside of the scope of this post
I prefer to rather declare it to be a TruStrategy, a 5-dimensional field of policies { S, D, A, A, T } )}
shall provide an a-priori sense [The Profit-generation Performance]
before any code-implementation starts

That means,
any designer can propose a feasible approach only ad-hoc, not a-priori - be it finally resulting in a HUGE-legacy-code, a smart(er)-OOD-code or tiny & just-enough-code.

Without a known TruStrategy behaviour in all 5-dimensions
( not just the frequency of events, complexity of signal detection, sensitivity to alpha, beta & black-swan factors, how many trades are to be managed in parallel on-the-fly )
one knows literally nothing
whether
hunting for nanoseconds inside a tight realtime event-flow control-loop
_{[if positioned near HFT end of spectrum]}
or
fighting to reduce hours/days spent on maintaining then non-evolutionary models
_{[if petabytes of static data are first to be processed for adaptive AI/ML models from which a non-convex GridSearch cross-validation minimiser is to pick the most suitable members for a coalition-of-machines, that can robustly predict a set of 1 or 2 success-trade opportunities per week]}

Believe me or not, the resulting code differs -- a lot...