Структура рулит. Учимся структурировать программы, изучаем возможности, ошибки, решения и т.п. - страница 9
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не подумайте, что умничаю, но еще раз посмотрите на эту архитектуру написания боевой ТС. Там нет обратной связи.
Есть виртуальные позиции и есть реальное торговое окружение, которое подгоняется под виртуальность.
В таком случае даже плевать, неттинг в платформе или другая система учета.
По моему, весьма интересная структура, особенно для скорострельных стратегий, которые не проверить на штатном тестере.
Только, не совсем ясно, по поводу "грамотного синхронизатора". Вероятно имеется ввиду какой то адаптивный копировщик торговых приказов, задача которого, если я правильно понимаю, согласование виртуальной прибыльности\убыточности стратегии и текущего состояния рынка - ликвидности, скорости исполнения и.т.д...
А вообще то хорошо иметь такой тестер и синхронизатор не монолитно вмонтированными в советника, а как отдельный, внешний модуль.
В таком случае к нему можно было бы подключать любой советник или несколько одновременно и даже избирательно использовать, наиболее подходящие сигналы.
Интересно, реально ли такое сделать, используя только MQL...
Так это и есть отдельный по логике модуль.
Вон, например, сервис Сигналы - это отдельный такой модуль, никак не связанный с ТС:
он просто виртуальные позиции источника (они для вас виртуальные) переводит в ваше торговое окружение.
Криво (не оптимально) , конечно, но переводит.
Так это и есть отдельный по логике модуль.
Вон, например, сервис Сигналы - это отдельный такой модуль, никак не связанный с ТС:
он просто виртуальные позиции источника (они для вас виртуальные) переводит в ваше торговое окружение.
Криво (не оптимально) , конечно, но переводит.
Выходит типа - есть гугл переводчик, который криво переводит, но пойдет если понимание не обязательно, а если точное обязательно - учи язык.)
А меня бы устроил промежуточном вариант - персональный, качественный переводчик(модуль), когда и перевод хорош и писать код в каждый советник не надо.
Понимание, как нужно структурировать программу, приходит с опытом. У каждого из здесь присутствующих свой опыт, и, соответственно, порядок и правила структурирования будут уникальными. Более того, правила эти будут меняться со временем - то есть то, что казалось идеальной структурой пару лет назад, сегодня может не выдержать даже самой легкой критики.
Со структурой программ на MQL вообще отдельная песня, так как он по сути своей DSL, управляемый событиями от терминала (хотя сейчас сделаны гигантские шаги по приведению его к языкам общего назначения). Имхо, для описания торговых стратегий лучшим образом подходит стейт-машина, и здесь уже было несколько статей на эту тему. Собственно и структура вырождается в большой case с кучей инклудов по реализации каждого кейса.
Если же абстрагироваться от торговых задач, то я обычно выделяю ядерную (core) часть, которая ничего не знает о конкретике взаимодействия с пользователем. Её цель - предоставить способ заполнить себя данными, решить задачу основываясь на поступивших данных и выдать наружу результат. Ядро физически может состоять из нескольких файлов, но все они должны быть логически увязаны и наружу предоставлять только методы приема данных и методы возврата данных и ничего кроме этого. Простейшая аналогия - мясорубка.
Второе, что я считаю важным - это локализация изменяемых частей (либо частей, которые потенциально могут быть изменены) и выделение их в отдельную абстракцию. При таком подходе мы безболезненно сможем переключаться между различными реализациями механизма (например, переключив механизм открытия позиций можно виртуализовать торговлю). Различные реализации удобно складывать в отдельную папку с обобщенным названием.
При таком подходе структура проекта будет напоминать дерево, у которого от ствола (Core), состоящего из различных связанных подсистем (Subsystems) расходятся ветви изменяемого поведения (Behaviour). А рядом с ним будут находиться бинокль (Reporting, GUI), чтобы посмотреть на это дерево под необходимым углом и топор с бензопилой (Actions, GUI), которые обеспечат нам необходимое взаимодействие с этим деревом.
Простые стейт-машины на службе у разработчика
Простые стейт-машины на службе у разработчика
Приведи хотя бы приблизительный пример применительно к нашим реалиям.
Ну ты даешь :) реализация любой стратегии по сути представляет из себя стейт-машину.
Это понятно. я просил пример такой машины в свете статьи на харабре.
А, ну ок. Была ))) статья где чувак сделал "аналог" стейт машины. И толкал технологию как передовое открытие в области программинга ).
А статьи предметной по стейт-машинам... не припомню здесь.
Приведи хотя бы приблизительный пример применительно к нашим реалиям.
Ахаха, напомнило "какие будут ваши доказательства"(с)
Просто погуглил "стейт-машина" выбрал наиболее понравившийся контент и залил сюда.
Ничего не доказываю, ничего не опровергаю. Интересная статья.
Я вообще против догм, если один пользует это, то не значит что для другого подойдёт.
Но читая чужие коды часто встречаю аналогии со стейт-машинами. Просто наблюдение.