Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Краткий ответ - с применением ООП существенно повышается удобство повторного использования кода и его последующая поддержка.
Золотые слова! Добавлю, сильно уменьшается время последующих разработок. Например, у меня в личной библиотеке есть класс COrderManager, который умеет работать с пулом ордеров, строить сетки отложенников, двигать сетки вверх-вниз по цене, растягивать и сжимать их и т.д. Если представить, что я все это делал бы на процедурном... бр-р-р-р))
ЗЫ: как вспомню "старый" MQL4, в котором даже структур не было, так вздрогну ))
Ну насколько я понял Ваш класс COrderManager и есть ни что иное как "контейнер функций"...... Ведь пока он у Вас "лежит" в библиотеке - он просто код. А как понадобится - набор функций (в ООП - методов)....
Поля данных тоже есть. Смысл в том, чтобы считать все ордера и потом уже проводить анализ. У меня обычно открыты десятки ордеров по разным парам, так что это быстрее, чем постоянно крутить циклы с OrderSelect. Есть и другие классы, например по обработке тиков, там вообще много полей данных. Если бы был просто набор функций, от класса не было бы особого преимущества.
Поля данных тоже есть. Смысл в том, чтобы считать все ордера и потом уже проводить анализ. У меня обычно открыты десятки ордеров по разным парам, так что это быстрее, чем постоянно крутить циклы с OrderSelect. Есть и другие классы, например по обработке тиков, там вообще много полей данных. Если бы был просто набор функций, от класса не было бы особого преимущества.
Здесь проблема в том, что создается вторая сущность: некая копия реальных ордеров в МТ и не факт, что она будет совпадать с фактической ситуацией. Например ордер отмениться, а в копии он будет продолжать существовать.
Может быть COrderManager и быстрее, но вот обычный перебор OrderSelect гораздо надежнее.
Из за того что ООП так расхваливают разработчики МТ , многие ждут невероятных чудес от этого метода. Соглашусь с некоторыми ООП упорядочивает мысли, позволяет собрать массу полезного и систематизированного кода, предотвратить глупые ошибки, и это только самый минимум..
Может быть COrderManager и быстрее
Не может, бо работа с объектами по определению требует больше ресурсов
с применением ООП существенно повышается удобство повторного использования кода
Что мешает повторно использовать набор функций? Объём неиспользуемого кода и отжираемые ресурсы сократятся в разы
---
На моё имхо ООП оправдан только там, где есть масштабирование структур, т.е. где наследование свойств/методов действительно востребовано и работает. Это меньше 1% работ во фриланс-сервисе
НО! Мне нравяцца наборы структур где всё красиво расфасовано и логически упорядоченно - в таком коде легко читается что к чему относится в общей структуре программы. Поэтому использую :)
Что мешает повторно использовать набор функций? Объём неиспользуемого кода и отжираемые ресурсы сократятся в разы
Я говорил про удобство повторного использования. При ООП между методами и данными - организована связь, которая (при правильном проектировании класса) сразу предотвращает большое количество ошибок.
Ресурсы - да, согласен, при ООП их нужно больше.
Alexander Puzanov:
НО! Мне нравяцца наборы структур где всё красиво расфасовано и логически упорядоченно - в таком коде легко читается что к чему относится в общей структуре программы. Поэтому использую :)
Что мешает повторно использовать набор функций? Объём неиспользуемого кода и отжираемые ресурсы сократятся в разы
...
То, что функции связаны с данными и другими функциями. Т.е. как правило не покатит скопипастить какую-нибудь функцию в свой mqh файл. Сразу пойдут какие-либо предупреждения компилятора о том, что функции не хватает такой-то функции и таких-то переменных.
Включая класс дерективой #include мы точно знаем, что все связи учтены и содержимое инклудника закомпилится без ошибок.
То, что функции связаны с данными и другими функциями. Т.е. как правило не покатит скопипастить какую-нибудь функцию в свой mqh файл. Сразу пойдут какие-либо предупреждения компилятора о том, что функции не хватает такой-то функции и таких-то переменных.
В этом писатель функций виноват а не компилятор - передавайте им данные в явном виде, правильно используйте область видимости переменных. Разве при написании классов вы элементарных правил не соблюдаете?
Я говорил про удобство повторного использования