Вопросы по ООП в MQL5 - страница 33

 
Alexey Viktorov:

Не секрет, выборка событий экономического календаря CalendarValueHistory(). В одном случае все новости в диапазоне времени. В другом по стране и другому диапазону времени. В третьем по символу. Но разве есть принципиальная разница? Разве на лекциях по программированию делят решения по типу выполняемых задач?

Я недавно встречал такого, который не сдал экзамен по вождению и возмущаясь говорил, что по этому перекрёстку они на занятиях по вождению не ездили и он просто не знает как на этом перекрёстке надо ехать.

Когда Вы создаёте класс, то этим Вы вводите новый тип данных.

Что конкретно делает Ваш класс не так важно.

Важно что Вы планируете делать с объектами класса как с данными?

(Помещать в массив, передавать в функции, возвращать из функций, ...)

Пока не понятно, нужен ли вообще этот класс.

И если нужен, то должен ли он быть обязательно один, а не три.

Может быть в Вашей задаче можно обойтись одной (или тремя) функцией?

 
Alexey Viktorov:

Тоска... Тут ещё и шаблоны с интерфейсами надо осваивать???

интерфейсов как таковых нет в MQL, пару страниц назад с абстрактным классом был - будет тоже самое, мне проще код просто потом читать

через интерфейсы удобно инициализировать разными конструкторами

в справке пример https://www.mql5.com/ru/docs/basis/types/classes по ключевому слову interface - это один в один мой шаблон, попробуйте воспроизвести у себя пример, возможно это то что Вы ищете

 
Igor Makanu:

интерфейсов как таковых нет в MQL, пару страниц назад с абстрактным классом был - будет тоже самое, мне проще код просто потом читать

через интерфейсы удобно инициализировать разными конструкторами

в справке пример https://www.mql5.com/ru/docs/basis/types/classes по ключевому слову interface - это один в один мой шаблон, попробуйте воспроизвести у себя пример, возможно это то что Вы ищете

Игорь, помните задание которое царь дал Федоту стрельцу?

     Исхитрись-ка мне добыть
     То-Чаво-Не-Может-Быть!
     Запиши себе названье,
     Чтобы в спешке не забыть!

И что ответили два дюжих молодца.

     Кабы схемку аль чертеж --
     Мы б затеяли вертеж,
     Ну а так -- ищи сколь хочешь,
     Черта лысого найдешь!

Как можно пытаться что-то воспроизвести если не знать ни правил, ни окончательного результата который надо получить...

 
Alexey Viktorov:

Тоска... Тут ещё и шаблоны с интерфейсами надо осваивать???

Ну, если тоска, то не Ваше это.
 
Koldun Zloy:

Когда Вы создаёте класс, то этим Вы вводите новый тип данных.

Пока не понятно, нужен ли вообще этот класс.

И если нужен, то должен ли он быть обязательно один, а не три.

Может быть в Вашей задаче можно обойтись одной (или тремя) функцией?

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

 
Alexey Viktorov:

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

Функцию тоже можно вызывать и из индикатора и из советника.

 
Alexey Viktorov:

Кажется я начинаю понимать необходимость и пользу ООП, но затрудняюсь в реализации.

Имеется класс который должен использоваться с тремя разными наборами переменных. Но выполняет одну задачу. По простому, можно вставить 3 конструктора, объявить 3 переменных и обращаться к ним. Но, как я понимаю это не совсем грамотно. Плюс ко всему в двух вариантах одна из переменных типа string но разные по имени и используются в разных частях кода. Конечно можно изменить последовательность переменных, но и это, как я понимаю это не совсем грамотно.

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

В общем прошу помощи. Читал какие-то объяснения по ООП в С++ но там ещё хуже описывается чем в документации по mql5. Нетерпеливых прошу не встревать, я буду много переспрашивать. Готовый код без объяснений тоже не интересует, я хочу разобраться в этом, а не тупо повторить "Делай с нами, делай как мы..."

Ближайшая к понятию "Класс" сущность - это структура. А структура - это связанный набор данных. Т.е. это группа разнородных переменных, которые по смыслу связаны друг с другом. В классе же к этому ещё добавляются методы, которыми можно этими данными управлять. Ближайший аналог "Метода" - это функция. Т.е. Класс - это структура с набором встроенных в неё функций, с помощью которых можно управлять и формировать данные, которые находятся внутри неё. Методов может быть несколько, для разных ситуаций и вариантов формирования данных внутри объекта класса. Для вашего случая понадобится три метода, которые будут внутри класса формировать данные соответствующим образом для каждой ситуации.
В Классе обязательно должен быть "конструктор по-умолчанию". Эта вещь вызывается при создании нового объекта класса с помощью оператора new. Конструктор по-умолчанию я бы сравнил с функцией OnInit в MQL-программе.
Деструктор - это, если продолжать аналогии, аналог функции OnDeinit.
"Убивать" объект сразу после того, как он был создан и сделал своё дело совсем не обязательно. "Убить" созданные объекты можно в функции OnDeinit по завершению MQL-программы, а пока программа работает, все объекты могут находиться в памяти и к ним можно обращаться.
 
Koldun Zloy:

Функцию тоже можно вызывать и из индикатора и из советника.

Так в этом-то я не сомневаюсь. Я хотел приобщиться к модным способам программирования, а вы мне такие советы.))) Так ведь и вообще можно отказаться от ООП. И так я не понимаю необходимости этих прибамбасов, а тут ещё вы отговариваете.:)))

 
Alexey Viktorov:

Так в этом-то я не сомневаюсь. Я хотел приобщиться к модным способам программирования, а вы мне такие советы.))) Так ведь и вообще можно отказаться от ООП. И так я не понимаю необходимости этих прибамбасов, а тут ещё вы отговариваете.:)))

Если Вы используете классы непонятно для чего, то это не ООП.

И да, я Вам советую, пока не поймёте необходимости этих прибамбасов, не используйте их.

 
BlackTomcat:
Ближайшая к понятию "Класс" сущность - это структура. А структура - это связанный набор данных. Т.е. это группа разнородных переменных, которые по смыслу связаны друг с другом. В классе же к этому ещё добавляются методы, которыми можно этими данными управлять. Ближайший аналог "Метода" - это функция. Т.е. Класс - это структура с набором встроенных в неё функций, с помощью которых можно управлять и формировать данные, которые находятся внутри неё. Методов может быть несколько, для разных ситуаций и вариантов формирования данных внутри объекта класса. Для вашего случая понадобится три метода, которые будут внутри класса формировать данные соответствующим образом для каждой ситуации.
В Классе обязательно должен быть "конструктор по-умолчанию". Эта вещь вызывается при создании нового объекта класса с помощью оператора new. Конструктор по-умолчанию я бы сравнил с функцией OnInit в MQL-программе.
Деструктор - это, если продолжать аналогии, аналог функции OnDeinit.
"Убивать" объект сразу после того, как он был создан и сделал своё дело совсем не обязательно. "Убить" созданные объекты можно в функции OnDeinit по завершению MQL-программы, а пока программа работает, все объекты могут находиться в памяти и к ним можно обращаться.

Так вот именно от трёх аналогичных методов я и пытаюсь уйти. Ведь они почти одинаковы. Получают массив событий календаря и отсеяв ненужные записи предоставляют массив для дальнейшей обработки.

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