Обсуждение статьи "Написание советника в MQL5 с использованием объектно-ориентированного подхода"

Новый комментарий
 

Опубликована статья Написание советника в MQL5 с использованием объектно-ориентированного подхода:

Эта статья посвящена использованию объектно-ориентированного подхода для создания советника, рассмотренного в статье "Пошаговое руководство по написанию советников для начинающих". Большинство людей думают, что это сложно, но могу вас заверить, что после прочтения этой статьи вы сможете написать свой собственный советник на основе объектно-ориентированного похода.

Автор: Samuel

 

В общем, неплохо, но слегка хромает следование лозунгу ООП, использованному в названии. Например, зачем стоплосс, тейк и цены вынесены вне класса? STP и TKP просятся в члены, нужен метод setSLTP; latest_price и уровни - считать внутри openBuy/openSell. Сами они написаны крайне нерационально - там желателно оставить только один if с вызовом MarginOK, а внутри неё добавить первой строкой проверку if(Chk_Margin == 0) return(true);

И еще мелочь. Зачем Chk_Margin объявлена int-ом, хотя по смыслу используется только как bool? Лучше описать минимальным достаточным типом, а то возникают вопросы при чтении исходника, что будет если вдруг Chk_Margin == 2, 3 и т.д.

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

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

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

 

 

конструкция вызывает недоумение

   if(Buy_Condition_1 && Buy_Condition_2 && Buy_Condition_3 && Buy_Condition_4)
     {
       return(true);
     }
     else
     {
       return(false);
     }
 
ortv:

конструкция вызывает недоумение

А чем именно она так вам не нравится? Конечно, в контексте кода я ее не видел...
 
Interesting:
А чем именно она так вам не нравится? Конечно, в контексте кода я ее не видел...

разве не так обычно пишут в таких случаях?

return(Buy_Condition_1 && Buy_Condition_2 && Buy_Condition_3 && Buy_Condition_4);
 
ortv:

разве не так обычно пишут в таких случаях?

Можно и так, если код воспроизведен точно и там нет больше ничего в обработке...
 

Немного не понял следующую часть кода:

// Скопируем цену закрытия предыдущего бара (бар 1) в соответствующую переменную эксперта
   Cexpert.setCloseprice(mrate[1].close);  // цена закрытия бара 1
//--- Проверка наличия позиции на покупку
   if (Cexpert.checkBuy()==true)
   {
      if (Buy_opened) 
         {
            Alert("У нас уже есть позиция на покупку!!!"); 
            return;    // Не добавляем к длинной позиции
         }
      double aprice = NormalizeDouble(latest_price.ask,_Digits);
      double stl    = NormalizeDouble(latest_price.ask - STP*_Point,_Digits);
      double tkp    = NormalizeDouble(latest_price.ask + TKP*_Point,_Digits);
      int    mdev   = 100;
      // размещаем ордер
      Cexpert.openBuy(ORDER_TYPE_BUY,Lot,aprice,stl,tkp,mdev);
   }
Если мы собираемся открывать позицию на покупку, то ориентироваться следует на цену latest_price.ask, но при выставлении стоплосса и тейкпрофита для такой позиции - на цену latest_price.bid. Правильно? Почему же тогда в тексте кода стоплосс и тейкпрофит выставляются исходя из цены ask? Это - опечатка или особенность конкретной стратегии (в отношении открытия позиции на продажу код имеет аналогичную конструкцию)?
 
Yedelkin:

Немного не понял следующую часть кода:

Если мы собираемся открывать позицию на покупку, то ориентироваться следует на цену latest_price.ask, но при выставлении стоплосса и тейкпрофита для такой позиции - на цену latest_price.bid. Правильно? Почему же тогда в тексте кода стоплосс и тейкпрофит выставляются исходя из цены ask? Это - опечатка или особенность конкретной стратегии (в отношении открытия позиции на продажу код имеет аналогичную конструкцию)?

Тут такая логика (скорей всего, я тоже ей обычно пользуюсь):

1. Цена открытия для Buy считается по Ask (и это верно);

Допустим мы открываемся по цене 1,27 по EURUSD

2. При открытии позиции мы получаем разницу равную спреду, для Buy это Ask-Bid (потенциальный убыток если закрыть по текущей цене);

Допусти что spred у нас равнен 5 пунктов. Таким образом Bid при открытии будет на 1,2695 (верно?)

3. Закрытие Long-ов у на происходит по цене Bid (и это вполне логично)

Таким образов когда Bid выйдет на 1,27 мы получаем БУ по позе (верно?)

4. Но нам то нужно еще и профита получить (пунктов 100 в стандартной котировки).

То есть TP у нас должно быть выше чем Open на 100 pips. В нашем случае это 1,28 (верно?)

При этом TP сработает если Bid (не Ask) достигнет этих самых 1,28...

5. SL же тоже нужно ставить (допустим он у нас 50 pips). Значит в нашем примере он будет располагаться на 1,2650 (50 pips ниже Open)

При каких условиях сработает SL?

По логике вещей он должен сработать тогда когда цена пройдет эти самые 50 пунктов против нас (то есть Ask в монет закрытия по SL должен по логике вещей быть на этих самых 1,2650).

Где же в таком случае должен быть Bid? А он в это время будет располагаться на 1,2645 (ведь Spred по условию у нас 5 pips)

Вспоминая о том что Long-и фиксируются

6. Давайте теперь посмотрим на то, что происходит на самом деле (для примера возьмем рыночное открытие лонга в MQL4)

//Взято из справки по OrderSend
ticket=OrderSend(Symbol(),OP_BUY,1,Ask,3,Bid-25*Point,Ask+25*Point);

Что мы тут видим

Цена открытия считается по ask, SL считается по Bid, а TP по Ask.

в нашем случае мы получим вот такой шаблон

OrderSend(Symbol(),OP_BUY,1,Open = Ask,3,SL = Bid-50*Point,TP Ask+100*Point);

Подставим сюда наши данные:

OrderSend(Symbol(),OP_BUY,1,1.2700,3,1.2695-50*Point,TP 1.2700+100*Point);

Что получается в итоге - Open = 1.2700 SL= 1.2645 TP 1.28

PS

Сравним с исходными данными:

Приказ - Open = 1.2700 SL= 1.2645 TP 1.28

модель - Open = 1.2700 SL= 1.2645 TP 1.28

 
Interesting:

Тут такая логика (скорей всего, я тоже ей обычно пользуюсь):

1. Цена открытия для Buy считается по Ask (и это верно);

Допустим мы открываемся по цене 1,27 по EURUSD

2. При открытии позиции мы получаем разницу равную спреду, для Buy это Ask-Bid (потенциальный убыток если закрыть по текущей цене);

Допусти что spred у нас равнен 5 пунктов. Таким образом Bid при открытии будет на 1,2695 (верно?)

 

5. SL же тоже нужно ставить (допустим он у нас 50 pips). Значит в нашем примере он будет располагаться на 1,2650 (50 pips ниже Open)

При каких условиях сработает SL?

По логике вещей он должен сработать тогда когда цена пройдет эти самые 50 пунктов против нас (то есть Ask в монет закрытия по SL должен по логике вещей быть на этих самых 1,2650).

Где же в таком случае должен быть Bid? А он в это время будет располагаться на 1,2645 (ведь Spred по условию у нас 5 pips)

Вспоминая о том что Long-и фиксируются

Если Bid при открытии будет на 1.2695, то 5 пунктов убытка мы уже имеем автоматически. Если при этом SL составляет по замыслу разработчика 50 pips, то до его срабатывания осталось пройти в неблагоприятном направлении ещё 45 pips. Т.е. при срабатывании стоплосса Bid должен быть не на 1.2645, а на 1.2650; а Ask, соответственно, - на 1.2655.
123
Новый комментарий
Причина обращения: