главные правила написания советников ну это не для ленивых людей так что нужно почитать и разобратся

Прототип торгового робота [ en ]

Введение

Жизненный цикл любой торговой системы сводится к закрытию и открытию позиции. Это ни у кого не вызывает споров. Но в то время, когда дело доходит до реализации метода, то тут, как говорится, сколько программистов, столько и точек зрения.

Любой сможет решить одну и ту же задачу своим собственным методом, но с однообразным окончательным результатом.

За годы практики программирования было перепробовано пара подходов к построению структуры и логики специалистов. Сейчас возможно утверждать, что создана четкая схема шаблона, что используется во всех кодах.

Данный подход не есть на 100% универсальным, но он может поменять ваш способ проектирования логики специалиста. И дело кроме того не в том, какие конкретно возможности работы с ордерами вы желаете применять в специалисте, вся сущность – в том принципе. что закладывается при построении торговой модели.

1. Правила проектирования торговых систем и виды источников событий

Главным подходом к проектированию метода, которым пользуются большая часть, есть отслеживание судьбы одной позиции от момента открытия и до закрытия. Это линейный подход. И в случае если требуется внести трансформации в код – это довольно часто ведет к громадным усложнениям, поскольку появляется код и большое число условий обрастает новыми ветками анализа.

Лучшим ответом для построения модели торгового робота есть «обслуживание состояний». А фундаментальный принцип – это анализ не того, как появилось данное состояние его позиций и эксперта и ордеров – а того, что с ними следует сделать на данный момент. Данный базисный принцип в корне меняет управление торговлей и упрощает разработку кода.

Разглядим его более детально.

1.1. Принцип «обслуживание состояний»

Как уже было сообщено, специалисту не требуется знать, как достигнуто текущее состояние. Он обязан знать, что с ним делать в текущий момент в соответствии с собственному окружению (значения параметров, запомненные характеристики ордеров и т.д.).

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

К примеру, вам нужно удалить все отложенные ордера специалиста и лишь затем продолжить выставление новых и анализ индикаторов ордеров. Большая часть примеров кода, каковые приходилось видеть, применяют зацикливание типа while (true) либо чуть помягче while (k

Данный метод линейный, он «вешает» специалист на неизвестное время.

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

В случае если случится торговая неточность, то специалист предстоящий анализ и работу до следующего цикла.

1.2. Второй фундаментальный принцип проектирования – это максимальное абстрагирование от разглядываемого направления позиции (приобретение/продажа), графика и валюты. Все функции специалиста должны реализовываться так, дабы явный анализ контролируемого направления либо знака осуществлялся в редких случаях, в то время, когда этого вправду избежать запрещено (к примеру, в то время, когда вы разглядываете благоприятное развитие цены для открытой позиции, не смотря на то, что и тут вероятны варианты ухода от конкретики).

Неизменно старайтесь избегать для того чтобы низкоуровневого проектирования. Это разрешит сократить сам процесс и код написания функций минимум вдвое. И сделает их «торгово-свободными».

Реализация данного принципа содержится в подмене явного анализа типов ордеров, параметров знака и зависимых от них расчетных параметров на функции-макросы. Потом в статье мы разглядим их реализации более детально.

1.3. Третий принцип – разделение метода на логически лексемы (свободные модули)

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

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

Эти три принципа разрешают создать единый прототип всех специалистов, что возможно легко изменять и подстраивать под любую конкретную задачу.

Источниками событий для экспертной совокупности являются:

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

Реже для их корректировки (в большинстве случаев трейлинг Stop Loss либо отложенного ордера по индикатору).

К примеру, практической реализацией работы с индикаторами возможно назвать специалист, разбирающий пересечение стремительной и медленной МА с предстоящим открытием позиции в сторону пересечения.

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

Несложным примером специалиста, основанного лишь на торговом событии, есть доливка для сглаживания имеющейся позиции и вывод её в требуемый профит. Другими словами, наличие убытка на имеющейся позиции будет являться событием для отправки нового усредняющего ордера.

Либо, к примеру, трейлинг Stop Loss. Для данной функции проверяется событие, в то время, когда цена отходит в профит на указанное число пунктов от прошлого положения Stop Loss. В следствии чего специалист подтягивает Stop Loss за ценой.

3. Внешние события. И не смотря на то, что в чисто экспертной совокупности это событие в большинстве случаев не имеет место, но в общем случае его стоит разглядывать для принятия ответа. Ко мне относится корректировка пользователем ордеров, позиций, обработка торговых неточностей, обработка событий с графика (перемещение/создание/удаление объектов, нажатие кнопок и т.д.).

В общем, это все события, каковые не поддаются проверке на истории и появляются лишь в ходе работы специалиста.

хорошим примером таких специалистов являются торгово-информационные совокупности с графическим управлением торговлей.

Все многообразие специалистов строится на комбинации этих трех источников событий

2. Базисный класс CExpertAdvisor – конструктор специалистов

Что же будет воображать собой работа торгового специалиста? Неспециализированная схема связей MQL-программы приведена на схеме ниже.

Рисунок 1. Неспециализированная схема связей элементов программы на MQL5

Как видно из схемы, на первом замысле стоит вход в рабочий цикл (это возможно тик либо сигнал таймера). На этом этапе в первом блоке имеется возможность отфильтровать данный тик без его обработки. Это делается в тех случаях, в то время, когда работа специалиста не нужна на каждом тике, а лишь при появлении нового бара либо в случае если специалисту легко не разрещаеться трудиться.

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

Эту последовательность возможно назвать схемой с прямой логикой, поскольку в ней сперва определяется «ЧТО» будет делать специалист (какие конкретно употребляются модули обработки событий) и лишь позже реализуется «КАК» и «Из-за чего» он будет это делать (получение сигналов событий).

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

Проектирование специалистов в этом замысле не исключение. Сперва объявляется, что обязан делать специалист (открывать и закрывать позиции, подтягивать защитный стоп), и лишь позже детализируется, при каких событиях и как он обязан это делать. Но ни в коем случает не наоборот: взяли сигнал, и думаем, куда его прописать и чем обработать.

Это обратная логика, и ею лучше не пользоваться, поскольку в следствии вы получите громоздкий код с солидным числом веток условий.

Приведем пример обратной и прямой логики. Заберём открытие/закрытие по сигналу RSI .

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

  ли он знаком на открытие. Позже, войдя в модуль закрытия ордера, специалист контролирует, есть ли он знаком на закрытие позиции. Другими словами, точки входа как такой нет — имеется независимо трудящиеся модули анализа состояния совокупности (первый принцип проектирования).

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

А в первом варианте нужно будет пересматривать структуру обработки сигнала либо вставлять его отдельной функцией.

Совет: при описании торговой системы вы должны затевать не со слов 1. Приобретаем сигнал. открываем ордер, а сходу разбивать на разделы: а) Условие открытия ордеров, б) Условия сопровождения ордеров и т.д. и в каждом уже разбирать требуемые сигналы.

Для лучшего понимания этого подхода, приведем разные схемы работы в контекстах четырех разных специалистов.

Рисунок 2. Примеры реализации специалистов

а). Специалист, основанный лишь на сигналах какого-либо индикатора. Может открывать и закрывать позиции при смене сигнала. Пример — специалист по МА.

б). Специалист с графическим управлением торговли.

в). Специалист на базе индикаторов, но уже с добавлением трейлинга Stop Loss и временем работы. Пример — скальпинг на новостях с открытием позиции в сторону тренда по индикатору МА.

г). Безиндикаторный специалист, с сглаживанием позиции, контролирующий параметры позиции лишь один раз на открытии нового бара. Пример — усредняющий специалист.

Как видно из схем, каждая торговая система весьма прямой логикой

3. Реализация класса специалиста

Создадим класс по всем выше обрисованным требованиям и правилам, что будет являться базой всех будущих специалистов.

Минимум функциональности, которая должна быть в классе CExpertAdvisor. выглядит следующим образом:

1. Инициализация :

• Регистрация индикаторов;
• Установка начальных значений параметров;
• Настройка на требуемый знак и таймфрейм.

2. Функции получения сигналов

• Разрешенное время работы (торгуемые промежутки);
• Определение сигнала для открытия/закрытия позиций либо ордеров;
• Определение фильтра (тренда, времени и т.д.).
• Запуск, остановка таймера.

3. Сервисные функции

• Вычисление цены открытия, уровни SL и TP, количество ордера;
• Отправка торговых запросов (открытие, закрытие, модификация).

4. Торговые модули

• Обработка сигналов, фильтров;
• Контроль ордеров и позиций;
• Работа в функциях специалиста: OnTrade(), OnTimer(), OnTester(), OnChartEvent().

5. Деинициализация

• Вывод сообщений, отчетов;
• Чистка графика, выгрузка индикаторов.

Все функции класса разбиваются на три группы. Неспециализированная их вложенности описание и схема функций представлены ниже.

Рисунок 3. Схема вложенности функций специалиста

Эта маленькая несколько функций есть базой для работы с типами ордеров, значениями цен и параметрами символа для установки ордеров (стопы и открытие). Эти макросы всецело снабжают второй принцип проектирования – абстрактность. Они трудятся в контексте того знака, на котором трудится сам специалист.

Макросы конвертации типов трудятся с понятием направления рынка – приобретение либо продажа. Исходя из этого, дабы не вводить собственные константы, лучше применять имеющиеся – ORDER_TYPE_BUY и ORDER_TYPE_SELL. Ниже представлены пара примеров применения макросов и результаты их работы.

При разработке специалистов макросы разрешают не конкретизировать обрабатываемое направление и оказывают помощь создавать маленький код.

Эти функции предназначены для работы с позициями и ордерами. Они, как и функции-макросы, также являются низкоуровневыми. Условно их возможно поделить на две категории: функции и информационные функции-исполнители.

Все они делают лишь одно какое-то воздействие, не разбирая никаких событий. Они – исполнители распоряжений от старших обработчиков специалиста.

Примеры информационных функций: определить большую цену открытия текущих отложенных ордеров; выяснить, как закрылась позиция – с профитом либо убытком; взять список и число тикетов ордеров специалиста и т.д.

Примеры аккуратных функций: закрыть указанные ордера; поменять Stop Loss в указанной позиции и т.д.

3. Модули обработки событий

Несколько этих функций есть уже высокоуровневой надстройкой над первыми двумя группами. Как уже говорилось выше – это имеется те готовые блоки, из которых планирует ваш специалист. В неспециализированном-то, как раз они попадают в функции-обработчики событий MQL-программы OnStart(). OnTick(). OnTimer().

OnTrade(). OnChartEvent(). Эта несколько немногочисленна, и содержимое данных модулей может корректироваться от задачи к задаче.

Но принципиально ничего не изменяется.

В модулях все должно быть организовано абстрактно (делаем второй принцип проектирования) чтобы одинаковый модуль возможно было вызывать как для приобретений, так и для продаж. Это достигается, само собой разумеется, при помощи макросов.

Итак, приступим к реализации

1. Инициализация, деинициализация

Это минимальный требуемый комплект параметров для работы функций специалиста.

Два параметра m_smb и m_tf намерено вынесены в особенности специалиста чтобы без ос