"Модульный" подход к созданию советника - страница 3

[[Удален]]

Давно делаю советники модульными. Из двух частей. Собственно советник - он всегда один и тот же. А сигнальная часть каждый раз разная. Общаются через глобальные переменные терминала - Global Variable Set/Get. Очень удобно

[Vitalii Ananev]

У меня все советники состоят из модулей. В одном модуле содержится класс в котором реализованы все необходимые торговые функции (открытие  позиций, модификация, и прочие на все случаи жизни функции). В основной части самого советника только алгоритм  самой торговой системы т.е. условия открытия(закрытия, модификации и т.п.) позиций. По этому основная часть советника занимает не очень много строк и упрощается отладка самой торговой системы.  

[Vladislav Alexandrov]

Товарищи LRA и Vitalii Ananev, спасибо Вам. Мне именно и нужно, что бы сигнальная часть менялась, а все остальное оставалось прежним. Буду пробовать это реализовать в будущем.

[Sergey Basov]

Vladislav Alexandrov:

Вот спасибо за такой ответ. Самый точный и исчерпывающий, характеризующий принцип использования для программиста :)

))

Если серьёзно, то в правильном направлении мыслите.

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

Я так примерно и сделал несколько лет назад, будучи в то время совсем ещё далёким от программирования. За пару месяцев написал универсальный шаблон советника из набора mq4 (главный файл советника) + несколько mqh (около 15 функций, на все случаи жизни, как тогда мне казалось). Для каждого нового советника (и проверки новой идеи) править нужно было обычно 2 файла mqh: файл с входными параметрами и файл с критериями входа, иногда ещё файл с критериями выхода.

Сейчас уже много чего переосмысливаю конечно, но тот шаблон и сейчас прекрасно работает, хоть и устарел.

В общем, если будете работать с одним программистом или самостоятельно программировать, то облегчит работу и ему и Вам. Другому программисту (исполнителю) скорее всего будет проще использовать свои наработки и шаблоны, чем разбираться с чужими, т.е. возможно усложнит.

Надеюсь, что не запутал совсем ))

[Vladislav Alexandrov]

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

[Aleksey Vyazmikin]

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

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

Только так, видя что происходит внутри кода, можно не будучи программистом выполнить проверку работы.

Кстати, подключить/заменить индикатор очень просто.

[Sergey Genikhov]

Sergey Basov:

В общем случае не облегчит и не усложнит, работы для другого исполнителя не убавится (для одного тоже).

Представьте, что в файле *.mq4 вместо строки, где написано "#include <*.mqh>" просто будет весь текст из того файла *.mqh.

Вот и вся разница между одним файлом mq4 и набором файлов mq4 + mqh, в общем то.

Так писать реально , но придется учитывать много нюансов, из за последовательности инклюдов, нахождении различных глобальных переменных или  input  переменных , вдруг они будут нужны в нескольких файлах. Нашел недавно одну статью про несколько другую модульность, тож будет полезна. https://www.mql5.com/ru/articles/3133

[Konstantin Nikitin]

По поводу input в классах все довольно просто решается.

// Menu.mqh
input   int     Variable        = 1,
        int     Variable2       = 123;
input   string  Variable3       = "";
input   double  Variable4       = 0.01;

Один вариант

class CMyClass
{
private:
        int     _Variable,
                _Variable2;
        string  _Variable3;
        double  _Variable4;
public:
        CMyClass();
};
CMyClass::CMyClass() :
        _Variable(  Variable  ),
        _Variable2( Variable2 ),
        _Variable3( Variable3 ),
        _Variable4( Variable4 )
{
        /* work */
}

Второй вариант

class CMyClass
{
private:
        int     _Variable,
                _Variable2;
        string  _Variable3;
        double  _Variable4;
public:
        CMyClass(){};

        void setVariable( const int    value){ _Variable  = value; }
        void setVariable2(const int    value){ _Variable2 = value; }
        void setVariable3(const string value){ _Variable3 = value; }
        void setVariable4(const double value){ _Variable4 = value; }
};

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

[Georgiy Merts]

Vladislav Alexandrov:
По поводу работы с разными программистами. Есть у меня советник, который писал один человек, а дорабатывали несколько других. Берутся, разбираются. Так что я думаю это небольшая проблема. Тем более до заключения соглашения о работе, в обсуждении, я сразу выкладываю претенденту все файлы что есть, что бы он оценил свои силы и написал точную сумму, сроки по итогам.

Зависит от сложности кода.

Предложи им разобраться в коде fxsaber'a - уверен, они даже за деньги не согласятся, а ведь fxsaber пишет очень даже интересный и нужный код (одна библиотека совместимости чего стоит).

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

В данном случае - задачи существенно различны - добавить некоторые возможности в советник, написанный другим человеком, и дорабатывать целую систему программных модулей. Использовать-то такую библиотеку - вполне приемлемо (когда она уже написана, и отлажена). А вот вносить в нее изменения - на это пойдет далеко не любой.

[Vladislav Alexandrov]

Aleksey Vyazmikin:

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

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

Только так, видя что происходит внутри кода, можно не будучи программистом выполнить проверку работы.

Кстати, подключить/заменить индикатор очень просто.

По поводу проверки работы Ваши идеи мне нравятся. Я планировал с каждым таким файлом  заказывать простенького советника для проверки всех функций. А вообще, пока мне это представляется так: есть модуль советника/стратегии, он выдаёт только сигнал (этот модуль меняется), а уже mqh файл, который как бы включается от сигнала, открывает ордер и сопровождает его (никаких закрытий по сигналам индикатора). Т. е. больше к ордеру модуль стратегии отношения не имеет. Не знаю, делать один файл для ордеров buy, sell или два, свой для buy, свой для sell. Как мне кажется это упростит работу по открытию разнонаправленных ордеров, упростит ссылание на файл и разборку какого направления открывать ордер. Пока формулирую, думаю. Всем спасибо за ответы/советы.