![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вот спасибо за такой ответ. Самый точный и исчерпывающий, характеризующий принцип использования для программиста :)
))
Если серьёзно, то в правильном направлении мыслите.
Даже используя достаточно простое процедурное программирование без ООП, и разбивая код на функции по отдельным mqh-файлам, можно очень упростить следующую разработку. Можно потом хоть каждый день новые советники делать.
Я так примерно и сделал несколько лет назад, будучи в то время совсем ещё далёким от программирования. За пару месяцев написал универсальный шаблон советника из набора mq4 (главный файл советника) + несколько mqh (около 15 функций, на все случаи жизни, как тогда мне казалось). Для каждого нового советника (и проверки новой идеи) править нужно было обычно 2 файла mqh: файл с входными параметрами и файл с критериями входа, иногда ещё файл с критериями выхода.
Сейчас уже много чего переосмысливаю конечно, но тот шаблон и сейчас прекрасно работает, хоть и устарел.
В общем, если будете работать с одним программистом или самостоятельно программировать, то облегчит работу и ему и Вам. Другому программисту (исполнителю) скорее всего будет проще использовать свои наработки и шаблоны, чем разбираться с чужими, т.е. возможно усложнит.
Надеюсь, что не запутал совсем ))
Подход реальный, я использую разные классы: торговые, для работы с файлами, ММ, сложный расчет индикатора.
Однако, если Вы пока только начинаете заниматься программированием (а им придется заняться, если хотите что б советник зарабатывал, то как минимум нужно проверять качественно выполненную работу фрилансера), то я бы рекомендовал для сигналов использовать индикаторы и именно их заказывать так-как с помощью них можно будет видеть всю логику, а не просто голый код, в котором может быть много ошибок. Или заказывать функцию, которую можно будет перенести в советник, но что б она графически отрабатывала на графике через индикатор.
Только так, видя что происходит внутри кода, можно не будучи программистом выполнить проверку работы.
Кстати, подключить/заменить индикатор очень просто.
В общем случае не облегчит и не усложнит, работы для другого исполнителя не убавится (для одного тоже).
Представьте, что в файле *.mq4 вместо строки, где написано "#include <*.mqh>" просто будет весь текст из того файла *.mqh.
Вот и вся разница между одним файлом mq4 и набором файлов mq4 + mqh, в общем то.
Так писать реально , но придется учитывать много нюансов, из за последовательности инклюдов, нахождении различных глобальных переменных или input переменных , вдруг они будут нужны в нескольких файлах. Нашел недавно одну статью про несколько другую модульность, тож будет полезна. https://www.mql5.com/ru/articles/3133
Один вариант
Второй вариант
В обоих вариантах, можно в пределах класса изменять переменные, что иногда довольно удобно. Конечно можно и напрямую получать значения input в функциях классов, но не всегда удобно в работе.
По поводу работы с разными программистами. Есть у меня советник, который писал один человек, а дорабатывали несколько других. Берутся, разбираются. Так что я думаю это небольшая проблема. Тем более до заключения соглашения о работе, в обсуждении, я сразу выкладываю претенденту все файлы что есть, что бы он оценил свои силы и написал точную сумму, сроки по итогам.
Зависит от сложности кода.
Предложи им разобраться в коде fxsaber'a - уверен, они даже за деньги не согласятся, а ведь fxsaber пишет очень даже интересный и нужный код (одна библиотека совместимости чего стоит).
В моей библиотеке, я уверен, мало кто захочет разбираться, хотя ее использование, думаю, большинству бы тоже понравилось.
В данном случае - задачи существенно различны - добавить некоторые возможности в советник, написанный другим человеком, и дорабатывать целую систему программных модулей. Использовать-то такую библиотеку - вполне приемлемо (когда она уже написана, и отлажена). А вот вносить в нее изменения - на это пойдет далеко не любой.
Подход реальный, я использую разные классы: торговые, для работы с файлами, ММ, сложный расчет индикатора.
Однако, если Вы пока только начинаете заниматься программированием (а им придется заняться, если хотите что б советник зарабатывал, то как минимум нужно проверять качественно выполненную работу фрилансера), то я бы рекомендовал для сигналов использовать индикаторы и именно их заказывать так-как с помощью них можно будет видеть всю логику, а не просто голый код, в котором может быть много ошибок. Или заказывать функцию, которую можно будет перенести в советник, но что б она графически отрабатывала на графике через индикатор.
Только так, видя что происходит внутри кода, можно не будучи программистом выполнить проверку работы.
Кстати, подключить/заменить индикатор очень просто.
По поводу проверки работы Ваши идеи мне нравятся. Я планировал с каждым таким файлом заказывать простенького советника для проверки всех функций. А вообще, пока мне это представляется так: есть модуль советника/стратегии, он выдаёт только сигнал (этот модуль меняется), а уже mqh файл, который как бы включается от сигнала, открывает ордер и сопровождает его (никаких закрытий по сигналам индикатора). Т. е. больше к ордеру модуль стратегии отношения не имеет. Не знаю, делать один файл для ордеров buy, sell или два, свой для buy, свой для sell. Как мне кажется это упростит работу по открытию разнонаправленных ордеров, упростит ссылание на файл и разборку какого направления открывать ордер. Пока формулирую, думаю. Всем спасибо за ответы/советы.