Новая статья: Универсальный торговый эксперт: Событийная модель и прототип торговой стратегии (Часть 2)

[MetaQuotes]

На mql5.com опубликована статья Универсальный торговый эксперт: Событийная модель и прототип торговой стратегии (Часть 2):

Данная статья продолжает серию заметок, посвященных универсальной модели эксперта. В этой части описывается оригинальная событийная модель на основе централизованной обработки данных, а также рассматривается структура базового класса движка — CStrategy.

Данная статья продолжает знакомить читателей с универсальным торговым движком CStrategy. В первой статье Универсальный торговый эксперт: Торговые режимы стратегий (Часть 1) были подробно разобраны торговые режимы и функции по их организации. Была предложена универсальная схема эксперта, состоящая из четырех методов, два из которых открывают новые позиции а другие два — закрывают. Разная комбинация вызовов этих методов определяет тот или иной торговый режим, например, такому эксперту можно задать режим только покупок или только продаж, сопровождение ранее открытых позиций или режим ожидания. Благодаря этим режимам эксперт приобретает возможность гибкой настройки своей работы в зависимости от торгового времени или даже дня недели.

Однако торговые режимы — далеко не единственное, что может понадобиться торговому эксперту. В данной, второй части серии статей пойдет речь о событийной модели торгового движка CStrategy на основе централизованной обработки событий. Предлагаемая схема обработки событий отличается от системных событий тем, что все события собираются в одном месте. О преимуществах, которые дает такая организация, будет написано ниже.

Также в данной статье описываются два важнейших класса всего торгового движка — это классы CStrategy и CPosition. Первый из них является ядром всей торговой логики эксперта, он объединяет события и режимы в единый гибкий каркас, который непосредственно наследует эксперт пользователя. Второй класс является основой универсальных торговых операций. В него помещены действия с открытой позицией (например закрытие позиции или изменение ее уровня Stop Loss или Take Profit). Благодаря этому все торговые действия становятся однотипными и платформонезависимыми.

Доступ к событиям, происходящим на других инструментах, структура MarketEvent

При проектировании торговой системы, анализирующей сразу несколько инструментов, как правило, требуется создать механизм, отслеживающий изменение цен на нескольких инструментах. Однако штатная функция OnTick вызывается только в момент прихода нового тика на том инструменте, на котором был запущен эксперт. С другой стороны, в распоряжении разработчиков торговых систем имеется функция OnBookEvent, реагирующая на изменения стакана. В отличие от OnTick, функция OnBookEvent будет вызываться при изменении стакана того инструмента, на который была осуществлена подписка с помощью функции MarketBookAdd.

Изменение стакана — очень частое событие, а потому отслеживание этого события — достаточно ресурсоемкая процедура. Как правило, эксперту достаточно отслеживать изменения тикового потока на других инструментах. С другой стороны, событие изменение стакана включает в себя также приход нового тика. Помимо OnBookEvent, с заданной периодичностью можно настроить вызов OnTimer и уже в этой функции анализировать изменившиеся цены нескольких инструментов.

Таким образом, в системных функциях, реагирующих на события NewTick, BookEvent и Timer, можно разместить вызов некоего промежуточного модуля (назовем его условно EventProcessor), который бы в свою очередь анализировал изменение цен на нескольких инструментах одновременно и генерировал бы то или иное событие. Каждое событие имело бы унифицированное описание в виде структуры и отправлялось бы управляющим методам стратегии. Стратегия, получив соответствующее событие в виде структуры, реагировала бы на него или пропускала. При этом системная функция, которая была бы фактическим инициатором этого события для конечного эксперта, оставалось бы неизвестной.

В самом деле, если эксперт получил уведомление о приходе нового тика, то не имеет значения, как была получена данная информация: через OnTick, OnTimer или OnBookEvent. Важно лишь то, что новый тик для указанного инструмента действительно пришел. Обработчик событий может быть один на несколько стратегий. Например, если каждую стратегию представить в виде пользовательского класса, то сразу несколько экземпляров этих классов можно хранить в специальном списке стратегий. При этом каждая из стратегий списка имела бы возможность получения нового события, генерируемого модулем EventProcessor. Схематично модель создания и распространения событий можно представить на следующем графике:

Рис. 1. Схема создания и распространения событий

Автор: Vasiliy Sokolov