ООП - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ошибся я-"Нет такой задачи которую можно написать на ООП и которую нельзя написать без ООП."
Попробуйте на MQL4 реализовать списки, деревья, графы. Это не возможно. На MQL5 - это делается легко, можно даже не изобретать велосипед, а найти код на С++ и с минимальными переделками использовать его. И естествено типы которые я привел в качестве примера лучше оформить в виде классов. Нейроные сети, нечеткая логика, и многое другое, теперь может быть комфортно реализовано на MQL5. Но естьствено каждый инструмет должен соответствовать решаемой задаче, и ООП надо использовать лишь при необходимости. Крики тех, кто ругает новые возможности смешны. Не нравиться не используйте, ведь вас никто не заставляет их использовать. Пользуйтесь функциональным программированием.
Вы не путайте "не возможно" и "трудно", нет такой задачи которую нельзя решить с помощью процедурного программирования и которую при этом можно решить на ООП я имею в виду конечный функционал программы..
Да и вобще, можно писать на ассемблере, а то расслабились, подавайте готовенькое :)
ООП основан на том же процедурном программировании с добавленной изоляцией данных и функций.
Например на ООП дольше писать программу "Hello world!", но быстрее можно написать крупный проект, грань между выбором писать на ООП или без ООП очень размытая и зависит от опыта программиста, цели и предпочтений.
Лично для меня удобнее ООП в большинстве случаев, т.к. я знаю его "узкие" и "широкие" места и есть опыт программирования на ООП (C++,JavaScript,PHP).
Но если я пишу какой-нибудь короткий тестовый скрипт, то не использую ООП.
Совет: прежде чем переходить на ООП в реальных задачах нужно попрактиковаться на простых примерах, например написать класс который будет складывать два числа и т.п.
Врятли получится прочитав в книжке о ООП начать на нем программировать серьезные программы без практики.
К нему нужно привыкнуть, начать думать в контексте ООП, видеть что нужно оформит как класс, а что не стоит.
Списки, деревья, графы, именно невозможно в MQL4 нет указателей.
Заметьте это реализация, а не итог.
Мы программируем ради результата (программы) или ради реализации программы?
Можно обойтись без всех этих способов и организовать на массивах и передачах по значению.
Это сложно, трудоемко, но возможно.
Заметьте это реализация, а не итог.
Мы программируем ради результата (программы) или ради реализации программы?
Можно обойтись без всех этих способов и организовать на массивах и передачах по значению.
Это сложно, трудоемко, но возможно.
Тем кто "родился" в век Windows и ООП не понять того что такое DOS и С / Turbo Pascal (я уже об Asm молчу)...
ИМХО конечно, но....
Тем кто "родился" в век Windows и ООП не понять того что такое DOS и С / Turbo Pascal (я уже об Asm молчу)...
ИМХО конечно, но....
Для разнообразия надо все попробовать, ведь программист может решить задачу сразу несколькими способами :)
А так, отладка программы на асм вгоняет в депрессию :)
Заметьте это реализация, а не итог.
Мы программируем ради результата (программы) или ради реализации программы?
Можно обойтись без всех этих способов и организовать на массивах и передачах по значению.
Это сложно, трудоемко, но возможно.
Согласен, вприцепе можно сделать, при условии что массив динамический. Но согласитесь это не очень элегантное решении. На ассемблере это сделать проще. А ОПП родилось раньше Виндовс. И его идеи помогали мене программировать на ассемблере для РС/ХТ. А первый мой учебник по программированию - это трехтомник Кнута.
Итак, приходим к мысли - "ООП - удобно" :)
И еще: "Если тебе не удобно пользоваться ООП - не пользуйся" :)
Две простых концепции...
ООП хорошая штука для больших программ.
Если кода меньше 50-ти строк, то надобности в ООП не возникает.
А вот когда кода становится очень много, понять что к чему относится почти невозможно, только по комментариям.
Возрастает вероятность ошибки при не запланированном совместном использовании переменных, ужас, каша.
В ООП можно сделать что-бы переменные хранились внутри контейнера(класса) вместе с методами (функциями).
Нет такой задачи которую можно написать на ООП и которую нельзя написать без ООП.
Дело в удобстве))
ООП это не метод решения задач, а способ структуризации кода.
Надобность в использовании ООП возникает, если программа становиться больше "Hello word".
А Вообще, Я знаю MQL4 несколько лет, и не перестаю поражаться его убогости. Четвертому MQL далеко как до звезды даже до возможностей классического Cи. В MQL5 разработчики решили идти вперед. Возможностей стало реально больше, а программировать стало реально легче. Язык стал сложней, это да, но продукт делался не для изучения в школе.