ООП - страница 6

 
Rosh:
Нет разницы до тех пор, пока не будет явного обращения к объекту по ссылке как к указателю. Попробуйте сами и посмотрите статью Когда нужно использовать указатели в MQL5
Спасибо!
 
Serj_Che:

Прошу не пинать а объяснить на пальцах что за зверь ООП и как его готовить.

Надеюсь услышать ответ создателей МКЛ5 и программеров которые просили сделать ООП в МКЛ5.

Насколько это ускоряет работу или замедляет. На первый взгляд МКЛ5 это пожыратель ресурсов без увеличения скорости по сравнению с МКЛ4.

Хотелось бы увидеть конкретные примеры увеличения производительности. 

ООП позволяет моделировать различные ситуации и также распараллеливать вычисления. Тетрис не очень удачный пример, его можно написать и без ООП, просто кода будет больше. А попробуйте, например, сделать аквариум, где у каждой рыбки своя скорость и своя траектория и этих рыб штук 500. - Вот примерно для таких задач ООП - это самое то! Если взять торговлю на форекс советниками, то к примеру, объектом можно сделать прогон по истории с определенными параметрами, это при том что советник сам будет в это время торговать. Или же те же графические панели - инструментарии - например, несколько независимых окон данных. Там где нужна параллельность работы, вычислений - там самое место ООП.

 

ООП ни какой связи с распараллеливанием не имеет.

 
papaklass:
Значит утверждение "Там где нужна параллельность работы, вычислений - там самое место ООП." не правда?

CUDA, к примеру, пишется на простом С, и ни о каком ООП там и речи не может быть.

На сколько я знаю, на сегодняшний день вообще нет языков, которые бы использовали ООП непосредственно для распараллеливания.

 
papaklass:
Значит утверждение "Там где нужна параллельность работы, вычислений - там самое место ООП." не правда?
Не совсем. Применяя ООП следует учитывать учет ресурсов, к примеру рыбок не 500, а 5 млн. плюс водросли)). Какой бы пример вам привести, к примеру у вас есть советник в котором используется несколько схем управления капиталом. И вот хотели бы видеть всю динамику работы эксперта при разных схемах управления капиталом. Если без ООП, то пришлось бы последовательно вычислять по каждой схеме, что может привести к устареванию тика. Или же сделать выполнение каждой схемы ММ в объекте. Так как есть запас ресурсов, то все будет выводиться практически "одинаково" - "параллельно". Вот такое распараллеливание я имел ввиду.
 
papaklass:
Значит утверждение "Там где нужна параллельность работы, вычислений - там самое место ООП." не правда?

Да. Не правда.

 
Serj_Che:

ООП - это ошибка, как "Нива" или "Лада".

Используйте в MetaTrader 5 обычное процедурное программирование.

Оно здесь также доступно как и в MetaTrader 4.

Жаль, что MetaQuotes не делают на этом акцент.

 
MoneyJinn:

ООП - это ошибка, как "Нива" или "Лада".

Используйте в MetaTrader 5 обычное процедурное программирование.

Оно здесь также доступно как и в MetaTrader 4.

Жаль, что MetaQuotes не делают на этом акцент.


Ошибка, с чего бы это?
 
MoneyJinn:

ООП - это ошибка, как "Нива" или "Лада".

Используйте в MetaTrader 5 обычное процедурное программирование.

Оно здесь также доступно как и в MetaTrader 4.

Жаль, что MetaQuotes не делают на этом акцент.

По моему мнению, Вы ошибаетесь очень сильно!

Как только у Вас появятся большие проекты (хотя бы несколько тысяч строк кода), Вы убедитесь, что программирование с классами (ООП) очень сильно облегчает дело и позволяет достаточно легко контролировать процесс разработки и, что особенно важно, отладки.

Кроме того, ООП делает проекты ближе к реальной жизни, ведь в обычной жизни мы имеем дело как-раз с экземплярами объектов (дом, дерево, человек, машина, ордер и т.д.), т.е. с совокупностью свойств и методов  :)

Да Вы попробуйте сделать что-либо на ООП, сами увидите, что это более элегантно и понятно. Это легче, чем процедурное программирование!

 

MoneyJinn:

ООП - это ошибка, как "Нива" или "Лада".

Используйте в MetaTrader 5 обычное процедурное программирование.

Оно здесь также доступно как и в MetaTrader 4.

Жаль, что MetaQuotes не делают на этом акцент.


Пока применение ООП не принесет практическую пользу в виде денег, видимо, споры будут. Я не сторонник спорить, в конце да концов можно и в википедии почитать и погуглить про плюсы и минусы ООП, про распараллеливание. Кому нужны примеры - их в комплекте программ терминала много. Даже вот этот комплект программ терминала разве не облегчил это процесс написания программ? Обычное процедурное программирование менее универсально.

У меня несколько объектов, каждый делает что то свое - для каждого процедуры писать и ждать когда они сделаются по очереди - уж увольте.

ООП - это ошибка, как "Нива" или "Лада". - смело! Интересно, сколько у вас на компе программ установлено включая ОС-ы? И каково соотношение программ в которых при создании использовалось ООП и программ где не использовалось.

Причина обращения: