Discussion of article "Developing multi-module Expert Advisors"

[MetaQuotes]

New article Developing multi-module Expert Advisors has been published:

MQL programming language allows implementing the concept of modular development of trading strategies. The article shows an example of developing a multi-module Expert Advisor consisting of separately compiled file modules.

As a result of the transformation, we obtain a modular EA allowing the integration of up to seven external modules.

• Module 1 — money management module. It provides a lot size.
• Module 2 — tracking positions and placing SL. It provides a distance to SL in points from the Open price.
• Module 3 — tracking positions and placing TP. It provides a distance to TP in points from the Open price.
• Module 4 — tracking positions and placing a trailing stop. It provides a distance to SL in points from the current price.
• Module 5 — trading signals generation. It provides a signal value.
• Module 6 — module for sorting out trading signals. It provides the filter value.
• Module 7 — tracking positions and placing a breakeven level. It provides a distance to SL from the Open price.
  

Author: Sergey Pavlov

[Matthew Colter]

MetaQuotes Software Corp.:

New article Developing multi-module Expert Advisors has been published:

Author: Sergey Pavlov

This is interesting as a project generation template for specific use cases but I see many issues that would inevitably come up in using it as a generalized development pattern.

The self optimization of modules would lead to constant curve fitting over the optimization history data set, leading the EA into the trap of having a "market memory". As volatility moves up or down with respect to the training sample size, the module would lag behind and generally set stop loss or take profit too close. Statistically it would generate larger losers than winners over time. With larger sample sizes the curve fitting would be extremely specific to spurious market conditions that occurred over the sample history.

Ditching self optimization, we would be left to manually adjust the source code to explore the parameters of indicators, instead of being able to use the strategy tester to rapidly iterate through the "problem space" and do comparative analysis on the results. So basically we would spend 1000 years searching for parameters on relatively simple trading strategies.

The composition of programs always produces a "monolith" as the end product, though various means exist for composing the sub components of the resulting monolith. I mean the whole massive program just has to work regardless of how its source code is organized, because it all ends up as machine code somewhere. This solution basically sacrifices the "user interface" a.k.a. input, to solve problems with defining discreet code blocks that can be reliably maintained over time. These problems are more commonly solved through OO principles using classes and interfaces. The "top" level of the library or program is where a summary of internal dependencies are declared, things like paths to modules, inputs, etc. Creating a system where the "top" level basically forbids inputs is restricting the developer from interfacing with the tools built into metatrader that provide for strategy development and defining risk, which is pretty much like renaming the files in your module system from the end user's point of view.