Используете ли Вы ООП по максимому или избегаете его ? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вопрос к аудитории. А почему Стандартная библиотека написана на ООП? ;-)
Вопрос к аудитории. А почему Стандартная библиотека написана на ООП? ;-)
Надо было написать в виде набора функций?))) У меня вопрос другой, почему вся библиотека MQL5 не написана в виде ООП изначально?
Помню, Нокия в Симбиане с самой первой версии в начале 2000-х сделала SDK на С++ и в виде набора классов, причем, довольно хорошо спроектированных.
В то время даже могучая MS только-только начинала ваять свой .NET и все работали, в основном, с win32 api в виде несвязанного набора функций
Надо было написать в виде набора функций?))) У меня вопрос другой, почему вся библиотека MQL5 не написана в виде ООП изначально?
Хороший вопрос. :)
Хотя ответ уже озвучен чуть выше -"патамушто".
Тут прозвучало мнение о трудности освоения ООП, сделал голосование, близкое к теме, поучавствуте плз )
https://www.mql5.com/ru/forum/79349#comment_2389300
Хороший вопрос. :)
Хотя ответ уже озвучен чуть выше -"патамушто".
Я думаю, патамушта не хотели отталкивать MQL4 - программистов, которые в тот момент в массе в ООП были ни в зуб ногой ))
Допустим так. Теперь, исходя из этого, представим себе массовый уровень советников, который лабался на MQL4. Далее, в MQL5 ООП тоже не назовешь современным. Где-то на уровне Паскаль 6.0, даже ниже.
Рассуждая логически :) мы придем к оч интересным выводам.
В MQL5 всё, что необходимо, можно сделать с использованием только процедурного программирования без ООП.
Предпочитаю видеть код в той последовательности, в которой его исполняет процессор.
Риск ошибок при этом минимален, а скорость работы максимальна.
Считаю ООП своеобразной религией оформления программных решений. Эффективность этой религии для меня сомнительна.
В MQL5 всё что необходимо можно сделать с использованием только процедурного программирования без ООП.
Предпочитаю видеть код в той последовательности, в которой его исполняет процессор.
Риск ошибок при этом минимален, а скорость работы максимальна.
Считаю ООП своеобразной религией оформления программных решений. Эффективность этой религии для меня сомнительна.
А почему вы решили, что ваш процедурный код будет исполняться иммено так, как он написан??? Сначала его изменит оптимизирующий компилятор, это раз. Потом, уже на уровне машинных инструкций, его во время исполнения прооптимизирует любой современный процессор, может инструкции местами переставить, какие-то выполнить параллельно даже на одном ядре (да-да, у процов на одном ядре несколько блоков АЛУ для целочисл. вычислений и поменьше для вещественных). Так что такие рассуждения на уровне ЭВМ 60-х годов.
К сожалению, у компиляторов МТ4/5 нет опции посмотреть генерируемый ассемблерный код. Но я копался в ассемблере, который генерит Intel C++ на высшем уровне оптимизации. Поверьте, если бы не комментарии, которые вставляет компилятор, я бы свой код вообще не узнал ))
Конечно, у MQ должно быть не так круто, но все же.
А, забыл, на МТ ведь все это крутится внутри среды исполнения, которая для нас вообще черный ящик.
В MQL5 всё что необходимо можно сделать с использованием только процедурного программирования без ООП.
Предпочитаю видеть код в той последовательности, в которой его исполняет процессор.
Риск ошибок при этом минимален, а скорость работы максимальна.
Считаю ООП своеобразной религией оформления программных решений. Эффективность этой религии для меня сомнительна.
Кроме ООП существует еще одна фишка под названием "Структурное программирование", знаменитое goto.
По моим представлениям разговоры про ту и другую фишку ведут люди никогда не участвовавшие в разработке больших программ трудоемкостью 100 и выше человеко/лет.
Для организации работы коллективов от 30 до нескольких сотен человек, разрабатывающих ровно один программный объект, и ООП и структурное программирование вещи третьестепенные, не способные оказать серьезное влияние на скорость разработки, а главное на качество программного продукта.
В основе качества разработки больших программ лежит тщательное, предварительное проектирование этих программ, при этом проектная документация должна включать необходимые сведения по отладке этих программ. Трудоемкость написания собственно коде в больших программах составляет примерно 10%, а ООП относится именно к этим 10% и ничего не говорит про остальные 90% трудоемкости разработки.
ПС.
Для сравнения процедурного подхода и объектного.
В R понятие "объект" доведено до своего логического завершения - объектом может быть все, что только может быть. Тем не менее основной содержательный состав R - это пакеты, которые состоят из функций.