Search code examples
low-latencyalgorithmic-tradingquantitative-financemql4metatrader4

MQL4, Code layout for big EA

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!

UPDATE2016-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 ).

Solution

  • 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, Stack Overflow seems not to be the best place to discuss the high-level architecture and development strategy of trading-strategy development efforts. While all above was mentioned, the last update of the question moves the subject another step farther from the said theoretical promoted Stack Overflow ideal.

    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...