Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если Вы используете классы непонятно для чего, то это не ООП.
И да, я Вам советую, пока не поймёте необходимости этих прибамбасов, не используйте их.
С таким подходом никогда понимание не придёт.
Я не думаю, что при неправильном использовании, может прийти понимание.
Игорь, помните задание которое царь дал Федоту стрельцу?
И что ответили два дюжих молодца.
Как можно пытаться что-то воспроизвести если не знать ни правил, ни окончательного результата который надо получить...
ну примерно так можно, вот имитация, что время новостей и количество новостей разное у разных стран:
но осталось выяснить, нужно ли Вам это в ООП оборачивать
;)
вот лог как все вызывалось и что в итоге получилось:
2019.09.08 16:00:35.031 tst (EURUSD,H1) NewsRU::NewsRU
2019.09.08 16:00:35.032 tst (EURUSD,H1) NewsEN::NewsEN
2019.09.08 16:00:35.032 tst (EURUSD,H1) NewsFake::NewsFake
2019.09.08 16:00:35.032 tst (EURUSD,H1) Error, not this type FR
2019.09.08 16:00:35.032 tst (EURUSD,H1) News №1 in 1970.01.01 00:01:51
2019.09.08 16:00:35.032 tst (EURUSD,H1) News №2 in 1970.01.01 00:03:42
2019.09.08 16:00:35.032 tst (EURUSD,H1) News №3 in 1970.01.01 00:05:33
2019.09.08 16:00:35.032 tst (EURUSD,H1) News №1 in 1970.01.01 00:07:24
2019.09.08 16:00:35.032 tst (EURUSD,H1) News №2 in 1970.01.01 00:09:15
Я не думаю, что при неправильном использовании, может прийти понимание.
Как минимум придёт понимание того что "тут рыбы нет".)))
Мы это много раз слышали от некоторых местных персонажей.
И это как раз от непонимания.
А рыба есть!
ну примерно так можно, вот имитация, что время новостей и количество новостей разное у разных стран:
но осталось выяснить, нужно ли Вам это в ООП оборачивать
;)
вот лог как все вызывалось и что в итоге получилось:
Нет, Игорь. Тут не такой подход.
Выделенные строки это три варианта использования. При этом диапазон времени меняется. Затем массив values[] обрабатывается определённым образом. По id события получаем описание этого события. Его важность, время и прочие атрибуты.
Мы это много раз слышали от некоторых местных персонажей.
И это как раз от непонимания.
А рыба есть!
Я читал об этом. Рыба-то есть, но не там где не понимаешь. Это-ж каким должен быть проект на mql5 чтобы тут была рыба... Хоть-бы один проект увидеть на mql5, где была-бы видна необходимость ООП.
Прям вот необходимости в ООП, наверное, нет. В принципе, всё можно сделать в структурном стиле. Но лично у меня первый позыв начался, когда я решил воспользоваться структурами вместо наборов глобальных переменных, количество которых начало угрожающе разрастаться. Ну а от структур уже перешёл к классам, поскольку логично было те функции, которые обрабатывают данные этих структур, интегрировать прям в них, что и привело к созданию классов. Это вопрос не необходимости, а просто упорядочивания данных и работы с ними.
"Убивать" объект сразу после того, как он был создан и сделал своё дело совсем не обязательно.
"Убить" созданные объекты можно в функции OnDeinit по завершению MQL-программы,
а пока программа работает, все объекты могут находиться в памяти и к ним можно обращаться.
Если объект выполнил свою задачу, зачем его держать в памяти?
Не возникнет ли утечка памяти?
Нет, Игорь. Тут не такой подход.
Выделенные строки это три варианта использования. При этом диапазон времени меняется. Затем массив values[] обрабатывается определённым образом. По id события получаем описание этого события. Его важность, время и прочие атрибуты.
подход не важен
если хотите понять ООП, то мое мнение ( уже писал ) - это удобно, но ООП это всего лишь парадигма, ну способ написания, который обьединяет несколько концепций ООП - Вики...
в общем можно попробовать от обратного : вот Ваша задача, нужно ее разбить на данные и способы обработки данных...
1. Вы где будете данные хранить? - скорее всего это структура
2. Вы как будете обрабатывать данные? - скорее всего это набор функций
3. Вы как будете инициализировать данные? - скорее всего это массив структур, и нужно будет в этот массив обнулить и затем заполнить данными
4. Вы как будете обеспечивать гибкость написанного ранее кода - рефакторинг ?
теперь если использовать ООП:
1. в полях в классе, хотя возможно это поле будет структурой, а может быть я вообще напишу базовый класс который и будет хранить данные и произведу наследование ИЛИ этот класс будет полем в обсуждаемом сейчас классе
2.1. это будет набор методов, причем если я напишу базовый класс, то возможно в базовом классе я создам методы которые будут производить простейшие действия с данными и если я буду наследоваться от базового класса, то эти методы будут доступны и в этом классе - это наследование!
2.2. а если я захочу после наследования от базового класса изменить всего один метод, я не буду переписывать в базовом классе ничего, это не нужно! - я просто напишу метод ( функцию! ) который будет называться один в один как метод в базовом классе и это будет наследование!
3. это будет конструктор, причем если конструктор я не написал, то он будет вызван неявно, поэтому я не забываю, что у каждого класса от которого я наследовался и / или класс у меня в полях будет всегда вызван конструктор, причем ООП мне дает возможность не писать конструктор, писать конструктор без параметров, писать еще дюжину конструкторов с парамерами
4. используя ООП ненужно переписывать уже ранее созданные участки кода, можно наследоваться, можно .... можно и накосячить, компилятор приберет за программистом в большинстве случаев!
фух, ну примерно такой мой довольно дилетантский взгляд на ООП , в общем это удобно и чтобы эффективно все работало основная работа при использовании ООП не у программиста, а у разработчиков компилятора, чтобы что из полей /методов не используется не включить в компилируемый файл, где программист накосячил, ну предупредить его )))