构建自动运行的策略（第 07 部分）：账户类型（II）

概述

在上一篇文章构建自动运行的策略（第 06 部分）：账户类型（I）中，我们着手开发一种方式来确保自动策略正常工作，并符合其预期目的。在那篇文章中，我们创建了 C_Manager 类，它充当管理员，以便在出现奇怪或不正确的策略行为时，能把策略从图表中删除。

我们首先解释了如何防止 策略 的挂单或市价单触发。 尽管此处显示的机制能够支持 策略，但我们还还有一些与 策略 和 C_Orders 类之间交互相关的其它问题。 该问题主要与净持结算账户有关。 这是本文要涵盖的主题之一。​

然而，无论如何，您永远不应该让自动 策略 在无人监督的情况下运行。​

不要指望编写 策略 仅仅运用智能编程就足够了，因为事实并非如此。 您应该始终明白自动 策略 正在做什么，如果它的动向超出了为其划定的范畴，请在它失控之前尽快将其从图表中删除。​

策略和 C_Orders 类之间交互的新例程

如果 策略 能够继续访问 C_Orders 类，则前面文章中所说的一切都将毫无价值，如下所示：​

代码块

//+------------------------------------------------------------------+void CreateOrder(const ENUM_ORDER_TYPE type, const double Price)​
                        {​
                                C_Orders::CreateOrder(type, Price, m_InfosManager.FinanceStop, m_InfosManager.FinanceTake, m_InfosManager.Leverage, m_InfosManager.IsDayTrade);​
                        }​
//+------------------------------------------------------------------+  void ToMarket(const ENUM_ORDER_TYPE type)​
                        {​
                                C_Orders::ToMarket(type, m_InfosManager.FinanceStop, m_InfosManager.FinanceTake, m_InfosManager.Leverage, m_InfosManager.IsDayTrade);​
                        }​
//+------------------------------------------------------------------+​

请注意，即使我们尝试限制和控制事态，策略 仍会设法将订单发送到市场，并新订单发送到订单簿。 这是一个安全漏洞，因为如果在 策略 初始化期间 C_Manager 类设法强加它将遵循某些规则，那么为什么在那之后，我们又允许它能够下订单，并执行市场操作呢？ 我们必须在这里设定一些限制，即使它非常简单。 一个简单的测试通常可以防止多种潜在问题。 故此，针对 策略 和 C_Orders 类中存在的订单系统之间的交互形式，我们添加一些覆盖整个区域的控制。​

代码块

//+------------------------------------------------------------------+void CreateOrder(const ENUM_ORDER_TYPE type, const double Price)​
                        {​
                                if ((m_TicketPending > 0) || (m_bAccountHedging && (m_Position.Ticket > 0))) return;m_TicketPending = C_Orders::CreateOrder(type, Price, m_InfosManager.FinanceStop, m_InfosManager.FinanceTake, m_InfosManager.Leverage, m_InfosManager.IsDayTrade);​
                        }​
//+------------------------------------------------------------------+  void ToMarket(const ENUM_ORDER_TYPE type)​
                        {​
                                ulong tmp;​
                                ​
                                if (m_bAccountHedging && (m_Position.Ticket > 0)) return;​
                                tmp = C_Orders::ToMarket(type, m_InfosManager.FinanceStop, m_InfosManager.FinanceTake, m_InfosManager.Leverage, m_InfosManager.IsDayTrade);​
                                m_Position.Ticket = (m_bAccountHedging ? tmp : (m_Position.Ticket > 0 ? m_Position.Ticket : tmp));if (PositionSelectByTicket(m_Position.Ticket)) SetInfoPositions(); else m_Position.Ticket = 0;​
                        }​
//+------------------------------------------------------------------+​

我们已添加了一些规则，如此 策略 在使用 C_Orders 类时就没有那么多的自由。 我们来看看在此发生了什么。 我们从 CreateOrder 函数开始。如果在示意挂单单号的变量中我们得到一个有效值，则发送新订单将被拒绝；如果在对冲账户上我们若已有一笔持仓，该订单也将被拒绝。 就这么简单。 但是，如果这些条件允许，我们可以发送将挂单添加到订单簿的请求，如果请求成功，我们将获得已下订单的单号。 之后，我们就无法再发送新订单。​

现在遇到一个大细节，即位于 ToMarket 函数当中。 在这种情况下，订单作为市价订单下达，即按最佳可用价格执行。 现在我们来看看允许我们发送市价单的条件。 仅当在对冲账户上我们尚无持仓时，才允许发送订单。 这是详细信息： 如果可以发送市价订单，则将完成此操作，但我们不能使用首次调用返回的值。 这是因为这样的事实，如果我们在净持结算账户上，该数值也许与来自持仓的单号不同。 如果直接在持仓单号中设置该值，则可能会丢失实际的单号，因为在这种情况下，返回值可能只是临时的。 这就是我们在此进行这项新检查的原因。如果这是一个对冲账户，那么返回的值可以安全地存储在持仓单号之中。 但在净持结算账户的情况下，只有当持仓单号为零时，才会保存；否则，该值将被忽略。 一旦此操作完成后，我们可以更新持仓数据，或重置持仓单号值，但这完全取决于检查结果。​

自动策略中的净持结算账户问题

在净持结算账户上使用自动 策略 时存在的潜在危险问题。 在上一篇文章中，我展示了对冲账户中可能发生的问题。 但现在我们来探讨一个不同的问题，它只会发生在净持结算账户上。 如果 策略 没有锁，它会在某个时候遇到这个漏洞，许多 策略 都存在这个漏洞，但它们的用户并不知晓。​

问题如下：在净持结算账户上，当品种的出价发生变化时，交易服务器将自动为多头或空头创建持仓平均价格。 如果您以一种或其它方式做空，平均价格以及持仓量将发生变化。​

对于手动操作的 策略，这里没有问题，因为交易者将负责向服务器发送所有请求。 问题出现于自动 策略。 在这种情况下，当其编程中存在一定的差距或漏洞时，它就容易被触发。 细节：问题不在于交易服务器，也不在于 MetaTrader 5 平台；问题出在 策略 当中。​

我将尝试以每个人都能理解的方式进行解释，但理想情况下，您应该对市场如何运作有一些了解，如此才更容易理解。 但我会尽量把问题说清楚。​

当自动 策略 发送买入或卖出订单意图开仓时，它会基于某种触发器进行。 虽然我们还没有讨论触发器，但我们很快就会到达那里。 但问题亦不在于触发因素，因为在绝大多数情况下，触发因素是不负责任的。​

一旦开仓，并且在净持结算账户中，策略 出于某种原因可以遵循策略：关闭交易量的一部分，然后另开一笔。 按这种方式，平均价格将开始移动。 问题是，也许 策略 会开始以一种野蛮、疯狂、和幻觉般的方式来做。 如果发生这种情况，它可能会在几分钟内导致大量资金损失，有时甚至只需几秒钟，具体取决于交易量。​

而这就是问题所在：策略 发起订单，然后它滞留在那里而不平仓，且向服务器发送新请求以更改平均价格。 这通常发生在没有交易者在场的情况下，交易者应该监督 策略，因为所示的持仓数量没有变化，但价格会改变，且一些交易者没有注意到这种变化。 经常发生的情况是，在交易者真正注意到那里有问题之前，持仓已经造成了巨大的损失。​

尽管一些自动 策略 在编写时故意采用这种类型的策略，但有些人不知道或意识到他们的自动 策略 中存在这种类型的错误。 在某些情况下，会遇到触发因素的问题，有人也许正用一类触发器，令 策略 买入或卖出，并且在某些非常特定的市场状况下，策略 也许会遵照上述进行操作。 如果意识到这一事实，交易者会有所提防。 但如果这种行为并非预期的，那么监督 策略 的交易者最终可能会被 策略 将要做的事情吓到。​

不要低估系统，无论您多么信任它，并相信您的自动 策略 是安全的。 千万不要低估它。因为任何意外都可能发生，从而令 策略 隐藏您在编程时没有预见到的漏洞。 但幸运的是，有一个相对简单的方法可以克服这个缺陷，至少可以稍微减少它的损害。 故此，我们来看看如何在编程方面做到这一点。​

限制策略中的交易量

最简单方法是减低，至少要一点点，针对在上一个主题中讲述的问题，限制 策略 实际可取的交易量。 没有十全十美的方法，但我们可以尽可能多地尝试，产生一些可以给我们带来一些安慰的形式。 最简单的方法是限制 策略 在整个运行期间可以采用的交易量。​

请注意：我不是说限制持仓的交易量，而是限制 策略 在整个期间进行交易的交易量。 也就是说，策略 可以按最小交易量的 x 倍进行交易，而一旦达到限制，策略 就无法再加仓。 如果一笔持仓的仓位仅相当于最小交易量，而限制是这个交易量的 50 倍，这无所谓；如果 策略 已达到该 50 的配额，那么它将无法再加仓。​

锁定正是基于此。 但我们这里有一个细节：没有 100% 安全锁定这样的东西。 一切都取决于监督 策略 的交易者。 如果交易者无意中关停了锁定，重新启动 策略，则交易者需对可能发生的任何灾难负责。 正如可能发生的那样，策略 达到了配额，交易者重新启动图表上的 策略。 在这种情况下，锁定失效。​

为了实现锁定，我们需要在 C_Manager 类中定义一个静态、全局和私密的变量。 如在下面的代码中所示：​

构建自动运行的策略（第 07 部分）：账户类型（II）​

构建自动运行的策略（第 07 部分）：账户类型（II）