Скачать MetaTrader 5

Разговоры на завалинке о ООП - страница 7

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Комбинатор
16953
Комбинатор  
Alexey Volchanskiy:

ЗЫ: кстати, во всей ветке не увидел ни одного пожелания по освещению какой-либо темы, как всегда, обычная грызня.

Судя по выбору начального примера, возникают вполне резонные сомнения в качестве освещения

Vasiliy Sokolov
30919
Vasiliy Sokolov  
Alexey Volchanskiy:

А можно уточнить, кто они и чему не научились? Модераторы не научились чистить или что-то другое )

ЗЫ: кстати, во всей ветке не увидел ни одного пожелания по освещению какой-либо темы, как всегда, обычная грызня. Так что я решил роликов на ютубе записать с нуля по устройству ООП, хоть какая-то польза будет. Все равно ветка через какое-то время окажется в ветко_отстойнике.

Уточняю: не научились ООП.

Алексей, думаю ты и сам прекрасно понимаешь, что ООП нельзя вот так просто взять и нучиться. Есть формальные знания ООП: наследование, инкапсуляция, полиморфизм - все эти мантры часто повторяются, но от того, что кто-то заучит их и будет яростно и непопадя применять, вроде класс эксперта наследовать от модуля MM (привет разработчикам СБ:) скорее больше вреда чем пользы.

Что касается MQL - то это очень слабый язык с точки зрения ООП: контроль типов отсутствует полностью (хорошо хоть безопасное приведение сделали), рефлексия в зачатке и очень ограничена, интерфейсов нет вовсе. Возникает вопрос: какому такому ООП можно научить в MQL? Да что там говорить, если сами разработчики лепят такого горбатого в Стандартной Библиотеке, что иногда просто страшно становится. 

Alexey Volchanskiy
24816
Alexey Volchanskiy  
Vasiliy Sokolov:

Уточняю: не научились ООП.

Алексей, думаю ты и сам прекрасно понимаешь, что ООП нельзя вот так просто взять и нучиться. Есть формальные знания ООП: наследование, инкапсуляция, полиморфизм - все эти мантры часто повторяются, но от того, что кто-то заучит их и будет яростно и непопадя применять, вроде класс эксперта наследовать от модуля MM (привет разработчикам СБ:) скорее больше вреда чем пользы.

Что касается MQL - то это очень слабый язык с точки зрения ООП: контроль типов отсутствует полностью (хорошо хоть безопасное приведение сделали), рефлексия в зачатке и очень ограничена, интерфейсов нет вовсе. Возникает вопрос: какому такому ООП можно научить в MQL? Да что там говорить, если сами разработчики лепят такого горбатого в Стандартной Библиотеке, что иногда просто страшно становится. 

Да, слабый, но проекты средней степени тяжести делать все же можно. СБ делали разные люди с разным уровнем подготовки. И там нет самого необходимого, я до сих пор твой CDictionary использую, а это вещь из разряда mast due.

Ну так что теперь, лечь и помереть? )) Можно в длл уйти в конце концов.

А научится ООП все же можно, я так думаю. Я же научился самоучкой. И другие тоже.

Vasiliy Sokolov
30919
Vasiliy Sokolov  
Alexey Volchanskiy:

А научится ООП все же можно, я так думаю. Я же научился самоучкой. И другие тоже.

Так учиться надо на правильных примерах. А в СБ их нет. Взять тот же CObject - контроль типов он не обеспечивает, работу на уровне интерфейсов с объектами он не предоставляет, зато содержит бессмысленные методы вроде Save() и Load(), которые никогда и не переопределяются на практике. Указатели m_prev и m_next используются в одном единственном классе CList, зато присутствют как балласт для всех классов потомков. Самым полезным является метод Comparer(). Действительно он переопределяется чаще всего. Но по-хорошему Comparer() - это интерфейс, его правильней было бы определить не в CObject, а в виде отдельного класса. 

Maxim Dmitrievsky
21899
Maxim Dmitrievsky  
fxsaber:

По всей видимости, static и const (это не ООП) не нужны.

Что же касается ООП, то очень интересно, как будет выглядеть в процедурном стиле следующая, имеющая широкое практическое применение (совсем не абстрактная), функция?

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

Так насколько красивее/удобнее/читабельнее/правильнее процедурный стиль по сравнению с ООП будет в данном примере? Ну чтобы не голословить несколько страниц, а просто сравнить короткие исходники процедурный vs ООП. Прошу противников ООП показать мастер-класс. Это не страшный MT5, а старый добрый MT4.


по каким лекалам можно научиться точно так же программировать? :) очень уж симпатично вглядит

или, может, нужно еще и образ мышления сменить

например, я не знал что структуры можно использовать почти так же как классы, с конструктором

Комбинатор
16953
Комбинатор  
Maxim Dmitrievsky:

например, я не знал что структуры можно использовать почти так же как классы, с конструктором

в С++ класс и структура одно и то же, просто некоторые умолчания разные.
Vasiliy Sokolov
30919
Vasiliy Sokolov  
Maxim Dmitrievsky:

по каким лекалам можно научиться точно так же программировать? :) очень уж симпатично вглядит

или, может, нужно еще и образ мышления сменить

например, я не знал что структуры можно использовать почти так же как классы, с конструктором

А можно спросить: что гениального Вы видите в кодах fxsaber'a? Наверное это побочные эффекты IsChange Вас так заворожили, или идея о том, что системное состояние надо дублировать еще на уровне пользователя?

Maxim Dmitrievsky
21899
Maxim Dmitrievsky  
Vasiliy Sokolov:

А можно спросить: что гениального Вы видите в кодах fxsaber'a? Наверное это побочные эффекты IsChange Вас так заворожили, или идея о том, что системное состояние надо дублировать еще на уровне пользователя?


наверное потому, что я почти не понимаю этот код :)

сорри, программист-любитель.. с ООП на базовом уровне только знаком

Maxim Dmitrievsky
21899
Maxim Dmitrievsky  
Комбинатор:
в С++ класс и структура одно и то же, просто некоторые умолчания разные.

прикольно, не знал.. надо наверное просто плюсы получше поизучать

Yuriy Asaulenko
5189
Yuriy Asaulenko  
Vasiliy Sokolov:

Так учиться надо на правильных примерах. А в СБ их нет. Взять тот же CObject - контроль типов он не обеспечивает, работу на уровне интерфейсов с объектами он не предоставляет, зато содержит бессмысленные методы вроде Save() и Load(), которые никогда и не переопределяются на практике. Указатели m_prev и m_next используются в одном единственном классе CList, зато присутствют как балласт для всех классов потомков. Самым полезным является метод Comparer(). Действительно он переопределяется чаще всего. Но по-хорошему Comparer() - это интерфейс, его правильней было бы определить не в CObject, а в виде отдельного класса. 

Всегда поражался глубине знаний MQL рядом товарищей. Я посмотрел, попробовал даже реально применить CExpert, плюнул,  и стал делать свои классы. Мне до таких высот как CObject и CExpert не подняться.
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий