Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
За то на MQL4 нельзя программировать с ООП, поэтому он все еще популярней.
Я уже показывал свой код, и покажу еще раз:
Это интерфейс торгового процессора - он совершенно одинаков, как для МТ4, так и для МТ5.
Пользователь просто получает этот интерфейс - и у него все возможности для торговых действий. Ему совершенно не надо даже знать, где он находится - на МТ4 или МТ5. Нужно совершить покупку - вызываете функцияю Buy. которая вам заполнит тикет открытой торговой компоненты (для МТ4 - это ордер, для МТ5 - позиция), и вернет код возврата торгового сервера.
Вам даже не надо задумываться над разностью протоколов МТ4 и МТ5 - интерфейс предоставляет всё необходимое.
Все это - возможности ООП.
Я уже показывал свой код, и покажу еще раз:
Это интерфейс торгового процессора - он совершенно одинаков, как для МТ4, так и для МТ5.
Пользователь просто получает этот интерфейс - и у него все возможности для торговых действий. Ему совершенно не надо даже знать, где он находится - на МТ4 или МТ5.
И все это - благодаря ООП.
А примеры использования есть для типичных случаев?
Если бы было по вашей теории, что MQL4=MQL5, то тогда MQL4 можно было запускать на МТ5 и наоборот.
А примеры использования есть для типичных случаев?
Ну, допустим, вот моя функция, отправляющая запрос изменения ТП-СЛ на торговый процессор:
Сперва объекты-части эксперта - формируют запросы на торговые действия (вот, один из таких запросов - на изменение ТП-СЛ). После этого у всех запросов вызывается функция ProceedRequestInto() чтобы отправить информацию о торговом действии в торговый процессор.
Сам торговый процессор представляет из себя объект следующего класса:
То есть, в зависимости от платформы - класс CTradeProcessor наследуется либо от класса CMT5TradeProcessor, либо от класса CMT4TradeProceccor.
Все это, конечно, можно сделать и без ООП - с помощью переключателей да ifdef'ов. Но, на мой взгляд, ООП-подход - куда более удобный и ясный. А главное - позволяющий изолировать сущности друг от друга, и избавляться от массы глобальных переменных.
Кстати, еще один "отголосок ООП" - как раз в дополнительных функциях работы с отложками. Торговый процессор - работает с тикетами отложек, что неудобно - обращение к тикетам в МТ4 и МТ5 разное. Поэтому есть общий класс COrderInfoCore - наследник интерфейса ордера. В процессор гораздо удобнее передавать просто указатель на этот объект. Соответственно, таки образом - мы обходим платформозависиые места.
Ну, допустим, вот моя функция, отправляющая запрос изменения ТП-СЛ на торговый процессор:
Сперва объекты-части эксперта - формируют запросы на торговые действия (вот, один из таких запросов - на изменение ТП-СЛ). После этого у всех запросов вызывается функция ProceedRequestInto() чтобы отправить информацию о торговом действии в торговый процессор.
Мой код совершенно без изменений запускается на МТ4 и на МТ5.
А зачем запускать в разных терминалах?
Мне кажется слишком замудрено, чтобы понять что там делается внутри на самом деле... А без понимания сути работы наврядли кто-то воспользуется... Не проще ли написать отдельную версию для МТ5 и подцеплять ее когда надо?
George Merts:
Но, на мой взгляд, ООП-подход - куда более удобный и ясный. А главное - позволяющий изолировать сущности друг от друга, и избавляться от массы глобальных переменных.
В этом то и смысл, что изолировав все от всего, разобраться с таким кодом будет во много раз сложнее, не говоря уже о невозможности адекватной отладки кода когда нужно знать текущие значения всех необходимых переменных...
А зачем запускать в разных терминалах?
А затем, что у меня основной счет открыт на МТ4, а тестер стратегий на МТ5 куда лучше.
Да и во Фрилансе, по слухам, очень частое требование заказчиков - "чтобы работало и на МТ4 и на МТ5" - значит, это неспроста. Сам я во Фрилансе не вижу смысла работать, но можно спросить у тех, кто там работает, зачем заказчики требуют кроссплатформенность.
А зачем "понимать, что там делается внутри на самом деле" ? Есть фиксированный интерфейс, который выполняет действие, независимо от платформы - его и используем. А что там, на низком уровне - какая разница ?