Учебник по MQL5 - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Обьясните в чем большая сложность ООП? Покажите пример, когда реализация функциональщиной сложнее ООП. ООП не обязывает вас применять все его приемущества там, где они не нужны. Создание класса и инициализация обьекта требуют меньшего понимания, чем создание функций и глобальных переменных, потому что в глобальных переменных в десятки раз проще запутаться чем в классе. Даже там, где требуется всего один обьект класса - вы получаете все те же приемущества в виде хранения всех переменных в одном месте (вместо глобальных переменных) и функций, которые вы можете именовать как угодно не боясь что они войдут в коллизию с такими же функциями в другом файле. Например, в разных классах я могу использовать функцию get_volume(), которая в одном классе вернет объем позиции, в другом вернет дневной объем торгов в секции, а в третьем классе вернет объем собственных торгов за день. В функциональщине же у вас будут get_position_volume(), get_self_trade_volume(), get_market_trade_volume(). А если вы заранее об этом не подумали и сделали просто get_trade_volume(), или вообще в одном месте сделали функцию double get_trade_volume(), забыли об этом и в другом месте сдлали bool get_trade_volume(double& volume) - то получите вполне себе компилируемый код, в котором функция будет возвращать не то что вы задумали, а абсолютно левые данные.
Похоже, это тот случай, когда программист не понял приемуществ и простоты ООП и вместо того, что бы еще раз перечитать и разобраться - просто откатился на ступень назад. Типа "так работает, пусть криво, за то учить не надо.
Мне сложно переходить от процедурного и функционального к ООП. Вернее даже не так. Приходится сперва правильно понять задачу, решить ее в процедурном или функциональном варианте и только потом декомпозицией заняться и что то в классы убрать. А так, Даже просто синтаксис не привычен.))) Создание описания объекта и его инициализация к сожалению не так явны для понимания, без обид, и для тех у кого первый язык бейсик не привычно. Помню в году 2003 мне парень писал на пхп сайт. На вопрос что такое ООП, он мне объяснить не смог. Ну инкапсуляция, наследование, ты не понимаешь что ли)))) Когда в теме долго, конечно набор однотипных задач, проблема / порядок наименования переменных как то определяется и само собой убрать в классы эти задачи нормально, и пользоваться ими для решения следующих задач, но это как минимум нужно быть в теме достаточно долго.))) Конечно у ООП подхода преимущества перед процедурным и функциональным подходом, но только если правильно сделана декомпозиция задач.))) А правильный алгоритм решения и рациональная разбивка на подзадачи, тоже требует навыка.
Хороший пример хорошего на мой взгляд ООП подхода
Можно про функциональный подход в mql5 поподробнее? Неужто у нас уже появились лямбда-функции, например?)
Хех, фразеологизмы, функциональщина)))) нет конечно лямбд ....))) Хорошая кстати книжка (в блаблакосе), легче идет чем остальные.)))
Что будет победителю? Потратить пару дней впустую что бы доказать тем, кого я не знаю, что ООП подход лучше функционального?
Мне сложно переходить от процедурного и функционального к ООП. Вернее даже не так. Приходится сперва правильно понять задачу, решить ее в процедурном или функциональном варианте и только потом декомпозицией заняться и что то в классы убрать. А так, Даже просто синтаксис не привычен.))) Создание описания объекта и его инициализация к сожалению не так явны для понимания, без обид, и для тех у кого первый язык бейсик не привычно. Помню в году 2003 мне парень писал на пхп сайт. На вопрос что такое ООП, он мне объяснить не смог. Ну инкапсуляция, наследование, ты не понимаешь что ли)))) Когда в теме долго, конечно набор однотипных задач, проблема / порядок наименования переменных как то определяется и само собой убрать в классы эти задачи нормально, и пользоваться ими для решения следующих задач, но это как минимум нужно быть в теме достаточно долго.))) Конечно у ООП подхода преимущества перед процедурным и функциональным подходом, но только если правильно сделана декомпозиция задач.))) А правильный алгоритм решения и рациональная разбивка на подзадачи, тоже требует навыка.
Хороший пример хорошего на мой взгляд ООП подхода
В вашем случае, в ООП нет смысла. Вы растите курицу, потом прогоняете ее через мясорубку что бы затолкать обратно в яйцо. Задача хорошего программиста вначале спроектировать и структурировать, потом с первого раза все написать. В ООП вы можете спроектировать и далее написать весь код классами без реализации, а после того, как структура написана - дописать реализацию.
В вашем случае, в ООП нет смысла. Вы растите курицу, потом прогоняете ее через мясорубку что бы затолкать обратно в яйцо. Задача хорошего программиста вначале спроектировать и структурировать, потом с первого раза все написать. В ООП вы можете спроектировать и далее написать весь код классами без реализации, а после того, как структура написана - дописать реализацию.
true ? do this : else do this
ifTlowFST[j] что это за операция? справа есть присвоения значения false
а слева что происходит?
переменная x = (если выражение правдиво) ? этому значению : в противном случае этому значению
(drSYM<2)? ifTlowFST[j] : ifTHighFST[j] = false;
Вот это тут не логично, красным что.
Если это было не присвоение, то непонятно чего вы хотели добиться этим: ifTlowFST[j]
А если присвоение, то чего вы хотели добиться этим ifTHighFST[j] = false.