Разговоры на завалинке о ООП - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
ЗЫ: кстати, во всей ветке не увидел ни одного пожелания по освещению какой-либо темы, как всегда, обычная грызня.
Судя по выбору начального примера, возникают вполне резонные сомнения в качестве освещения
А можно уточнить, кто они и чему не научились? Модераторы не научились чистить или что-то другое )
ЗЫ: кстати, во всей ветке не увидел ни одного пожелания по освещению какой-либо темы, как всегда, обычная грызня. Так что я решил роликов на ютубе записать с нуля по устройству ООП, хоть какая-то польза будет. Все равно ветка через какое-то время окажется в ветко_отстойнике.
Уточняю: не научились ООП.
Алексей, думаю ты и сам прекрасно понимаешь, что ООП нельзя вот так просто взять и нучиться. Есть формальные знания ООП: наследование, инкапсуляция, полиморфизм - все эти мантры часто повторяются, но от того, что кто-то заучит их и будет яростно и непопадя применять, вроде класс эксперта наследовать от модуля MM (привет разработчикам СБ:) скорее больше вреда чем пользы.
Что касается MQL - то это очень слабый язык с точки зрения ООП: контроль типов отсутствует полностью (хорошо хоть безопасное приведение сделали), рефлексия в зачатке и очень ограничена, интерфейсов нет вовсе. Возникает вопрос: какому такому ООП можно научить в MQL? Да что там говорить, если сами разработчики лепят такого горбатого в Стандартной Библиотеке, что иногда просто страшно становится.
Уточняю: не научились ООП.
Алексей, думаю ты и сам прекрасно понимаешь, что ООП нельзя вот так просто взять и нучиться. Есть формальные знания ООП: наследование, инкапсуляция, полиморфизм - все эти мантры часто повторяются, но от того, что кто-то заучит их и будет яростно и непопадя применять, вроде класс эксперта наследовать от модуля MM (привет разработчикам СБ:) скорее больше вреда чем пользы.
Что касается MQL - то это очень слабый язык с точки зрения ООП: контроль типов отсутствует полностью (хорошо хоть безопасное приведение сделали), рефлексия в зачатке и очень ограничена, интерфейсов нет вовсе. Возникает вопрос: какому такому ООП можно научить в MQL? Да что там говорить, если сами разработчики лепят такого горбатого в Стандартной Библиотеке, что иногда просто страшно становится.
Да, слабый, но проекты средней степени тяжести делать все же можно. СБ делали разные люди с разным уровнем подготовки. И там нет самого необходимого, я до сих пор твой CDictionary использую, а это вещь из разряда mast due.
Ну так что теперь, лечь и помереть? )) Можно в длл уйти в конце концов.
А научится ООП все же можно, я так думаю. Я же научился самоучкой. И другие тоже.
А научится ООП все же можно, я так думаю. Я же научился самоучкой. И другие тоже.
Так учиться надо на правильных примерах. А в СБ их нет. Взять тот же CObject - контроль типов он не обеспечивает, работу на уровне интерфейсов с объектами он не предоставляет, зато содержит бессмысленные методы вроде Save() и Load(), которые никогда и не переопределяются на практике. Указатели m_prev и m_next используются в одном единственном классе CList, зато присутствют как балласт для всех классов потомков. Самым полезным является метод Comparer(). Действительно он переопределяется чаще всего. Но по-хорошему Comparer() - это интерфейс, его правильней было бы определить не в CObject, а в виде отдельного класса.
По всей видимости, static и const (это не ООП) не нужны.
Что же касается ООП, то очень интересно, как будет выглядеть в процедурном стиле следующая, имеющая широкое практическое применение (совсем не абстрактная), функция?
Очевидно, что любой ООП можно переписать в процедурном стиле. Но интересует практика. Поэтому взял вышеприведенный крохотный код, где и ООП используется по минимуму.
Так насколько красивее/удобнее/читабельнее/правильнее процедурный стиль по сравнению с ООП будет в данном примере? Ну чтобы не голословить несколько страниц, а просто сравнить короткие исходники процедурный vs ООП. Прошу противников ООП показать мастер-класс. Это не страшный MT5, а старый добрый MT4.
по каким лекалам можно научиться точно так же программировать? :) очень уж симпатично вглядит
или, может, нужно еще и образ мышления сменить
например, я не знал что структуры можно использовать почти так же как классы, с конструктором
например, я не знал что структуры можно использовать почти так же как классы, с конструктором
по каким лекалам можно научиться точно так же программировать? :) очень уж симпатично вглядит
или, может, нужно еще и образ мышления сменить
например, я не знал что структуры можно использовать почти так же как классы, с конструктором
А можно спросить: что гениального Вы видите в кодах fxsaber'a? Наверное это побочные эффекты IsChange Вас так заворожили, или идея о том, что системное состояние надо дублировать еще на уровне пользователя?
А можно спросить: что гениального Вы видите в кодах fxsaber'a? Наверное это побочные эффекты IsChange Вас так заворожили, или идея о том, что системное состояние надо дублировать еще на уровне пользователя?
наверное потому, что я почти не понимаю этот код :)
сорри, программист-любитель.. с ООП на базовом уровне только знаком
в С++ класс и структура одно и то же, просто некоторые умолчания разные.
прикольно, не знал.. надо наверное просто плюсы получше поизучать
Так учиться надо на правильных примерах. А в СБ их нет. Взять тот же CObject - контроль типов он не обеспечивает, работу на уровне интерфейсов с объектами он не предоставляет, зато содержит бессмысленные методы вроде Save() и Load(), которые никогда и не переопределяются на практике. Указатели m_prev и m_next используются в одном единственном классе CList, зато присутствют как балласт для всех классов потомков. Самым полезным является метод Comparer(). Действительно он переопределяется чаще всего. Но по-хорошему Comparer() - это интерфейс, его правильней было бы определить не в CObject, а в виде отдельного класса.