结构规则。 学习如何构建方案，探索可能性、错误、解决方案等。 - 页 7 1234567891011121314...20 新评论 Vladimir Gomonov 2013.07.22 22:40 #61 Urain:我建议把基本的设计模式摆出来。1.职能部门2.对象模型3.事件驱动的....键入4.组成部分--一般来说，任何程序（包括你打算的程序）都可以从不同角度来看。//这是可以理解的。在对一个项目的初步分析中，我试图至少考虑4个方面。1.结构：程序代码和程序组件的物理和逻辑组织。2.功能性（不要与开发中的功能性方法相混淆）：程序解决什么任务（产生什么产品），它的用途是什么，它应该产生什么输出，等等。3.交流性：程序应该有什么样的用户界面，它 与哪些程序交流，如何交流，交流协议，等等。4.管理方面：软件如何管理，需要做哪些设置，自由度等。所有的方面都是密不可分的，但从这些不同的角度（+一些更多的角度）来看，你就不会错过重要的微妙之处，在早期阶段就不会对一些具有深远影响的重要事情打哈欠。) Denis Kirichenko 2013.07.23 06:08 #62 MetaDriver:...一般来说，任何方案（包括构想的方案）都可以从不同的角度来看待。//这是可以理解的...我完全同意。这是一个一般的哲学原则--从不同的角度来研究一个现象。而我正在试图回答 "一个程序应该做什么，不应该做什么 "的问题，在开发之初。问题的第一部分属于系统内（这里是MTS），第二部分不属于，是在系统外。我认为，不管是什么设计 模型，有一个模型元素的层次结构是非常重要的。然后，演绎法--"从一般到特殊"--就能很好地发挥作用，将模型分解为其主要和构成部分。 Vasiliy Sokolov 2013.07.23 06:47 #63 MetaDriver:为了交流思想/互相学习，我提议拿一个或多或少的实际问题，一起进行重组。例如，至少要为这样的问题勾勒出基本结构（或更准确地说，这种结构的变体）。有一个专家顾问是这样写的（例如，用于测试一个交易想法）。 让我们假设策略测试器中的想法（在客户端）显示出有希望的结果。 现在我们需要重写专家顾问，使其更适合开发。特别是，为其提供一个图形化的用户控制面板。最好是使面板可以切换（在测试器中进行优化），或者将整个EA的 "非图形 "实现转移到一个可插拔的文件（.mqh）中，然后可以连接到图形界面，而不改变（排除）"测试器 "和 "图形 "版本操作上的差异。我想听听看关于这样一个项目的结构的考虑，特别是关于在这样一个项目中实施事件驱动控制模型。假设双重实施（测试员+面板）是客户的严格要求（即项目必须以任何方式完成，你只能选择实施的方法）。我们可以试试这个任务吗？我认为很明显，专家顾问控制面板和专家顾问是一个程序中两个完全不同的模块。因此，它们需要以这样一种方式分开，即每个部分都独立于另一个部分。这意味着，如果你改变专家顾问的一部分（例如，改变下单的逻辑），你不必改变面板的逻辑，反之亦然（改变面板的界面 - 不需要改变专家顾问的逻辑）。首先想到的是创建一个统一的界面，通过这个界面，面板和专家顾问可以进行交流。但不幸的是，MQL5的创建者还没有考虑到创建水平链接的可能性，因此，通过MQL5来描述它们之间的接口是行不通的。那么垂直整合的方式仍然存在。专家顾问必须继承自一个基类，而基类又包含足以与面板互动的方法和数据。这意味着任何从基类继承的EA也将能够显示并与面板互动。负责与面板交互的方法的实现不能委托给子代，而必须在基类的幕后完成，即 "子代！"的消息。如果你想与面板互动，你必须用这样那样的参数调用我的这样那样的方法 "根本不起作用。理想情况下，任何继承自基类的派生专家顾问都应该以一种方便的方式进行交易，其行动将自动显示在这个面板上。如何组织一个通用的基类是一个单独的有趣的话题。在这个问题上几年的实践，终于使我找到了我的普遍方案。事实证明，它是透明和普遍的。如果你有兴趣，我可以向你提供它的基本流程图（哈哈，毕竟画流程图是一项非常有用的活动）。但无论如何，每个人都有自己的方式，一个人的好办法不会是另一个人的好办法。 --- 2013.07.23 07:42 #64 C-4:如果有兴趣，我可以给你一张原理图（哈哈，画方框图毕竟是一种有用的活动）。 Vladimir Gomonov 2013.07.23 08:16 #65 sergeev: 终于有东西清理出来了....) Vladimir Gomonov 2013.07.23 08:32 #66 C-4:首先想到的是创建一个统一的界面，通过它面板和EA可以交换数据。 不幸的是，MQL5的创建者没有提供创建水平链接的可能性，因此，使用MQL5工具描述它们之间的接口是不可能的。 1. 毫不含糊地。2.自定义事件呢？ 它是相当水平和普遍的。3.那么垂直整合的方式依然存在。专家顾问必须继承自一个基类，而基类又包含足以与面板互动的方法和数据。这意味着任何从基类继承的专家顾问也获得显示和与面板互动的能力。负责与面板交互的方法的实现不能委托给子代，而必须在基类的幕后完成，即 "子代！"的消息。如果你想与面板互动，你必须用这样那样的参数调用我的这样那样的方法 "根本不起作用。理想情况下，任何从基类继承的派生专家顾问应该只是以一种方便的方式进行交易，而其行动将自动显示在该面板上。由于我不同意第2点，所以我还没有挖到这个变体。--我有一个替代方案，我觉得非常有吸引力（带有 "可断开 "面板的变体）。 把面板做成指标的形式。 如果你的专家顾问在策略测试器中，它根本不会加载面板。额外的好处是，面板在不同的线程中运行，为专家顾问留下更多的资源。至于面板的多功能性，我认为面板通过ini文件进行完全配置没有任何重大障碍。换句话说，你可以从一组有限的视觉组件+事件代码中规定创建任何面板所需的绝对所有数据，它们在与用户互动时应该产生。如何安排一个通用的基础交易类是一个单独的有趣话题。几年来在这个问题上的实践，终于使我找到了我的普遍方案。事实证明，它是透明和普遍的。如果你有兴趣，我可以给你看它的基本框图。.... 来吧，我甚至非常感兴趣。 而且实际上它可以是有用的。 TheXpert 2013.07.23 08:36 #67 MetaDriver:1. 毫不含糊地。Nahr 为什么？过度普遍化和过早优化一样邪恶。并通过事件绑定一个模块的块......是缓慢和不方便的。 Vasiliy Sokolov 2013.07.23 10:10 #68 MetaDriver:来吧，我其实很感兴趣，它在实践中可能很有用。蓝色框架是基础类实体。红框是派生类的实体。你可以看到，基类在四个方法中把它的逻辑定义强加给子类。这就是它把对任何策略的描述减少到只描述四种情况的方式。1.如果所有的多头头寸开仓规则都被遵守，多头头寸就会在InitBuy()方法中开仓。2.如果所有的多头头寸平仓规则得到满足--多头头寸使用SupportBuy()方法平仓。 3.如果所有的空头头寸开仓规则都得到满足--那么就用InitSell()方法开出空头头寸。4.如果关闭空头头寸的所有规则都得到满足--那么空头头寸将在SupportSell()方法中关闭。根据这一逻辑，策略反转不是用一种方法（例如，收长开短）来描述，而是用两种互不相干的方法。事实证明，这种方法非常方便，因为它允许我们，例如，在满足一些可在基类中描述的一般条件后，一键禁止卖出或强行平仓。在某些情况下，一个策略有销售和购买的一般数据，这些数据应该在某些事件发生时重新计算，例如，新酒吧的到来。在这种情况下，一个策略有可能向事件订阅自己的处理方法。用这些方法不可能开仓，但可以进行各种计算。 另一个有趣的问题是如何处理未结头寸。基类存储了一个单独的多头和空头列表。当一个新的事件发生时（例如，OnTick），该类开始列出所有未结头寸，并提供使用方法SupportBuy SupportSell逐一处理这些头寸。这些方法只能关闭基类此刻提供给它们的位置。所有其他位置都是只读的。因此，基类将这一想法强加给了它的后代，即目前它们必须只关注一个位置。当我测试这个想法时，事实证明，即使是最复杂的专家顾问的逻辑也要简单得多。此外，它还为对冲的概念提供了自动支持，因为专家顾问会保留其多头和空头的信息。 GaryKa 2013.07.23 10:31 #69 TheXpert: ...交易部分的实施取决于策略，所以在假设的策略框架内没有什么可讨论的。奇怪的是，战略的实施也取决于战略:)MetaDriver: ...整个交易部分是以一个类（CMarketDriver）的形式编写的，它完全实现了下单、仓位跟踪、重新报价和其他交易相关的东西。对于所有的符号都是一次性的。策略部分只输入符号的推荐市场头寸，即填充{string Instrument; double Position}格式的结构数组，并请求与服务器同步：MD.Synchronize(PositionArray)。 这就是全部。目前，它只用市场订单进行交易，但用点 差内设置的限额进行交易（以减少交易成本）的版本即将推出。对于交易来说，止盈/止损是不使用的，但是MarketDriver可以在与服务器长时间失去连接的情况下设置保护性止损（止损参数在驱动设置中指定一次）。 顺便说一下，这是一个非常成功的、几乎没有问题的结构性解决方案。 对于在测试器中测试战略思想--交易没有问题，所有注意力都可以放在战略上--所有交易早已在交易驱动中调试和封装好了。只要你开始将策略的执行转化为限价订单，你就会莫名其妙地收到很多问题。你的限价器对击中你的策略部分（分析器/预测器/大脑）的价格的影响。多币种战略的同步化在趋势交易中一直没有执行力（拖网？ 如果是，怎么拖，还是吐槽和跟风？）部分执行...然后，必须在 "执行者 "和 "分析者 "之间实现反馈，此外，这种非理想运动的参数应该以某种方式建立在分析者的数学模型中。MetaDriver: ...在测试器中检查战略思想，一首歌 - 没有问题的交易... 是的，对于限制者来说，这真的是一首歌。 TheXpert 2013.07.23 11:11 #70 GaryKa:当你开始将策略中的执行彻底转换为限价订单时 这只是我所说的一个例子 -- 交易部分取决于策略。 1234567891011121314...20 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我建议把基本的设计模式摆出来。
1.职能部门
2.对象模型
3.事件驱动的.
...
键入
4.组成部分
--
一般来说，任何程序（包括你打算的程序）都可以从不同角度来看。//这是可以理解的。
在对一个项目的初步分析中，我试图至少考虑4个方面。
1.结构：程序代码和程序组件的物理和逻辑组织。
2.功能性（不要与开发中的功能性方法相混淆）：程序解决什么任务（产生什么产品），它的用途是什么，它应该产生什么输出，等等。
3.交流性：程序应该有什么样的用户界面，它 与哪些程序交流，如何交流，交流协议，等等。
4.管理方面：软件如何管理，需要做哪些设置，自由度等。
所有的方面都是密不可分的，但从这些不同的角度（+一些更多的角度）来看，你就不会错过重要的微妙之处，在早期阶段就不会对一些具有深远影响的重要事情打哈欠。)
...一般来说，任何方案（包括构想的方案）都可以从不同的角度来看待。//这是可以理解的...
我完全同意。这是一个一般的哲学原则--从不同的角度来研究一个现象。
而我正在试图回答 "一个程序应该做什么，不应该做什么 "的问题，在开发之初。问题的第一部分属于系统内（这里是MTS），第二部分不属于，是在系统外。
我认为，不管是什么设计 模型，有一个模型元素的层次结构是非常重要的。然后，演绎法--"从一般到特殊"--就能很好地发挥作用，将模型分解为其主要和构成部分。
为了交流思想/互相学习，我提议拿一个或多或少的实际问题，一起进行重组。
例如，至少要为这样的问题勾勒出基本结构（或更准确地说，这种结构的变体）。
有一个专家顾问是这样写的（例如，用于测试一个交易想法）。 让我们假设策略测试器中的想法（在客户端）显示出有希望的结果。 现在我们需要重写专家顾问，使其更适合开发。特别是，为其提供一个图形化的用户控制面板。
最好是使面板可以切换（在测试器中进行优化），或者将整个EA的 "非图形 "实现转移到一个可插拔的文件（.mqh）中，然后可以连接到图形界面，而不改变（排除）"测试器 "和 "图形 "版本操作上的差异。
我想听听看关于这样一个项目的结构的考虑，特别是关于在这样一个项目中实施事件驱动控制模型。假设双重实施（测试员+面板）是客户的严格要求（即项目必须以任何方式完成，你只能选择实施的方法）。
我们可以试试这个任务吗？
我认为很明显，专家顾问控制面板和专家顾问是一个程序中两个完全不同的模块。因此，它们需要以这样一种方式分开，即每个部分都独立于另一个部分。这意味着，如果你改变专家顾问的一部分（例如，改变下单的逻辑），你不必改变面板的逻辑，反之亦然（改变面板的界面 - 不需要改变专家顾问的逻辑）。首先想到的是创建一个统一的界面，通过这个界面，面板和专家顾问可以进行交流。但不幸的是，MQL5的创建者还没有考虑到创建水平链接的可能性，因此，通过MQL5来描述它们之间的接口是行不通的。那么垂直整合的方式仍然存在。专家顾问必须继承自一个基类，而基类又包含足以与面板互动的方法和数据。这意味着任何从基类继承的EA也将能够显示并与面板互动。负责与面板交互的方法的实现不能委托给子代，而必须在基类的幕后完成，即 "子代！"的消息。如果你想与面板互动，你必须用这样那样的参数调用我的这样那样的方法 "根本不起作用。理想情况下，任何继承自基类的派生专家顾问都应该以一种方便的方式进行交易，其行动将自动显示在这个面板上。
如何组织一个通用的基类是一个单独的有趣的话题。在这个问题上几年的实践，终于使我找到了我的普遍方案。事实证明，它是透明和普遍的。如果你有兴趣，我可以向你提供它的基本流程图（哈哈，毕竟画流程图是一项非常有用的活动）。但无论如何，每个人都有自己的方式，一个人的好办法不会是另一个人的好办法。
如果有兴趣，我可以给你一张原理图（哈哈，画方框图毕竟是一种有用的活动）。
首先想到的是创建一个统一的界面，通过它面板和EA可以交换数据。
不幸的是，MQL5的创建者没有提供创建水平链接的可能性，因此，使用MQL5工具描述它们之间的接口是不可能的。
1. 毫不含糊地。
2.自定义事件呢？ 它是相当水平和普遍的。
3.那么垂直整合的方式依然存在。专家顾问必须继承自一个基类，而基类又包含足以与面板互动的方法和数据。这意味着任何从基类继承的专家顾问也获得显示和与面板互动的能力。负责与面板交互的方法的实现不能委托给子代，而必须在基类的幕后完成，即 "子代！"的消息。如果你想与面板互动，你必须用这样那样的参数调用我的这样那样的方法 "根本不起作用。理想情况下，任何从基类继承的派生专家顾问应该只是以一种方便的方式进行交易，而其行动将自动显示在该面板上。
由于我不同意第2点，所以我还没有挖到这个变体。
--
我有一个替代方案，我觉得非常有吸引力（带有 "可断开 "面板的变体）。 把面板做成指标的形式。 如果你的专家顾问在策略测试器中，它根本不会加载面板。额外的好处是，面板在不同的线程中运行，为专家顾问留下更多的资源。
至于面板的多功能性，我认为面板通过ini文件进行完全配置没有任何重大障碍。换句话说，你可以从一组有限的视觉组件+事件代码中规定创建任何面板所需的绝对所有数据，它们在与用户互动时应该产生。
如何安排一个通用的基础交易类是一个单独的有趣话题。几年来在这个问题上的实践，终于使我找到了我的普遍方案。事实证明，它是透明和普遍的。如果你有兴趣，我可以给你看它的基本框图。....
1. 毫不含糊地。
Nahr 为什么？过度普遍化和过早优化一样邪恶。
并通过事件绑定一个模块的块......是缓慢和不方便的。
来吧，我其实很感兴趣，它在实践中可能很有用。
蓝色框架是基础类实体。红框是派生类的实体。你可以看到，基类在四个方法中把它的逻辑定义强加给子类。这就是它把对任何策略的描述减少到只描述四种情况的方式。
1.如果所有的多头头寸开仓规则都被遵守，多头头寸就会在InitBuy()方法中开仓。
2.如果所有的多头头寸平仓规则得到满足--多头头寸使用SupportBuy()方法平仓。
3.如果所有的空头头寸开仓规则都得到满足--那么就用InitSell()方法开出空头头寸。
4.如果关闭空头头寸的所有规则都得到满足--那么空头头寸将在SupportSell()方法中关闭。
根据这一逻辑，策略反转不是用一种方法（例如，收长开短）来描述，而是用两种互不相干的方法。事实证明，这种方法非常方便，因为它允许我们，例如，在满足一些可在基类中描述的一般条件后，一键禁止卖出或强行平仓。
在某些情况下，一个策略有销售和购买的一般数据，这些数据应该在某些事件发生时重新计算，例如，新酒吧的到来。在这种情况下，一个策略有可能向事件订阅自己的处理方法。用这些方法不可能开仓，但可以进行各种计算。
另一个有趣的问题是如何处理未结头寸。基类存储了一个单独的多头和空头列表。当一个新的事件发生时（例如，OnTick），该类开始列出所有未结头寸，并提供使用方法SupportBuy SupportSell逐一处理这些头寸。这些方法只能关闭基类此刻提供给它们的位置。所有其他位置都是只读的。因此，基类将这一想法强加给了它的后代，即目前它们必须只关注一个位置。当我测试这个想法时，事实证明，即使是最复杂的专家顾问的逻辑也要简单得多。此外，它还为对冲的概念提供了自动支持，因为专家顾问会保留其多头和空头的信息。只要你开始将策略的执行转化为限价订单，你就会莫名其妙地收到很多问题。
然后，必须在 "执行者 "和 "分析者 "之间实现反馈，此外，这种非理想运动的参数应该以某种方式建立在分析者的数学模型中。
MetaDriver: ...在测试器中检查战略思想，一首歌 - 没有问题的交易...
当你开始将策略中的执行彻底转换为限价订单时