Вопросы по Мастеру MQL5 и стандартной библиотеке торговых классов - страница 12

[Victor Kirillin]

Reshetov:

Пока только одно единственное, которое позволяет устранить вышеуказанные недостатки:

Открыть доступ к чтению значений возвращаемых методом Direction() сигнального модуля из модулей сопровождения позиций и управления капиталом и риском.

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

Для этого нужно

1. Выделить в классах CExpertMoney и CExpertTrailing поля для хранения экземпляра класса CExpertSignal, т.е. основного  модуля сигналов. 
2. Этот самый экземпляр класса CExpertSignal, т.е. сигнальный модуль необходимо передать модулям сопровождения позиций и управления капиталом и риском во время инициализации экземпляров классов этих самых модулей и сохранить его в полях указанных в п.1. Естественно, что перед этим необходимо также проверить (убедиться), что экземпляр класса сигнального модуля уже существует, т.е. был создан.
   
3. Создать в классах CExpertMoney и CExpertTrailing дополнительные методы с идентификатором double getMainSingnal(), которые обращаются к экземпляру класса модуля сигналов, хранимого в соответствующих полях данных классов и возвращает в качестве результата, результат метода Direction()  модуля сигналов.

Почти всё понятно. Единственное, что хотелось бы уяснить: "почему это Ваше желание видеть сигнал на уровне ММ и трейлинга должно быть реализовано на уровне базовых классов?".

Я думаю это будет нехорошо (т.е. плохо). Алгоритм не типовой (с моей точки зрения). Как я понял, у Вас свои модули ММ и трейлинга (со своими алгоритмами, привязанными к сигналу).

Вот и заложите в них соответствующие 1.,2.,3.

[Yury Reshetov]

uncleVic:

Почти всё понятно. Единственное, что хотелось бы уяснить: "почему это Ваше желание видеть сигнал на уровне ММ и трейлинга должно быть реализовано на уровне базовых классов?".

Я думаю это будет нехорошо (т.е. плохо). Алгоритм не типовой (с моей точки зрения). Как я понял, у Вас свои модули ММ и трейлинга (со своими алгоритмами, привязанными к сигналу).

Вот и заложите в них соответствующие 1.,2.,3.

Дело в том, что Мастер в качестве базового берет класс CEхpert. А следовательно, я никоим образом не смогу переопределить в модулях, которые я создаю необходимые функции, т.к. они с этим самым базовым классом  CEхpert уже несовместимы изначально, поскольку доступа к экземпляру класса модуля сигналов они не имеют.

Ведь экземпляр класса модуля сигналов хранится лишь в поле класса СExpert  в файле Expert.mqh строка 67

CExpertSignal    *m_signal;                   // trading signals object

и это поле не расшарено (недоступно) для других классов и создаваемых на их основе модулей.

По этой самой причине я никак не могу переопределить классы CExpertMoney и CExpertTrailing, чтобы они были совместимы с мастером.

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

Зри в корень (с) Козьма Прутков "Афоризмы"

[Yury Reshetov]

Я разобрался, как передать из сигнального модуля в модули сопровождения позиций и управления капиталом и риском торговые сигналы без передачи экземпляров класса CExpertSignal.

Добавим по две строчки в классы CExpertMoney и CExpertTrailing:

  double m_signaldirection; // Direction from signals module
 
  void              setSignalDirection(double value)  { m_signaldirection = value; }
  

Для файла ExpertMoney.mqh:

class CExpertMoney : public CExpertBase
  {
protected:
   //--- Direction from signals module  
   double m_signaldirection;
   //--- input parameters
   double            m_percent;

public:
                     CExpertMoney();
   void              setSignalDirection(double value) { m_signaldirection = value; }        
   //--- methods of setting adjustable parameters
   void              Percent(double percent)    { m_percent=percent; }
   //--- method of verification of settings
   virtual bool      ValidationSettings();
   //---
   virtual double    CheckOpenLong(double price,double sl);
   virtual double    CheckOpenShort(double price,double sl);
   virtual double    CheckReverse(CPositionInfo* position,double sl);
   virtual double    CheckClose(CPositionInfo* position);
  };

Для файла ExpertTrailing.mqh:

class CExpertTrailing : public CExpertBase
  {
protected:
   
    //--- Direction from signals module
   double m_signaldirection;
public:
   //---
   void              setSignalDirection(double value) { m_signaldirection = value; }        
   virtual bool      CheckTrailingStopLong(CPositionInfo *position,double& sl,double& tp)  { return(false); }
   virtual bool      CheckTrailingStopShort(CPositionInfo *position,double& sl,double& tp) { return(false); }
  };

Тем самым мы определили необходимые поля и методы для передачи торговых сигналов. Теперь нам нужно передавать эти самые торговые сигналы в классы модулей. Это будем делать в файле Expert.mqh, т.е. для класса CExpert

Для передачи торговых сигналов в класс сопровождения позиций мы пропишем одну строчку:

m_trailing.setSignalDirection(m_signal.Direction());

и вставим ее в самом начале метода, который вызывается перед каждым трейлингом, т.е. CheckTrailingStop():

bool CExpert::CheckTrailingStop()
  {
//--- Set signal direction to trailing stops module
   m_trailing.setSignalDirection(m_signal.Direction()); 
//--- position must be selected before call
   if(m_position.PositionType()==POSITION_TYPE_BUY)
     {
      //--- check the possibility of modifying the long position
      if(CheckTrailingStopLong()) return(true);
     }
   else
     {
      //--- check the possibility of modifying the short position
      if(CheckTrailingStopShort()) return(true);
     }
//--- return without operations
   return(false);
  }

Для передачи торговых сигналов в класс управления капиталом и риском мы пропишем одну строчку:

m_money.setSignalDirection(m_signal.Direction());

и вставим ее в самом начале метода, который вызывается перед каждым открытием позиций, т.е. CheckOpen():

bool CExpert::CheckOpen()
  {
//--- set signal direction to money management module
   m_money.setSignalDirection(m_signal.Direction());
   if(CheckOpenLong())  return(true);
   if(CheckOpenShort()) return(true);
//--- return without operations
   return(false);
  }

И все, проблема решена.

Теперь можно в модулях сопровождения позиций и управления капиталом и риском получить текущее значение торговых сигналов, обратившись к значению поля: m_signaldirection. Останется только прописать в документации о наличии новых полей и методов в классах CExpertMoney и CExpertTrailing и добавить измененные файлы в апдейты.

[Victor Kirillin]

Вот файлы. В эксперте строки 100 и 123 написаны руками.

Если ещё будут вопросы, обращайтесь.

[Yury Reshetov]

uncleVic:

Вот файлы. В эксперте строки 100 и 123 написаны руками.

Если ещё будут вопросы, обращайтесь.

Блин да что за люди эти разработчики? Когда уже они начнут прислушиваться к тому что необходимо трейдерам, у которых уже есть опыт создания торговых систем, а не выдумывать собственное видение построения торговых систем, практически непригодных для конечных пользователей из-за того, что требуется ручная доводка исходников? Сколько можно объяснять, что я могу руками залезть и поправить, да и то придется долго разбираться что и к чему, хотя я знаком с программированием. А конечный пользователь, вряд ли полезет в код, т.к. он в программировании не разбирается. Вы же сами декларировали, цитирую:

"Знание языков программирования теперь не является обязательным условием для создания торговых роботов." см. https://www.mql5.com/ru/articles/240

"Уже в первой версия Мастера MQL5 была возможность быстро создать готовый к использованию эксперт как совокупность простых модулей в виде исходного кода на языке MQL5. Для этого даже не требовалось знания языка MQL5, достаточно было прочитать статью "Собери свой торговый советник в Мастере MQL5". см. https://www.mql5.com/ru/articles/275

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

Например, напишу я свой модуль управления капиталом и риском, который должен открывать позицию в соответствии с уровнем торгового сигнала, выдаваемого модулем написанным другим разработчиком модулей. В результате чего получится что мой модуль уже несовместим с мастером. Как объяснять пользователям, что нужно лезть куда-то там в код и вставлять какие-то строки, чтобы модуль стал работать? Ведь разработчики модулей должны создавать модули, а мастер должен их автоматически объединять в одну согласованную систему, чтобы модули, как минимум не конфликтовали друг с другом и были полностью совместимы друг с другом. А у Вас получается, что мастер этим не занимается, т.к. после него нужно лезть в код и все переделывать вручную.

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

Что за идеология у Вашей компании, с одной стороны декларировать полную автоматизацию, а когда доходит до дела, то предлагают после так называемой "автоматизации" лезть в код и ручками все переделывать?

В общем, как я понял, все это бесполезно объяснять. И нечему удивляться, что трейдеры не хотят переходить на МТ5, потому что платформа сырая и делается не для удобства автотрейдинга, а для удобства разработчиков этой самой платфомы. И если пользователь досконально не научится программированию, то ему лучше держаться как можно подальше от автотрейдинга.

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

[Renat Fatkhullin]

Боюсь, Вы или в плену максимализма или просто не понимаете пределов применимости инструментов.

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

[Yury Reshetov]

Renat:
Боюсь, Вы или в плену максимализма или просто не понимаете пределов применимости инструментов.

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

Да в общем-то я на работу не напрашивался, т.е. ради заработка, а меня вполне устраивало сотрудничество на общественных началах. Как и где мне зарабатывать, это я сам решаю.

Ну не будет и не надо. Наше дело предложить, Ваше право - отказаться. Как говориться: хозяин - барин.

Если Ваша компания уже все осознала и даже научила создавать чайников так называемые "готовые" советники, причем, не суть что они пригодны лишь для демонстрации Wizard-а, но мало пригодны для автотрейдинга, поскольку даже на исторических данных кривая эквити выглядит страшноватенько, т.к. модульность предусмотрена, а вот согласованность модулей для полноценной торговой системы отсутствует, то не буду Вам мешать и дальше продвигать в массы Ваше корпоративное видение того, как нужно и должно создавать торговые системы.

Успехов!

[Mykola Demko]

Reshetov:
...

Например, напишу я свой модуль управления капиталом и риском, который должен открывать позицию в соответствии с уровнем торгового сигнала, выдаваемого модулем написанным другим разработчиком модулей. В результате чего получится что мой модуль уже несовместим с мастером. Как объяснять пользователям, что нужно лезть куда-то там в код и вставлять какие-то строки, чтобы модуль стал работать? Ведь разработчики модулей должны создавать модули, а мастер должен их автоматически объединять в одну согласованную систему, чтобы модули, как минимум не конфликтовали друг с другом и были полностью совместимы друг с другом. А у Вас получается, что мастер этим не занимается, т.к. после него нужно лезть в код и все переделывать вручную.

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

...

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

Почитайте на досуге книгу Стива Макконелла "Совершенный код".

Проще говоря представьте Мастер как завод для производства перчаток, есть пятипалый штамп для правой и для левой руки, но тут появляется небольшой заказ на шестипалые перчатки. Ведь есть же и такие люди. Но вместо того чтоб изготовить штамп для них (который сделает партию и будет лежать до поры) вы предлагаете внести изменения в пятипалый штамп, сделав сдвигающийся палец. Вроде бы как универсально и всё здорово, но прочность штампа фигарящего миллоны пятипалых перчаток будет ослаблена в угоду универсальности (ради малюсенькой надобности изредка выпускать шестипалые). А потом появится заказ на партию из 300 четырёхпалых, и снова кроши хорошо зарекомендовавший себя, надёжный шаблон.

Вам же выше сказали:

"почему это Ваше желание видеть сигнал на уровне ММ и трейлинга должно быть реализовано на уровне базовых классов?".

Я думаю это будет нехорошо (т.е. плохо). Алгоритм не типовой (с моей точки зрения). Как я понял, у Вас свои модули ММ и трейлинга (со своими алгоритмами, привязанными к сигналу).

Вместо изменений в стандартную библу, лучше сделать наработки по её расширению (через наследование). Тогда это будет действительно интересно.

ЗЫ Более того чтоб людям не приходилось сталкиваться с тонкостями кода (о чём вы писали выше), можете готовые модули завернуть в библу и шароварно залить в маркет, тогда просто подключил модуль от Решетова и жми кнопку [качать бабло]

[Yury Reshetov]

Urain:

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

Почитайте на досуге книгу Стива Макконелла "Совершенный код".

Проще говоря представьте Мастер как завод для производства перчаток, есть пятипалый штамп для правой и для левой руки, но тут появляется небольшой заказ на шестипалые перчатки. Ведь есть же и такие люди. Но вместо того чтоб изготовить штамп для них (который сделает партию и будет лежать до поры) вы предлагаете внести изменения в пятипалый штамп, сделав сдвигающийся палец. Вроде бы как универсально и всё здорово, но прочность штампа фигарящего миллоны пятипалых перчаток будет ослаблена в угоду универсальности (ради малюсенькой надобности изредка выпускать шестипалые). А потом появится заказ на партию из 300 четырёхпалых, и снова кроши хорошо зарекомендовавший себя, надёжный шаблон.

Вам же выше сказали:

Вместо изменений в стандартную библу, лучше сделать наработки по её расширению (через наследование). Тогда это будет действительно интересно.

Да сколько можно уже говорить, что нельзя унаследовать то, что в родительских классах недоступно? Когда Вы уже наконец ознакомитесь с книгой того же самомого Стива Макконелла "Совершенный код"?

1. Мой подход не нарушает принципов инкапсуляции, т.к. в том варианте, который я предложил, все лишнее скрыто, а модулям выдается лишь торговый сигнал в виде значения типа double и только в режиме чтения. В отличие от некоторых я книги по OOП не только почитал, но и внимательно изучал.
2. Я не предлагал создавать шестипалые перчатки к шаблонным, т.е. присобачивать шестые пальцы в виде дополнительных модулей, а всего лишь предложил согласовать все уже существующие модули сигналами из модуля сигналов, который собственно и является основным для торговых систем, т.к. вся система должна работать по его команде. Это вы предложили модульность, т.е. перчатки со сменными пальцами. Но поскольку все Вами было сделано так, что правая рука не ведает о том, что вытворяет левая, т.е. остальные модули не могут получить информацию от сигнального модуля и синхронизировать свои действия с ним, то Ваши перчатки получаются с пальцами (модулями) разных размеров, когда надев на руку Вашу перчатку, пользователь видит, что один из ее пальцев мал и в него ничего не вмещается, а другой велик и лишнее торчит.

Например, трейлинг-стоп выполняется по какой-то своей отдельно сигнальной системе, написанной сторонним разработчиком модуля, скажем, по мувингу или параболику, сигналы которых в некоторые моменты противоречат тому что выдает модуль сигналов и вся торговая система начинает действовать вразнобой. Модуль управления капиталом и риском тоже телепатически не может догадаться, что торговый сигнал слабый и ему уже пора сократить объемы открываемых позиций и тоже действует по каким-то независимым от сигнального модуля правилам, т.е. один просит притормозить на поворотах, а другой жмет на газ. И вся торговая система созданная с помощью Вашего так называемого мастера получается как в басне дедушки Крылова под названием "Лебедь, рак и щука". Не больше и не меньше. И эту самую басенную идеологию сборки бесшабашных советников, Ваша компания пытается навязать нам для автотрейдинга. А оно нам нужно?

В результате чего получаются торговые системы с вот такими графиками эквити и баланса, которыми можно только пугать и трейдеров и инвесторов см. https://www.mql5.com/ru/code/833

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

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

Поэтому вести дальнейшие дискуссии бессмысленно. Оставайтесь при своем мнении и действуйте как Вам удобнее. Надоело уже и толку нет, т.к. разработчикам платформы до лампочки, ведь они поделки не для собственного пользования ляпают и смогут ли этими самые поделки применить пользователи платформы для автотрейдинга, разработчиков уже нисколько не волнует. Сытый голодного не разумеет.

[Mykola Demko]

Reshetov:
...

Решетов, мне даже влом читать эти твои портянки с эмоциями. Хочешь поспорить аргументируй.

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

Мастер создаёт шаблон который уже работает, и человек который вообще не умеет программировать может воспользоваться как есть. Если же разбираешься в кодировании то не сложно изменить на то как хочется. Достаточно просто один раз вникнуть откуда чего берётся и куда чего девается в стандартной библе. К тому же стандартную библу можно ещё использовать и как образец, и просто копипастить в свой код те участки которые понравились.