Что может делать ООП-код, чего не может процедурный код? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Программирование графических интерфейсов - это то, чем я занимался большую часть своего времени в качестве программиста. Невозможно написать полноценный графический интерфейс, который должен взаимодействовать в нескольких направлениях по принципу if then else. Вам потребуется столько утверждений, что код станет нечитабельным и, в конце концов, слишком медленным, что приведет к тому, что цель не будет достигнута. Факт.
Я не буду создавать GUI на процедурном языке, чтобы доказать, что вы не правы. Но я мог бы, без всякого сомнения.
Кстати, в ООП также легко написать нечитаемый и гораздо более медленный код, и, как вы знаете, стандартная библиотека Metaquotes является хорошим доказательством этого.
...
В силу того обстоятельства, что процессор ничего не знает об ООП, можно - конечно - закодировать все без него, просто используя указатели и сложные массивы. Но это абсурд. Я также могу нанять 10000 человек, которые будут рисовать содержимое моего экрана на пленке в режиме реального времени и последовательно транслировать его световым проектором на стену. Это тоже достижение цели?
Согласны ли вы с тем, что операционная система Windows предлагает хороший графический интерфейс? Насколько я знаю, она написана на C. Процедурный язык, а не ООП.
Вы ошибаетесь, Дирк, если думаете, что сложная программа может быть построена только с помощью ООП. Вам лучше объяснить, почему лучше написать ее на ООП.
Да ладно ;) Не совсем ;) Если что-то родное могло бы делать эту работу как-то странно, то это указатели, но в MQL есть ограничения. Если бы еще ... код стал бы абсурдным.
Я сильно сомневаюсь, что ООП - это более короткий способ кодирования.
Согласны ли вы с тем, что операционная система Windows предлагает хороший графический интерфейс? Насколько я знаю, она написана на C. Процедурный язык, а не ООП.
Вы ошибаетесь, Дирк, если думаете, что сложная программа может быть построена только с помощью ООП. Вам лучше объяснить, почему лучше кодировать ее с помощью ООП.
Я кодировал графические интерфейсы на Ассемблере, полностью. Но в Ассемблере я могу работать с указателями, в Си я могу работать с указателями, и, конечно, основа Windows - это не ООП, но мы говорим о MQL, который не поддерживает указатели void нативным способом, и из-за этого вы не сможете кодировать сложные GUI с помощью if then else, по крайней мере, не с результатом, который можно использовать без большого недостатка производительности.
И этот ответ уже включает в себя вопрос, почему с ООП лучше - при этом "лучше" все еще является неправильным определением. Метод ООП реализует использование таких указателей, но не заставляя вас иметь с ними дело. Внутри ООП реализуется с помощью многомерных массивов для указателей функций и переменных. Пытаться кодировать подобные вещи - это то же самое, что изобретать колесо, которое никогда не будет катиться так же гладко, как то, которое у вас уже есть перед глазами.
Я кодировал графические интерфейсы на Ассемблере, полностью. Но в Ассемблере я могу работать с указателями, в Си я могу работать с указателями, и, конечно, основа Windows - это не ООП, но мы говорим о MQL, который не поддерживает указатели void по-настоящему, и из-за этого вы не сможете кодировать сложные GUI с помощью просто if then else, по крайней мере, не с результатом, который можно использовать без большого недостатка производительности.
И этот ответ уже включает в себя вопрос, почему с ООП лучше - при этом "лучше" все еще является неправильным определением. Метод ООП реализует использование таких указателей, но не заставляя вас иметь с ними дело. Внутри ООП реализуется с помощью многомерных массивов для указателей функций и переменных. Пытаться кодировать подобные вещи - это то же самое, что изобретать колесо, которое никогда не будет катиться так же гладко, как то, которое у вас уже есть перед глазами.
Это только мое личное предпочтение из-за моего небольшого(!) опыта!
1) Мне не нравится, например, Java, так как я 99% времени искал функцию, не зная, как она может называться, существует ли она или нет, и придется ли мне ее кодировать самостоятельно...
2) Мне не нравится C++, потому что мне приходится писать больше, чем если бы я писал на скриптовом языке, таком как mq4 или даже Perl.
3) Я не люблю C++, потому что понимание чужого кода позволяет мне прыгать из файла в файл, где я нахожу только функции с 2,3 строками, что делает очень трудным выяснение того, что и как вычисляется s.th.. Конечно, есть объяснения типа "вычисление остановки", но процедура calc.-procedure также разбита на несколько функций в разных файлах.
4) Меня абсолютно устраивают enum и массивы enum-переменных. Мне не нужно кодировать воображаемые реальные объекты. GUI может быть другой проблемой, так как он состоит из многих других вещей, которые могут быть закодированы как объекты для простого способа повторного использования. Но сколько различных объектов нужно советнику? Один для позиций? Если бы было много различных "объектов" (GUI), это могло бы помочь - но я не вижу их здесь.
5) Наконец, MQ5 все еще не может запустить свой бэктест на тиках клиента:( <Отредактировано модератором как не по теме: это не имеет отношения к mql5, но имеет отношение к MT5>.
Я действительно уважаю тех, кто кодирует ассемблер, вы должны хорошо знать, как работает само оборудование, просто потрясающе, круто, никто не использует сегодня
Я больше не кодирую, но в прошлом это было очень важно. На чипах Intel 80x86 это был единственный шанс добиться реального преимущества в визуальной производительности. И конечно, это базовое знание, которое я не хочу упускать, даже если оно мне больше не нужно в деталях, но вы всегда знаете, что происходит с вашим кодом в конце концов, и знаете, как использовать это как преимущество в скорости выполнения.
Да, "добрые" старые времена ;) ... Но и безумие тоже, не было даже переменных, никаких реальных функций, никаких if then else, только регистры, стеки, прерывания и адреса памяти. Сумасшедшее дерьмо :)
ООП - это инструмент для разделения кода на небольшие многократно используемые части. Но самая лучшая часть - это шаблоны. Эта функция позволяет упростить код. Лучший пример - класс массива. В Java вы должны создать класс для типа. В C++ и Mql5 вы можете иметь это в одном классе, сокращая избыточный код и обходя некоторые проблемы, когда вы смешиваете примитивы и объекты.
PS: Насчет ASM, это старая школа. Я использовал его, когда еще не было первых компиляторов режима защиты и было забавно преодолевать ограничения. 64K сегменты с селекторами были кошмаром кодеров того времени. Каждый раз, когда вы писали в неправильном месте, вы перезагружали компьютер :)