ООП - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
По моему мнению, Вы ошибаетесь очень сильно!
Как только у Вас появятся большие проекты (хотя бы несколько тысяч строк кода), Вы убедитесь, что программирование с классами (ООП) очень сильно облегчает дело и позволяет достаточно легко контролировать процесс разработки и, что особенно важно, отладки.
Кроме того, ООП делает проекты ближе к реальной жизни, ведь в обычной жизни мы имеем дело как-раз с экземплярами объектов (дом, дерево, человек, машина, ордер и т.д.), т.е. с совокупностью свойств и методов :)
Да Вы попробуйте сделать что-либо на ООП, сами увидите, что это более элегантно и понятно. Это легче, чем процедурное программирование!
MoneyJinn:
Используйте в MetaTrader 5 обычное процедурное программирование.
ООП - это развитие процедурного программирования.
Ведь никто не спорит, что можно обойтись и без функций. Ведь так еще быстрее, до определенного момента. Не беда, что есть участки кода которые выполняют одно и тоже действие, с разными данными. Копипаст сделать очень просто.
Повторное использование функций проигрывает ООП. Расширение функционала - это всегда создание новой функции и переделка кода для возможности вызова этой функции в зависимости от различных условий. В правильно написанной ООП программе расширение - простая вещь, не требующая переделки всего кода.
Если при написании программ без ООП у вас не возникло дискомфорта от проблем с масштабированием, обилия лишних данных и сотен функций, случайно перекрытых переменных, необходимости в "горячей" замене функционала, то ООП вам не нужен.
Да, писать на ООП ради ООП не стоит, ничего хорошего не выйдет. Не нужно функции заменять классами. Избегайте антипаттернов
ООП - это ошибка, как "Нива" или "Лада".
Используйте в MetaTrader 5 обычное процедурное программирование.
Оно здесь также доступно как и в MetaTrader 4.
Жаль, что MetaQuotes не делают на этом акцент.
ООП - это развитие процедурного программирования. ...
Если при написании программ без ООП у вас не возникло дискомфорта от проблем с масштабированием, обилия лишних данных и сотен функций, случайно перекрытых переменных, необходимости в "горячей" замене функционала, то ООП вам не нужен.
Да, писать на ООП ради ООП не стоит, ничего хорошего не выйдет. Не нужно функции заменять классами. ...
Согласен на 100%.
Кроме того, ООП делает проекты ближе к реальной жизни, ведь в обычной жизни мы имеем дело как-раз с экземплярами объектов (дом, дерево, человек, машина, ордер и т.д.), т.е. с совокупностью свойств и методов :)
Что ближе к реальности: виртуальные дом, дерево, человек или же видеть программу в той последовательности, в которой она на самом деле выполняется процессором?
Это вопрос религиозный. И у каждого свой выбор.
Мой пост был ответом на вопрос заблокированного топикстартера, который в результате поплатился за свою неприязнь к ООП,
а также ответом для простых трейдеров, которые попытаются освоить такой продукт как MT5 или перейти на MT5 c MT4.
Мой пост был ответом на вопрос заблокированного топикстартера, который в результате поплатился за свою неприязнь к ООП,
Контрольный для топикстартера:
Объектно-ориентированное программирование – это (читаем фразу в обратной последовательности) программирование ориентированное на объекты. Или, программирование основанное на объектах.
Под объектом понимается программный код (обычно изолированный от другого кода), который описывает параметры и поведение реальных объектов (например "машина") или выдуманных (например "грааль пупкина") . Каждый объект может как бы жить своей жизнью и вариться в собственном соку. Для связей с внешним миром используется ограниченный набор "нервных каналов" - типа специальные функции с доступом из вне.
Основное преимущество ООП, на мой взгляд, в том, что код объекта можно отладить независимо от другого кода. А потом собрать, как мозаику, более сложные объекты. Например, объект "женщина" может включать другие объекты: "фюзеляж", "шасси", "баки", "кабину пилотов", и т.д.
Хорошим примером ООП на MQL является Мастер MQL5. Он позволяет собрать советник из уже готовых отлаженных объектов. Причем эти объекты можно комбинировать.
Самый убийственный аргумент в пользу ООП: тот, кто вник в его суть, подсаживается на него. Просто программировать легче, код более понятный и структурированный.
...
Самый убийственный аргумент в пользу ООП: тот, кто вник в его суть, подсаживается на него. Просто программировать легче, код более понятный и структурированный.
Что да то да, пока не освоил ООП мне казалось это такая пурга что даже лезть туда не стоит.
Как только понял, всё как рукой сняло, не нужно больше выдумывать уникальные имена переменным,
счётчик первой вложенности i, счётчик второй вложенности j, размер массива size и не шаришся по всему многотысячному коду а хде это у меня переменная не обнулилась? :о), а главное всё как на ладони, открываешь программу всё сразу понятно, вот вызов объекта вот взаимодействие объектов, если нужно понять что объект делает идёшь к коду объекта.
Что да то да, пока не освоил ООП мне казалось это такая пурга что даже лезть туда не стоит.
Как только понял, всё как рукой сняло, не нужно больше выдумывать уникальные имена переменным,
счётчик первой вложенности i, счётчик второй вложенности j, размер массива size и не шаришся по всему многотысячному коду а хде это у меня переменная не обнулилась? :о), а главное всё как на ладони, открываешь программу всё сразу понятно, вот вызов объекта вот взаимодействие объектов, если нужно понять что объект делает идёшь к коду объекта.
+10
Я бы даже поспорил с тезисом о том, что для маленьких проектов нет нужды использовать ООП.
Мне кажется, что ООП надо пихать всюду, где только можно - код удлиняется незначительно, а вот прозрачность его возрастает в разы.
+10
Я бы даже поспорил с тезисом о том, что для маленьких проектов нет нужды использовать ООП.
Мне кажется, что ООП надо пихать всюду, где только можно - код удлиняется незначительно, а вот прозрачность его возрастает в разы.
Я - сторонник ООП, так как для себя понял удобство программирования снизу вверх. От интерфейсов взаимодействия объектов к реализации классов. Все кто начинают с реализации классов - пишут не на правильном ООП, они пишут функциональные обертки. Такие обертки, кроме удобного namespace для переменных и функций ничего не дают. Это обычный библиотечный подход. Но даже этот минимум кого то устраивает и они гордо говорят "я пишу на ООП", что, впрочем, их право.
Есть матерые программисты и основатели целых течений в современном программном обеспечении, которые имеют достаточно опыта для критики парадигмы ООП. Это - старая тема, и в принципе все давно уже обсосано до мелочей, когда и где что проигрывает:
http://blogerator.ru/page/oop_why-objects-have-failed
Вот ответ сторонников ООП
http://bugtraq.ru/library/programming/objectshavenotfailed.html
Сравнение скорости С++ (небольшой тест) Объектно-ориентированное и процедурное программирование(+ разные компиляторы)
https://www.mql5.com/ru/forum/132434/page3