Обсуждение статьи "Разрабатываем мультивалютный советник (Часть 4): Отложенные виртуальные ордера и сохранение состояния"
Не использовал бы такую архитектуру.
Представьте, что MQ сделали виртуальную торговлю, встроенную в язык. Тогда Вам не пришла бы идея встраивать в нее другие сущности, потому что это просто не сделать через ООП-наследование - исходники недоступны. Вы бы создали иную архитектуру.
Графические объекты в виртуалке - ну это снова все в одну кучу.
Архитектура стала настолько громоздкой, что вызывает неприятные ощущения. Вместо сбора из простых кирпичиков, вы решили создать универсальные кирпичи.
Мы снова возвращаемся к тому, что реализация не особо нравится, но другие (которые не сделаны, но обдумывались) нравятся еще меньше. Возможно, в процессе дальнейшей разработки получится сделать по-другому, но пока так.
По поводу ситуации с недоступными исходниками: в этой реализации решил как раз воспользоваться тем, что исходники доступны и можно в них добавить что-то, что сразу не было необходимости добавлять. Старался сделать такие добавки минимальными. Альтернативой этому было порождение нескольких новых классов-наследников для семейства классов CVirtual*. Такой подход мне показался ещё более громоздким. Но, вполне возможно, что мы к этому придём, когда классов станет еще больше и хранить их в одной папке станет уже совсем некрасиво.
Графические объекты мне были нужны для контроля при разработке торговых стратегий, поэтому они были реализованы. Причём класс CVirtualOrder при этом вообще не изменялся. А вот добавить четыре новые строки кода в клаcc CVirtualReceiver действительно пришлось. Выбрал именно такой вариант среди разных возможных.
Если необходимости в графическом отображении виртуальных позиций нет, то можно им либо не пользоваться, либо вернуться к варианту библиотеки из предыдущей статьи.
Мы снова возвращаемся к тому, что реализация не особо нравится, но другие (которые не сделаны, но обдумывались) нравятся еще меньше. Возможно, в процессе дальнейшей разработки получится сделать по-другому, но пока так.
У меня, к сожалению, туго со временем, чтобы на примере частичного рефакторинга показать свое виденье.
После первого запуска советник открывает виртуальные и реальные позиции, рассчитывает, может быть, какие-то показатели по ценовым данным. Именно эта информация составляет состояние советника в целом. Если теперь перезагрузить терминал, то советник должен не только распознать открытые позиции как свои, но и восстановить все свои виртуальные позиции и необходимые расчётные значения. Если информацию об открытых позициях можно получить из терминала, то информацию о виртуальных позициях и расчётных значениях советник должен сохранять самостоятельно.
Представьте, что советник работает на двух торговых счетах одного брокера. Один терминал вырубился. За это время в работающем произошло изменение виртуальных позиций. Как сделать, чтобы при запуске упавшего терминала поведение советника совпало с терминалом, что не переставал работать?
Как делаю. Виртуалки не сохраняю совсем. При запуске советника все внутренние ТС запускаются в виртуальном тестере до текущего TimeCurrent. Таким образом получаем, что в перезагружаемом советнике все данные на текущий момент совпадают с версией без перезагрузки.
Под "перезагрузкой" имеется в виду и ситуация, когда происходит пауза в работе советнике. Например, долгий OrderSend или reping. Поэтому нужно запрашивать ценовые данные с момента прошлого запроса. И их прогонять в виртуалке.
У меня, к сожалению, туго со временем, чтобы на примере частичного рефакторинга показать свое виденье.
Вы и так много внимания уделяете рассмотрению чужого кода, за что огромное спасибо.
Представьте, что советник работает на двух торговых счетах одного брокера. Один терминал вырубился. За это время в работающем произошло изменение виртуальных позиций. Как сделать, чтобы при запуске упавшего терминала поведение советника совпало с терминалом, что не переставал работать?
С подобной ситуацией сталкивался, но это было незначительным фактором, оказывающим влияние на торговый результат. К тому же бывало так, что "проспавший" закрытие позиций терминал закрывал их по более выгодной цене. Поэтому обеспечение полной идентичности не было самоцелью.
А если еще и брокеры разные, то тут даже работающие синхронно советники могут показывать несколько отличающиеся результаты из-за небольших расхождений котировок. Хотя к идентичности надо стремиться.
Как делаю. Виртуалки не сохраняю совсем. При запуске советника все внутренние ТС запускаются в виртуальном тестере до текущего TimeCurrent. Таким образом получаем, что в перезагружаемом советнике все данные на текущий момент совпадают с версией без перезагрузки.
Это интересный подход, я такой вариант прежде не рассматривал. Если правильно понимаю, то при его использовании у нас должна быть обязательно задана фиксированная дата начала виртуальной торговли, и она должна быть одинаковой для разных экземпляров советников в разных терминалах. Это несложно. И должен быть реализован виртуальный тестер, либо использован ваш готовый. Это уже сложнее.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Разрабатываем мультивалютный советник (Часть 4): Отложенные виртуальные ордера и сохранение состояния:
Приступив к разработке мультивалютного советника мы уже достигли некоторых результатов и успели провести несколько итераций улучшения кода. Однако наш советник не мог работать с отложенными ордерами и возобновлять работу после перезапуска терминала. Давайте добавим эти возможности.
В прошлой статье мы провели существенную переработку архитектуры кода для построения мультивалютного советника с несколькими параллельно работающими стратегиями. Стараясь добиться простоты и ясности мы пока что рассматривали только некоторый минимальный набор функциональных возможностей. И даже с такой весьма ограниченной постановкой задачи мы довольно сильно изменили код из предшествующих статей.
Теперь есть надежда, что сделанного задела хватит на то, чтобы нарастить функциональность без кардинальных переделок уже написанного кода. Постараемся вносить минимальное количество правок только в тех местах, где без этого никак не обойтись.
В качестве дальнейшего развития в рамках данной статьи мы попробуем сделать следующее:
Начнём с самого простого — работы с виртуальными отложенными ордерами.
Автор: Yuriy Bykov