MQL4，大型 EA 的代码布局
MQL4, Code layout for big EA
这主要是一个理论问题（但示例代码总是受欢迎的）。
真正的问题是：如何正确编写从多个自定义指标测试多个场景的 EA 的 'frame'？
我（忙）构建 EA 的方式并不是非常专注于一种策略，而是会尝试 'test' 多种策略和 'picks' 最合适的策略。
所以我创建了一些自定义指标，它们都返回一个数组 'status data'。
比如我有以下指标：
- 交叉移动平均线指标，当平均线被交叉时给出信号，并且当前位置从 MA 移动的百分比。
- 布林带指标，returns 带之间的 'room' 并在带开始时发出信号 'squeezing'.
- Multi timeframe 'direction/trend' 指标（某个时间框架向上或向下移动）。 returns 当前方向并在时间框架方向发生变化时发出信号。
- ADX 指标，用于检查 'small-scale' 走势和选择最佳 buy/sell 点。
我可以写一个巨大的场景，但我认为它可以做得更好。因为如果假设所有时间框架都在下降（下降趋势），您可能有一个特殊的场景来处理大量的下降趋势。但如果没有当前趋势，则不同的场景最适合。
所以，我觉得最好制作多个场景（仍然在 1 个 EA 中）。首先收集所有自定义指标数据，然后每个场景使用该数据来计算其内容。然后 returns 一个 'score' 并选出最好的一个。
但是我怎样才能以最好的 'overview' 方式布局代码？
我是否应该为每个场景创建一个 Class 并给他们一个带有数据的手册 'tick'？然后将它们拆分成多个文件然后 #include 它们？
或者事件驱动？创建了 classes 并持续 运行ning，计算和设置特定指标事件的侦听器并按照自己的方式进行（那太棒了）
非常欢迎任何想法！
更新2016-01-11,12:00
我现在没有时间创建 UML.. 但我现在执行以下操作 ->
Order（Order是单例，只是执行订单请求）Indicator（每个指标扩展的基础class）Strategy（每个策略扩展的基础class）
IndicatorFetcher（保留所有指标，每次报价时获得 运行）
StrategyRunner（持有所有策略，在每个订单号上获得 运行，在 IndicatorFetcher )
每个 Strategy 实例都可以访问 IndicatorFetcher（持有所有指标数据的概览，并使用 Order 单例执行交易）。
. . . a remark on creeping subject
Whosebug 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, Whosebug 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 Whosebug 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.
初注：架构是你的敌人（不是"layout"-of-MQL4-代码）
如您之前的问题所述，正确理解 MetaTrader Terminal 4 代码执行生态系统是否是您的最佳路线图。
MT4 的流程管理限制
这是任何大型项目的核心 alpha 和 omega。
虽然在带有 GUI-有限状态-自动机层的 MT4 事件方案之上完成了 GPU / GPU-grid / 混合双事件控制器，但将其实际状态馈送到分布式后端处理中以实现真正的快速的 MQL4-EA，所有这些宏伟的项目都是可行的 并且由于对共享资源使用稳定性（避免竞争条件）和主要非阻塞设计的适当关注而正常工作（避免冲突作为首选的并发方面）。
关于MT4流程管理限制的介绍，
#include 还是 #include？ （这是一道题...）
无需询问丹麦王子哈姆雷特，#include 指令已为您的代码库做好准备，但它无法有效地处理您的所有压力靠自己。
根据为代码库提供开发和维护跨越数百人 * 年的经验，#include 不是万事通。
经过深思熟虑的选择... IDE 加上一些自制词法分析器和语法验证器 .. . 是关键，因为这是您的团队真正的生产力工具（或性能制动器，如果选择不好的话）。
不要犹豫read a few notes on this in this post
最后的评论：
而最初的post
的动机是
"how to program something HUGE in MQL4"
[请原谅我以具有更鲜明的对比和专注于优点的名义故意过度简化]
恕我直言
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...
对于复杂的场景，将每个场景拆分为 classes 会很有用。
类 分为相互交互的任务和数据。
指标可以包装在 Data-class 中，它被馈送到 Monitor-Task 中。可以创建一个大的 Action-task-class 来响应多个监视器 classes.
我一开始就在 OnTick 中收集所有数据。
然后我知道我拥有的所有数据。
与数据收集并行的是打印语句，因此我可以在“专家”选项卡中看到它们。可以使用其他几种方式来查看数据。
在这个带有所有打印语句的函数中，如果您需要在编写和调试代码时查找代码中的一些变量，您可以复制、粘贴到您正在工作的区域。
我用xmind.net免费版来做代码的流转。这有助于在更容易修复时识别问题。弄清楚你的伪代码，然后在它准备好时填写它。一些 Xmind 可能最终会出现在评论中。
我发现对于我的文档，尽可能在代码中完成。其他方法使文档不同步并成为一个挑战。
使用 GitHub 或类似的方法来存储您的更改。拍摄所有代码的完整快照，包括 Files 文件夹中的任何内容等等。我宁愿保存东西而不需要它，也不愿需要它而不拥有它。
在您的发布版本中，请在前面加上日期，如下所示：
JosephsProject.mq5 // 发布版本 - 被认为是功能性的
20201215_JosephsProject.mq5（还有可执行文件）
现在您可以获得这段代码，如果需要，您可以比较它的工作方式和现在的工作方式。您可以在创建“发布版本”时无需挖掘所有包含文件和快照即可进行测试。
多个或大型显示器可提高工作效率。
我使用 50 英寸 4K 高清电视。我在最高像素设置下使用它，它让我有更多的空间来编码，并让我的所有工具都摆放起来，而不是像扑克牌一样堆叠。
将开发分解成小任务。您可能希望使用 KanbanFlow.com 来组织您的待办事项列表。您还可以看到有利于激励的已完成项目。如果您有多个人参与该项目，这也很有用。
随时保持代码整洁。测试和弄乱是可以的，但是一旦确定了理想的代码，您就可以去清理所有混乱和未使用的变量。
使用格式化行来分解逻辑块。
我对代码的排列方式很挑剔。这可能只是我的一些强迫症。
我喜欢留下很多笔记，即使只是我在编码。当我必须回到这部分代码时，我想知道什么？
最后使用其中任何一个有帮助并跳过其他的。您将成为这样做的人，因此请选择最好的，如果需要，请选择。
祝福。
这主要是一个理论问题（但示例代码总是受欢迎的）。
真正的问题是：如何正确编写从多个自定义指标测试多个场景的 EA 的 'frame'？
我（忙）构建 EA 的方式并不是非常专注于一种策略，而是会尝试 'test' 多种策略和 'picks' 最合适的策略。
所以我创建了一些自定义指标，它们都返回一个数组 'status data'。
比如我有以下指标：
- 交叉移动平均线指标，当平均线被交叉时给出信号，并且当前位置从 MA 移动的百分比。
- 布林带指标，returns 带之间的 'room' 并在带开始时发出信号 'squeezing'.
- Multi timeframe 'direction/trend' 指标（某个时间框架向上或向下移动）。 returns 当前方向并在时间框架方向发生变化时发出信号。
- ADX 指标，用于检查 'small-scale' 走势和选择最佳 buy/sell 点。
我可以写一个巨大的场景，但我认为它可以做得更好。因为如果假设所有时间框架都在下降（下降趋势），您可能有一个特殊的场景来处理大量的下降趋势。但如果没有当前趋势，则不同的场景最适合。
所以，我觉得最好制作多个场景（仍然在 1 个 EA 中）。首先收集所有自定义指标数据，然后每个场景使用该数据来计算其内容。然后 returns 一个 'score' 并选出最好的一个。
但是我怎样才能以最好的 'overview' 方式布局代码？
我是否应该为每个场景创建一个 Class 并给他们一个带有数据的手册 'tick'？然后将它们拆分成多个文件然后 #include 它们？
或者事件驱动？创建了 classes 并持续 运行ning，计算和设置特定指标事件的侦听器并按照自己的方式进行（那太棒了）
非常欢迎任何想法！
更新2016-01-11,12:00
我现在没有时间创建 UML.. 但我现在执行以下操作 ->
Order（Order是单例，只是执行订单请求）Indicator（每个指标扩展的基础class）Strategy（每个策略扩展的基础class）IndicatorFetcher（保留所有指标，每次报价时获得 运行）StrategyRunner（持有所有策略，在每个订单号上获得 运行，在IndicatorFetcher)
每个 Strategy 实例都可以访问 IndicatorFetcher（持有所有指标数据的概览，并使用 Order 单例执行交易）。
. . . a remark on creeping subject
Whosebug encourages users to postMCVE-related questions, as the Community is motivated to provideMCVE-related answers.
algorithmic-trading, quantitative-finance and particularlyMQL4domains are very, very specific with respect to narrow-band specialisation & ultimate profit-oriented motivation of the problem domain.
That said, Whosebug 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 Whosebug 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/OOPideals may and will suffer fromMQL4language limited extensibility ( by far !C++)
- design patterns, common in other domains, need not work underMQL4event-triggered restricted code-execution facility ( you have no means to controlmainloop()-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"-strategymode-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 anMQL4-coding bottom-up.
- there is literally zero benefits from assembling many strategies under the same process, while risks of not executedXTO-operations are both out of your control and grow exponentially, which is exactly what a good design practice strives to avoid and principally prevent.
初注：架构是你的敌人（不是"layout"-of-MQL4-代码）
如您之前的问题所述，正确理解 MetaTrader Terminal 4 代码执行生态系统是否是您的最佳路线图。
MT4 的流程管理限制
这是任何大型项目的核心 alpha 和 omega。
虽然在带有 GUI-有限状态-自动机层的 MT4 事件方案之上完成了 GPU / GPU-grid / 混合双事件控制器，但将其实际状态馈送到分布式后端处理中以实现真正的快速的 MQL4-EA，所有这些宏伟的项目都是可行的 并且由于对共享资源使用稳定性（避免竞争条件）和主要非阻塞设计的适当关注而正常工作（避免冲突作为首选的并发方面）。
关于MT4流程管理限制的介绍，
#include 还是 #include？ （这是一道题...）
无需询问丹麦王子哈姆雷特，#include 指令已为您的代码库做好准备，但它无法有效地处理您的所有压力靠自己。
根据为代码库提供开发和维护跨越数百人 * 年的经验，#include 不是万事通。
经过深思熟虑的选择... IDE 加上一些自制词法分析器和语法验证器 .. . 是关键，因为这是您的团队真正的生产力工具（或性能制动器，如果选择不好的话）。
不要犹豫read a few notes on this in this post
最后的评论：
而最初的post
的动机是
"how to program something HUGE in MQL4"
[请原谅我以具有更鲜明的对比和专注于优点的名义故意过度简化]
恕我直言
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-convexGridSearchcross-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...
对于复杂的场景，将每个场景拆分为 classes 会很有用。 类 分为相互交互的任务和数据。 指标可以包装在 Data-class 中，它被馈送到 Monitor-Task 中。可以创建一个大的 Action-task-class 来响应多个监视器 classes.
我一开始就在 OnTick 中收集所有数据。 然后我知道我拥有的所有数据。 与数据收集并行的是打印语句，因此我可以在“专家”选项卡中看到它们。可以使用其他几种方式来查看数据。 在这个带有所有打印语句的函数中，如果您需要在编写和调试代码时查找代码中的一些变量，您可以复制、粘贴到您正在工作的区域。
我用xmind.net免费版来做代码的流转。这有助于在更容易修复时识别问题。弄清楚你的伪代码，然后在它准备好时填写它。一些 Xmind 可能最终会出现在评论中。
我发现对于我的文档，尽可能在代码中完成。其他方法使文档不同步并成为一个挑战。
使用 GitHub 或类似的方法来存储您的更改。拍摄所有代码的完整快照，包括 Files 文件夹中的任何内容等等。我宁愿保存东西而不需要它，也不愿需要它而不拥有它。
在您的发布版本中，请在前面加上日期，如下所示： JosephsProject.mq5 // 发布版本 - 被认为是功能性的 20201215_JosephsProject.mq5（还有可执行文件） 现在您可以获得这段代码，如果需要，您可以比较它的工作方式和现在的工作方式。您可以在创建“发布版本”时无需挖掘所有包含文件和快照即可进行测试。
多个或大型显示器可提高工作效率。 我使用 50 英寸 4K 高清电视。我在最高像素设置下使用它，它让我有更多的空间来编码，并让我的所有工具都摆放起来，而不是像扑克牌一样堆叠。
将开发分解成小任务。您可能希望使用 KanbanFlow.com 来组织您的待办事项列表。您还可以看到有利于激励的已完成项目。如果您有多个人参与该项目，这也很有用。
随时保持代码整洁。测试和弄乱是可以的，但是一旦确定了理想的代码，您就可以去清理所有混乱和未使用的变量。
使用格式化行来分解逻辑块。
我对代码的排列方式很挑剔。这可能只是我的一些强迫症。
我喜欢留下很多笔记，即使只是我在编码。当我必须回到这部分代码时，我想知道什么？
最后使用其中任何一个有帮助并跳过其他的。您将成为这样做的人，因此请选择最好的，如果需要，请选择。
祝福。