概述

如前一篇文章中所討論的那樣, 對于跨平臺智能交易系統(tǒng), 赫茲量化已創(chuàng)建了一個訂單管理器 (COrderManager), 它負責(zé)處理 MQL4 和 MQL5 之間交易入場和離場的大部分差異。在兩個版本中, 智能交易系統(tǒng)通過創(chuàng)建 COrder 的實例將交易信息保存在內(nèi)存中。這些類對象實例的動態(tài)指針容器也可作為 COrderManager 的類成員 (當(dāng)前和歷史交易均可)。

編輯切換為居中

訂單管理器能夠直接處理每筆交易的停止價位。但是, 這樣做會有一些限制:

• COrderManager 有很大可能需要擴展, 以便能夠定制如何處理每筆交易的停止價位。

• COrderManager 的現(xiàn)有方法只能處理主要交易的入場。

可以擴展 COrderManager, 以便它可以自行處理每筆交易的停止價位。不過, 這不僅限于實際價位的設(shè)置, 還涉及有關(guān)停止位監(jiān)控的其它任務(wù), 諸如修改和檢查行情是否已觸及預(yù)定價位。這些功能將致 COrderManager 更復(fù)雜, 而目前并未提及如何拆分實現(xiàn)它。

訂單管理器僅處理主要交易的入場, 而 EA 執(zhí)行其它交易操作時會需要一些停止價位, 例如放置掛單, 以及真實倉位的平倉。雖然訂單管理器可以自行處理它, 但最好將其重點放在主要交易的入場上, 并讓另一個類對象處理停止價位。

在本文中, 赫茲量化將研討具體實現(xiàn), 其中 COrderManager 將專門處理主要交易 (目前為止) 的入場和離場, 然后由另一個單獨的類對象 (CStop) 處理停止價位的實施。

COrder

正如赫茲量化從前一篇文章 (參見 跨平臺智能交易系統(tǒng): 訂單) 中了解到的那樣, 在交易操作 (入場) 成功之后創(chuàng)建了一個 COrder 實例。關(guān)于止損和止盈的信息可以從經(jīng)紀(jì)商的后臺獲取并保存。然而, 如果要對經(jīng)紀(jì)商隱藏停止位或涉及多個停止位的情況下, 關(guān)于這些停止位的更多信息就應(yīng)該被保存在本地。因此, 在后一種情況下, 在倉位成功入場后, 應(yīng)首先創(chuàng)建 COrder 實例, 隨后是代表其止損和止盈價位的對象實例。在早前的文章中, 赫茲量化已演示了如何在創(chuàng)建時將 COrder 實例添加到訂單管理器中, 正如下圖所示:

編輯切換為居中

停止價位以相同的方式添加。為此, 赫茲量化只需要在創(chuàng)建新的 COrder 實例之后, 并在將其添加到進行中交易列表 (COrders) 之前插入該方法。因此, 我們只需稍微修改以上示意圖, 如下圖所示:

編輯切換為居中

創(chuàng)建停止價位的一般操作如下圖所示:

編輯切換為居中

如前面兩個流程圖所示, 一旦交易成功入場, 將會創(chuàng)建一個新的 COrder 實例來表示它。此后, 將為每個已定義的止損和止盈價位創(chuàng)建 COrderStop 的實例。如果在智能交易系統(tǒng)的初始化中沒有聲明 CStop 實例, 則會跳過這一特定過程。另一方面, 如果創(chuàng)建了 COrderStop 的實例, 那么這些實例的指針將被存儲在早前創(chuàng)建的 COrder 實例中。赫茲量化可以在 COrder 的 Init 方法中找到這個操作:

bool COrderBase::Init(COrders *orders,CStops *stops) ?{ ? if(CheckPointer(orders)) ? ? ?SetContainer(GetPointer(orders)); ? if(CheckPointer(stops)) ? ? ?CreateStops(GetPointer(stops)); ? m_order_stops.SetContainer(GetPointer(this)); ? return true; ?}

為了給 COrder 實例創(chuàng)建停止價位, 赫茲量化可以看到它調(diào)用了自身的 CreateStops 方法, 如下所示:

void COrderBase::CreateStops(CStops *stops) ?{ ? if(!CheckPointer(stops)) ? ? ?return; ? if(stops.Total()>0) ? ? { ? ? ?for(int i=0;i<stops.Total();i++) ? ? ? ?{ ? ? ? ? CStop *stop=stops.At(i); ? ? ? ? if(CheckPointer(stop)==POINTER_INVALID) ? ? ? ? ? ?continue; ? ? ? ? m_order_stops.NewOrderStop(GetPointer(this),stop); ? ? ? ?} ? ? } ?}

該方法遍歷 CStop 的所有可用實例, 該實例代表每對止損和止盈價位。這些 CStop 實例中的每一個都傳遞給 COrderStops 的實例, 其中 COrderStops 只是所有給定順序的停止價位的容器。然后, 赫茲量化可以如下構(gòu)造類對象的層次結(jié)構(gòu):

編輯切換為居中

對于 COrder 的每個實例, 都有一個類型為 COrderStops 的成員。這個 COrderStops 實例是一個容器 (CArrayObj 的擴展), 它包含指向 COrderStop 實例的指針。每個 COrderStop 實例代表該特定交易 (COrder 實例) 的停止價位 (CStop)。

CStop

如前所述, 赫茲量化希望有一定的自由度來定制每筆交易的停止價位如何處理, 而無需修改訂單管理器的源代碼。這主要是由 CStop 類完成的。當(dāng)中這個類的職責(zé)是:

1. 定義止損和止盈價位

2. 執(zhí)行計算停止價位所需的計算

3. 主要交易的止損和止盈價位實現(xiàn)

4. 檢查是否已觸發(fā)停止價位

5. 調(diào)整 MQL4 和 MQL5 之間實現(xiàn)止損和止盈價位的差異

6. 定義如何隨時間處理停止位 (例如, 盈虧平衡, 尾隨等)

指針 #1-#5 將在本文中討論, 而 #6 將在單獨一篇文章中討論。

主要停止位

主要停止位是觸發(fā)整體倉位退出的停止價位。通常, 這是經(jīng)紀(jì)商端的停止位。當(dāng)經(jīng)紀(jì)商端的止損或止盈觸發(fā)時, 整體持倉離場, 無論 EA 是否打算為此進一步操作。然而, 如果有多個停止價位, 且無經(jīng)紀(jì)商端的停止位, 那么讓 EA 決定哪個是主要停止位可能是一個壞主意。在這種情況下, 程序員必須選擇哪個 CStop 實例是交易的主要停止位。這對于某些依賴倉位的主要停止位的功能和特性尤為有用, 例如資金管理。由于主要停止位的止損會導(dǎo)致整體持倉的離場, 它代表入場交易的最大風(fēng)險。已知主要停止位的實例, EA 將能夠相應(yīng)地計算手數(shù)。

值得注意的是, 當(dāng)一個停止位被指定為主要停止位時, 其交易量將始終等于主要交易的初始交易量。對于經(jīng)紀(jì)商端和虛擬停止位這將工作良好, 但不適用在基于掛單的停止位。有兩個關(guān)聯(lián)的問題會引出這種方法。

第一個原因是在 赫茲量化中, 在掛單尚未觸發(fā)前可以修改入場價格。在赫茲量化中, 這是不可能的, 因為必須維護交易操作的清晰足跡。必須放出新的掛單, 如果成功, 應(yīng)刪除舊訂單, 然后智能交易系統(tǒng)應(yīng)使用新掛單作為新的停止價位。

第二個問題是給經(jīng)紀(jì)商發(fā)送替換掛單時, 舊的掛單可能被同時觸發(fā)。由于 EA 對觸發(fā)掛單沒有控制權(quán) (只有經(jīng)紀(jì)商可以), 這會導(dǎo)致諸如孤立交易或一個停止價位超預(yù)期將更多持倉平倉等問題。

為了避免這些問題, 更簡單的方法是在交易創(chuàng)建時分配掛單的交易量, 而非在主要交易的整個生存期內(nèi)動態(tài)調(diào)整掛單的交易量。不過, 這就要求如果主停止位為掛單類型, 則不應(yīng)有其它掛單停止位。