Оверхед для ООП - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Моя практика показывает, что, таки, нужен.
Я лет пять назад шел этим путем, тогда еще на МТ4. (Не потому, что не знал про ООП, просто мне лень было заморачиваться с интерфейсами и наследованием, тем более, что в то время МТ4 и МТ5 существенно различались в плане реализации MQL). Это меня привело к пониманию его ошибочности. Это не "замудренности", а вполне разумное ограничение, своего рода "защита против дурака". Если вы всегда помните, за что отвечает каждая из сотни переменных - вам инкапсуляция не нужна. Я этого не помню, и предпочитаю, чтобы в каждом блоке программы доступ имелся к как можно меньшему числу сущностей.
Как только на МТ4 появилось ООП - я все мои наработки тут же стал переводить к единой форме, на основе интерфейсов.
Мне так и не удалось придумать что-то удобнее MQL4-ордерной системы. Если есть пример, прошу показать.
Все торговые API, что видел, выглядят чудовищно, по сравнению с MQL4. И к тому же еще и неповоротливы.
Мне так и не удалось придумать что-то удобнее MQL4-ордерной системы. Если есть пример, прошу показать.
Все торговые API, что видел, выглядят чудовищно, по сравнению с MQL4. И к тому же еще и неповоротливы.
Чего хорошего, каждый параметр надо отдельной функцией тягать. Было бы логично как с тиками, получать по запросу структуру со всеми параметрами.
Мне так и не удалось придумать что-то удобнее MQL4-ордерной системы. Если есть пример, прошу показать.
Все торговые API, что видел, выглядят чудовищно, по сравнению с MQL4. И к тому же еще и неповоротливы.
В смысле ?
Сама суть сделок-ордеров ? Да, согласен, весьма удобно.
Но, как раз применение ООП к этой системе - на мой взгляд, и дает наибольший "выигрыш". Скажем, у меня один и тот же интерфейс - дает как МТ4-позицию, состоящую из ордеров, так и МТ5-позицию, состоящую из МТ5 позиций, причем, независимо от того, хеджевые или неттинговые условия работы.
На мой взгляд, гораздо логичнее и понятнее, когда у нас имеется список объектов-ордеров (или MT5-позиций), получаемых по функции Select() и мы обращаемся к свойствам ордеров, а не "состояние окружения" (получаемое по этой же функции), к которому мы обращаемся через функции.
Самое интересное будет, если нам надо отслеживать сразу несколько ордеров - тут процедурный подход неминуемо приведет к "псевдообъектному" - придется создать массив информации по ордерам, которую при входе в OnTick() обновлять, и работать с данными ордеров по индексам в массиве, точно так же, как с ООП-указателями на объекты-ордера.
Кроме того - ООП-подход даст выигрыш и при работе одновременно с историческими и действующими ордерами - поскольку интерфейс исторического ордера - является наследником ордера действующего. Большинство функций получаются общими. А при процедурном подходе - обращение к историческим и действующим ордерам производится разными функциями, что гораздо менее удобно.
Чего хорошего, каждый параметр надо отдельной функцией тягать. Было бы логично как с тиками, получать по запросу структуру со всеми параметрами.
Записи Order.TakeProfit и OrderTakeProfit() - одно и то же. Первая обладает только возможностью хранения объекта, а вторая - актуальностью. Надобность в хранении встречал очень редко и не в ТС. И там структуру создать - нет проблем.
Сам задумывался, почему разработчики не сделали возврат ордера структурой, а оставили каждое поле в отдельности через функцию (для истории еще и тикет каждый раз требуется).
В общем, реально нехорошего в MQL4-API (может работать не только в MT4/5) не вижу.
В смысле ?
Сама суть сделок-ордеров ? Да, согласен, весьма удобно.
Но, как раз применение ООП к этой системе - на мой взгляд, и дает наибольший "выигрыш". Скажем, у меня один и тот же интерфейс - дает как МТ4-позицию, состоящую из ордеров, так и МТ5-позицию, состоящую из МТ5 позиций, причем, независимо от того, хеджевые или неттинговые условия работы.
У Вас своя обертка, у другого - своя. Вопрос был в другом, можно ли создать обертку удобнее, чем MQL4?
На мой взгляд, гораздо логичнее и понятнее, когда у нас имеется список объектов-ордеров (или MT5-позиций), получаемых по функции Select() и мы обращаемся к свойствам ордеров, а не "состояние окружения" (получаемое по этой же функции), к которому мы обращаемся через функции.
Самое интересное будет, если нам надо отслеживать сразу несколько ордеров - тут процедурный подход неминуемо приведет к "псевдообъектному" - придется создать массив информации по ордерам, которую при входе в OnTick() обновлять, и работать с данными ордеров по индексам в массиве, точно так же, как с ООП-указателями на объекты-ордера.
Об этом в пред. посте написал.
Кроме того - ООП-подход даст выигрыш и при работе одновременно с историческими и действующими ордерами - поскольку интерфейс исторического ордера - является наследником ордера действующего. Большинство функций получаются общими. А при процедурном подходе - обращение к историческим и действующим ордерам производится разными функциями, что гораздо менее удобно.
Ну так в MQL4 с историей идет работа через одни и те же функции (OrdersHistoryTotal - не считается).
Хорошо бы пример кода, где свой торговый API явно лучше MQL4-API. Сам ООП использую почти всюду. И для решения каких-то конкретных задач делаю некоторые торговые обертки. Но они не являются универсальными, хоть для конкретной задачи использовать их ну очень удобно. Однако, все же хочется сранивать универсальные торговые API.
Сам задумывался, почему разработчики не сделали возврат ордера структурой, а оставили каждое поле в отдельности через функцию (для истории еще и тикет каждый раз требуется).
Alexey Volchanskiy:
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
В MT5 были структуры, но возврат через функции все равно.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Оверхед для ООП
fxsaber, 2017.07.07 08:08
Вопрос был в другом, можно ли создать обертку удобнее, чем MQL4?
В MT5 были структуры, но возврат через функции все равно.
наверное, решили не нарушать традиции, хотя зря
я еще понимаю, если бы данные с сервера ДЦ качались, но ведь они локальные, берутся мгновенно, можно было бы сразу заполнить структуру
наверное, решили не нарушать традиции, хотя зря
я еще понимаю, если бы данные с сервера ДЦ качались, но ведь они локальные, берутся мгновенно, можно было бы сразу заполнить структуру
Да, при SELECT внутри идет именно заполнение одного экземпляра скрытой стуктуры, до полей которой достучаться возможно только через const(read-only)-функции.
Наверное, это единственное спорное решение ядра торгового API. В остальном даже не знаю, к чем возможно придраться.
Да, при SELECT внутри идет именно заполнение одного экземпляра скрытой стуктуры, до полей которой достучаться возможно только через const(read-only)-функции.