Будет ли востребовано ООП в MQL5? - страница 5

 

Svinozavr писал(а) >>

Ну а для себя отчего нет?

По старой памяти, привычней как-то. Надо перепривыкнуть.

Статья нужна. Буду ждать. Да все ждут. Только там, как я понял, тоже "пока".)))

Там видно будет. Коды для статьи еще будут дорабатываться.

 

Пишу для себя сразу с применением ООП. Медленно. Не для публикации.

 

Ясно. Просто судя по постам этой ветке, казалось, что вот только дай возможность ООП, так сразу. По крайней мере, в этом меня и друг друга активно убеждали.

Ладно. Действительно, две недели от беты всего прошло. Подождем.

Но ведь, согласитесь, интересно было б посмотреть на ООП хотя бы вашем опубликованном индикаторе! Слушайте, идея! Почему бы вам в статье или просто как вариант опубликованного вами индикатора, не переписать его с применением ООП? Было бы очень наглядно: вот один и тот же индюк в двух реализациях - процедурном и ОО.

 
Svinozavr >>:

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


То есть, есть конечно теория, как оно могло бы быть, если писать на ООП, и есть практика программирования, в которой ООП используется далеко не всегда.


PS. когда был опрос, "а чего вам ещё нужно в мт5" - я сразу сказал, дайте записи, - а классы мне даром не нужны. При этом, я без зазрения совести пытаюсь писать программки на Дельфи, который точно сам по себе ООП.

 

Svinozavr писал(а) >>

Но ведь, согласитесь, интересно было б посмотреть на ООП хотя бы вашем опубликованном индикаторе! Слушайте, идея! Почему бы вам в статье или просто как вариант опубликованного вами индикатора, не переписать его с применением ООП? Было бы очень наглядно: вот один и тот же индюк в двух реализациях - процедурном и ОО.

Ну куда же от процедурного стиля денешься, если он навязывается по умолчанию?

Сравнить хотя бы количество встроенных объектов и функций. Или саму реализацию -- имеются в виду функции OnCalculate OnInit OnDeinit OnTick и т.д.

В статье тогда уже, если найду эффективные места для применения. Впрочем, уже нашел наверное.

 
TheXpert >>:

Ну куда же от процедурного стиля денешься, если он навязывается по умолчанию?

Сравнить хотя бы количество встроенных объектов и функций. Или саму реализацию -- имеются в виду функции OnCalculate OnInit OnDeinit OnTick и т.д.


Да, согласен. Потому отчасти и эту тему открыл.

В статье тогда уже, если найду эффективные места для применения. Впрочем, уже нашел наверное.

Очень интересно будет почитать. Спасибо.

 

TheXpert писал(а) >>

В статье тогда уже, если найду эффективные места для применения. Впрочем, уже нашел наверное.

Мде, как все-таки тяжело оказалось на MQL5 после C++ писать в стиле ООП...

 
api >>:
Наверное ZUP от nen'а будет неплохим примером. Там много чего наворочено. Одна только масса исходника внушает уважение (368Kb v82), не говоря уже о содержании.

Хи-хи... Архив моего проекта весит 7 Мб. EX4 эксперта 800 кб., индикатора 100 кб, а ещё там есть скрипты и куча библиотек...

И всё это без ООП. Я не к тому, что ООП не нужно.
 
Zhunko писал(а) >>

Хи-хи... Архив моего проекта весит 7 Мб. EX4 эксперта 800 кб., индикатора 100 кб, а ещё там есть скрипты и куча библиотек...

И всё это без ООП. Я не к тому, что ООП не нужно.

Хо-хо... Ваш проект будет примером не хуже.

 

Создается впечатление что люди хающие ООП его просто не знают. Прежде чем рассуждать о ООП его неплохо было бы изучить на примере С++. По разговорам о том что С++ это изврат ибо не напоминает логику человеческих языков можно определить, что их автор знаком с языком достаточно поверхностно. В совершенстве овладейте работой с библиотекой STL и тогда можете порассуждать о достоинствах и недостатках ООП, а пока не зная темы набирайтесь ума а не лезти в дебри.

З.Ы. У большинства ООП ассоциируется с конкретным языком программирования С++, MQ5 - это ООП, С, MQ4 - это не ООП. Это не правильно. ООП существует даже в Си, однако почему-то многие об этом не знают, что опять-таки говорит о поверхностных знаниях.

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