Что может делать ООП-код, чего не может процедурный код? - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы действительно ожидаете, что кто-то профессиональный выложит библиотеку compex, просто так, в качестве "доказательства"? ;) Я мог бы дать вам ссылку на что-то готовое, что не может быть продано на рынке здесь, но Ален даст мне пинка, если я это сделаю ;) Вы можете посетить мой профиль и взглянуть на картинку на стене, чтобы получить представление или написать мне в почту.
Другая платформа? Вы не найдете другой платформы с таким мощным компилятором. Вовсе нет.
@James Cater - спасибо большое за ваши комментарии.
Есть и другие платформы, кроме MT, а что касается более или менее мощного компилятора, то мне все равно, лишь бы я мог писать простой код.
Чего вам здесь не хватает, так это образования, мы все все еще учимся, просто некоторые находятся дальше по пути, чем другие. Насколько я знаю, это не конкурс, а место для обмена знаниями и поддержки.
И кстати, я не верю, что кто-то на этом форуме напишет программу в миллион строк.
Вы упустили суть, Дирк. Люди, не являющиеся специалистами, хотят простых и понятных примеров кода, что, собственно, и было моей целью в этой теме. Но это кажется совершенно недоступным пониманию специалистов.
Вы сказали, что ключевое происходит в каждом языке. Новейшие языки пытаются упростить вещи для людей с меньшими знаниями кодирования, которые могут быть добавлены в группу "кодеров". Лучший пример - псевдоязык HTML. И это большая ошибка. Когда MT5 был разработан, многие "новички" обвиняли стиль ООП в том, что он был сложным. Но правда в том, что в каждой работе есть свои профессионалы. Если вы хотите улучшить платформу, вы должны ее усложнить. Больше функций, больше гибкости. Позволить людям без знаний кодирования попытаться сделать это, это как кто-то без знаний в строительстве домов сделать один. Это будет катастрофа.
Насчет длины проектов зависит от кодера. Моя библиотека среднего размера для языка MQL. Другим нужны только небольшие библиотеки для создания инструментов. В моем случае я предпочитаю тратить время на создание фреймворка, чтобы сэкономить время и упростить разработку в будущем. Если вам нужно сделать сложный пользовательский интерфейс или повторно использовать код для других проектов - это более разумный путь.
Вы сказали, что ключевое происходит в каждом языке. Новейшие языки пытаются упростить вещи для людей с меньшими знаниями кодирования, которые могут быть добавлены в группу "кодеров". Лучший пример - псевдоязык HTML. И это большая ошибка. Когда MT5 был разработан, многие "новички" обвиняли стиль ООП в том, что он был сложным. Но правда в том, что в каждой работе есть свои профессионалы. Если вы хотите улучшить платформу, вы должны ее усложнить. Больше функций, больше гибкости. Позволить людям без знаний кодирования попытаться сделать это, это как кто-то без знаний в строительстве домов сделать один. Это будет катастрофа.
Насчет длины проектов зависит от кодера. Моя библиотека среднего размера для языка MQL. Другим нужны только небольшие библиотеки для создания инструментов. В моем случае я предпочитаю тратить время на создание фреймворка, чтобы сэкономить время и упростить разработку в будущем. Если вам нужно сделать сложный пользовательский интерфейс или повторно использовать код для других проектов - это более разумный путь.
Значит, люди не могут приобретать знания?
Процедурный vs ООП - бесполезный спор, 3 года назад это уже обсуждалось, и мой ответ полностью обоснован, больше здесь ничего не сказано:
Форум о трейдинге, автоматических торговых системах и тестировании торговых стратегий
Программисты: Что вы предпочитаете: ООП против процедурного
Alain Verleyen, 2013.06.11 13:11
В вашем опросе не хватает варианта для тех, кто ничего не предпочитает. Я имею в виду, что это не только вопрос предпочтений, что нет смысла использовать ООП для маленького скрипта или даже простого советника. ООП всегда добавляет работы и выгодно только для сложных проектов и повторного использования кода (один и тот же код используется в нескольких проектах). Сложный - не то же самое, что большой, если у кого-то большой проект, но относительно простой ,это не означает, что он автоматически должен использовать ООП.
Вы можете увидеть большой потенциал ООП в MQL5 Wizard , разработанном Metaquotes, было бы очень трудно разработать такой инструмент с помощью процедурного программирования,хотя это и возможно.
ООП должно быть использовано:
С этого момента я не буду принимать ни одного сообщения, которое не является конкретным, без примера кода, демонстрирующего, почему и как ООП лучше использовать в вышеуказанных случаях.
Процедурный vs ООП - это бесполезный спор, 3 года назад это уже обсуждалось, и мой ответ полностью обоснован, больше здесь ничего не было сказано:
ООП должно быть использовано:
С этого момента я не буду принимать ни одного сообщения, которое не является конкретным, без примера кода, чтобы продемонстрировать, почему и как ООП лучше использовать в вышеуказанных случаях.
Я читаю всю эту тему и нахожу это интересным, но разве машинный код не является процедурным? То есть языки высокого уровня, и ООП в том числе, все они в конечном итоге переводятся в процедурный в компиляторе, так? Если все языки переводятся в процедурный машинный код, то мы можем сказать, что все можно сделать на процедурном языке, если программист обладает соответствующими навыками, пожалуйста, кто-нибудь поправьте меня, если я ошибаюсь.
Теоретически все можно сделать на процедурном. Но это не так на практике.
Кирпич состоит из тысяч тысяч частиц песка, поэтому вы можете построить дом без кирпичей, просто из песка.
Но никто даже не пытается, когда у вас есть кирпичи.
Самолет строится из готовых деталей - крыльев, колес, сидений, компьютеров и т. д. Все они в конце концов делаются из металла, или пластика, или стекла. Но никто не будет строить самолет из чистого стекла, пластика и металла.
Для дебатов в целом (в ответ Алене и другим): Возьмем CArrayObj - массив объектов. Одного этого достаточно, чтобы ответить, в чем сила OO (которая гораздо больше, чем это). Он может хранить массив любых объектов - например, индикаторов.
И без особых усилий делать сложные вещи для всех этих различных индикаторов. И если вы теперь хотите получить новую силу, например, вы хотите знать, когда буфер индикатора пересекается, вам просто нужно поместить метод в CIndicator, и все. И так далее. Как бы вы сделали это в процедурном?
И это можно сделать во всех аспектах - стратегии, сделки, сделки, сигналы - что угодно.
Все можно сделать в процедурном теоретически. Но не на практике.
Кирпич строится из тысяч тысяч частиц песка, поэтому вы можете построить дом без кирпичей, просто из песка.
Но никто даже не пытается, когда у вас есть кирпичи.
Самолет строится из готовых деталей - крыльев, колес, сидений, компьютеров и т. д. Все они в конце концов делаются из металла, пластика или стекла. Но никто не будет строить самолет из чистого стекла, пластика и металла.
Для дебатов в целом (в ответ Алене и другим): Возьмем CArrayObj - массив объектов. Одного этого достаточно, чтобы ответить, в чем сила OO (которая гораздо больше, чем это). Он может хранить массив любых объектов - например, индикаторов.
И без особых усилий делать сложные вещи для всех этих различных индикаторов. И если вы теперь хотите получить новую силу, например, вы хотите знать, когда буфер индикатора пересекается, вам просто нужно поместить метод в CIndicator, и все. И так далее. Как бы вы сделали это в процедурном?
И это можно делать во всех аспектах - стратегии, сделки, сделки, сигналы - что угодно.
Эта тема была намеренно провокационной, однако ответ на главный вопрос (что может сделать ООП, чего не может процедурный код) - НИЧЕГО.
ООП, конечно, не единственный способ создания и использования кирпичиков. В ООП есть как минимум столько же способов создать плохой код, сколько и в процедурном коде (а скорее всего, даже больше). Просто посмотрите на "стандартную библиотеку", предоставляемую Metaquotes, которая на самом деле далека от "стандартной".
ООП против процедурного - это бесполезный и бесконечный спор. Более полезным был бы вопрос: "Как создавать качественный код? С ООП и без ООП, с процедурным и без процедурного, с любой парадигмой программирования и без нее". Если вам нужно построить деревянный дом, вам не нужны кирпичи, но вам нужно, чтобы это был хороший, прочный и надежный дом.
Теоретически все можно сделать в процедурном. На практике это невозможно.
Кирпич строится из тысяч тысяч частиц песка, поэтому вы можете построить дом без кирпичей, просто из песка.
Но никто даже не пытается, когда у вас есть кирпичи.
Самолет строится из готовых деталей - крыльев, колес, сидений, компьютеров и т. д. Все они в конце концов делаются из металла, или пластика, или стекла. Но никто не будет строить самолет из чистого стекла, пластика и металла.
Для дебатов в целом (в ответ Алене и другим): Возьмем CArrayObj - массив объектов. Одного этого достаточно, чтобы ответить, в чем сила OO (которая гораздо больше, чем это). Он может хранить массив любых объектов - например, индикаторов.
И без особых усилий делать сложные вещи для всех этих различных индикаторов. И если вы теперь хотите получить новую силу, например, вы хотите знать, когда буфер индикатора пересекается, вам просто нужно поместить метод в CIndicator, вот и все. И так далее. Как бы вы сделали это в процедурном?
И это можно делать во всех аспектах - стратегии, сделки, сделки, сигналы - что угодно.
В вашем примере, когда вы пишете код OO и нажимаете компиляцию, он генерирует машинный код. Но этот машинный код является процедурным или нет? Я действительно не знаю ответа, кто-нибудь знает? Если машинный код является процедурным, тогда вы можете назвать OO только языком более высокого уровня, который облегчает только код, но ничего особенного, так что опытный программист C может сделать ту же работу, что и программист OO, на самом деле, он может быть даже лучше оптимизирован. Так что мой вопрос, бывший код продедурален или нет?