Обсуждение статьи "Разрабатываем мультивалютный советник (Часть 1): Совместная работа нескольких торговых стратегий" - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не помешает - 100%. Просто лишняя сущность получилась. В ООП же архитектурно идет принцип от общего к частному. Вы общий (базовый класс) сделали "частным". Хотя все, что там вызывается - CStrategy::Tick().
Тут я придерживался такого подхода. Предположим, мы можем создаем линейную иерархию Базовый класс -> Наследник1 -> Наследник2 -> Наследник3. Классы наследников постепенно усложняют свой родительский класс, но нигде нет разветвлений дерева наследования, то есть у у всех классов есть только один следующий наследник. Тогда если мы будем создавать реальные объекты только нескольких классов, которые будут наследниками Наследника3, и при этом весь код родительских классов достаточно компактен, то сделаем сразу базовый класс, включающей содержание первых трех наследников.
В этой статье в базовом классе действительно, по большому счёту, только CStrategy::Tick() и есть. Но дальше в него планируется еще добавить общего кода для всех стратегий.
Похоже, ошибка компилятора, что не ругается на эту сигнатуру метода при таком вызове.
Тут, как я понял, это связано с тем, что указатели в MQL5 это не то же самое, что указатели в С++. Поэтому и такой вариант подходит.
Наследуетесь от CObject.
При этом не используете это.
Заметил, что это довольно распространенная практика - наследование от CObject.
Не совсем понял мысль, что именно не используется, хотя могло бы?
Наследование от CObject сделано только ради последующего использования Save() и Load()
Не совсем понял мысль, что именно не используется, хотя могло бы?
Приведу код целиком.
Кратко говоря, этот класс предназначен для формирования и работы со списками, включая возможную сортировку.
Наследование от CObject сделано только ради последующего использования Save() и Load()
Из пушки по воробьям. Почему не добавить эти два виртуальных метода в CStrategy?
Из пушки по воробьям. Почему не добавить эти два виртуальных метода в CStrategy?
Да, согласен. Добавлю методы сохранения к CStrategy и остальным базовым классам вместо наследования от CObject
Вы из классического (input + без ООП) SimpleVolumes.mq5 делаете ООП-преобразование в SimpleVolumesStartegy.mqh.
Почему не сделали SimpleVolumes.mq5 через #include SimpleVolumesStartegy.mqh ?
хорошо видна громоздкость со входными из-за ООП. Хорошо бы убрать ее.
Закамуфлировали.
Раз уж стали показывать работу портфеля ТС, то и с загрузкой портфеля (входные) хорошо бы грамотно разобраться.
Вы из классического (input + без ООП) SimpleVolumes.mq5 делаете ООП-преобразование в SimpleVolumesStartegy.mqh.
Почему не сделали SimpleVolumes.mq5 через #include SimpleVolumesStartegy.mqh ?
Потому что хотелось продемонстрировать процесс перехода от обычного советника (input + без ООП), который написан без прицела на его использование в параллельном режиме с разными настройками (это роль SimpleVolumes.mq5) к уже другому советнику, в котором это параллельное использование можно сделать (это роль SimpleVolumesExpert.mq5). Для этого понадобилось ООП-преобразование в SimpleVolumesStartegy.mqh.
Раз уж стали показывать работу портфеля ТС, то и с загрузкой портфеля (входные) хорошо бы грамотно разобраться.
Обязательно будем разбираться в следующих частях. Там еще много с чем надо разбираться, поэтому всё сразу изложить и не получилось.
Я очень благодарен за все замечания, поскольку сейчас как раз для них самое время - для статей я занимаюсь переделкой по сути почти с нуля своего ранее написанного кода за последние несколько лет, который не особо чистился и оптимизировался без особой необходимости. Так то свою работу код выполняет, но есть места, которые уже не нужны, но остались не вычищены, а так же места, где, как теперь видно, можно упростить код или вообще применить другой архитектурный подход.
В идеале хотелось бы дойти до уровня полной автоматизации оптимизации и подбора хорошего портфеля параметров стратегий, используя ваши прекрасные библиотеки.
Потому что хотелось продемонстрировать процесс перехода от обычного советника (input + без ООП)