Вопросы по ООП в MQL5 - страница 27
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Какие конкретно высказывания безосновательны?
там хватает.
статья вбросовая, рассчитанная на подгорание со стороны ООПшников и никак не касающаяся mql потому что для ФП в mql просто нету средств языка.
поэтому смысла ее здесь обсуждать нет никакого.
там хватает.
статья вбросовая, рассчитанная на подгорание со стороны ООПшников и никак не касающаяся mql потому что для ФП в mql просто нету средств языка.
поэтому смысла ее здесь обсуждать нет никакого.
там хватает.
статья вбросовая, рассчитанная на подгорание со стороны ООПшников и никак не касающаяся mql потому что для ФП в mql просто нету средств языка.
поэтому смысла ее здесь обсуждать нет никакого.
Комментарии излишни.
Сторонники ФП осознанно забывают, что их лямбда-исчисление исполняет машина Тюринга, с конечным числом состояний и переходами между ними, т.е. используются те же счетчики, ветвления и инструкции goto. Так что утверждать что ФП предоставляет нечто большее, чем может предоставить классический язык вроде C, C#, Java как минимум некорректно.
Василий, вот эта статья вам была бы очень полезна - что бы не мучить себя, выжимая их себя ООП ради ООП.
Василий, вот эта статья вам была бы очень полезна - что бы не мучить себя, выжимая их себя ООП ради ООП.
почему так не лестно? мне стиль изложения его статей очень нравится,
да и чистота кода и читаемость - себе бы точно пожелал бы - уровень очень высок
почему так не лестно? мне стиль изложения его статей очень нравится,
да и чистота кода и читаемость - себе бы точно пожелал бы - уровень очень высок
К сожалению не могу поддержать этот разговор - не читал ни статьи не видел кода. Это было о другом.
К сожалению не могу поддержать этот разговор - не читал ни статьи не видел кода. Это было о другом.
ну могу лишь сказать свое мнение об ООП для чистоты понимания целесообразности ООП в MQL, закончил код - было интересно посмотреть что в итоге выйдет, изначально было как привык писать - отлаженные сервисные функции работы с ордерами и вставки ООП где хранил данные и небольшие методы которые только в данной задаче планировал использовать, из классов вызывал функции работы с ордерами (процедурный стиль)
теперь обернул все функции работы с ордерами в класс, потом причесывая код убрал параметры в функциях, ибо поля класса приватные - нет смысла.... итог по моему плачевный - получил абсолютно не переносимый код для дальнейшего использования
да удобно, что можно добавлять небольшие методы и расширять функциональность класса, но для последующего использования ... или дописывать новые методы, зная что компилятор не используемый код не включит в экзешник, или... писать заново опять - в общем монстр некий получился класс работы с ордерами
посмотрел СБ, там в принципе та же ситуация, т.е плата за универсальность - это раздутый код, который не сможешь прочитать спустя пару месяцев и будешь наследоваться чтобы не разбираться что лишнее в классе - время жалко
читать то в принципе можно, названия методов по выполняемым задачам... в общем я не доволен результатом громоздко все
ну могу лишь сказать свое мнение об ООП для чистоты понимания целесообразности ООП в MQL, закончил код - было интересно посмотреть что в итоге выйдет, изначально было как привык писать - отлаженные сервисные функции работы с ордерами и вставки ООП где хранил данные и небольшие методы которые только в данной задаче планировал использовать, из классов вызывал функции работы с ордерами (процедурный стиль)
теперь обернул все функции работы с ордерами в класс, потом причесывая код убрал параметры в функциях, ибо поля класса приватные - нет смысла.... итог по моему плачевный - получил абсолютно не переносимый код для дальнейшего использования
да удобно, что можно добавлять небольшие методы и расширять функциональность класса, но для последующего использования ... или дописывать новые методы, зная что компилятор не используемый код не включит в экзешник, или... писать заново опять - в общем монстр некий получился класс работы с ордерами
посмотрел СБ, там в принципе та же ситуация, т.е плата за универсальность - это раздутый код, который не сможешь прочитать спустя пару месяцев и будешь наследоваться чтобы не разбираться что лишнее в классе - время жалко
читать то в принципе можно, названия методов по выполняемым задачам... в общем я не доволен результатом громоздко все
Короче - нагадил и свалил.
Короче - нагадил и свалил.
хм, кто свалил? Вы о чем? ладно... у Вас все комменты среди ночи сложно понять что к чему
...
А если не использовать классы, то замучаешься от постоянного написания чего-нибудь типа SymbolInfoDouble(_Symbol,SYMBOL_BID). Такое вытанцовывание каждый раз - и скобки и подчеркивание и не знаешь, нажимать ли капслок (а потом где-то в другом месте не глядя набрать целую строку заглавными буквами и перепечатывать ее) или держать шифт прижатый. Хотя бы в этом ООП полезен. Если, как минимум, сделать классы для всех этих функция, то да - они громадные. Если для себя писать, то не проблема. По работе с ордерами - часто используемых функция не так уж много, можно просто несколько функций в библиотеку сложить. Но в общем, пока никак не складывается идеальный подход.