Меньше кода, больше прока.. пишем советник - страница 2

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

в use-case стиль принципиально процедурный, как самый распространённый. Потенциальные пользователи (начинающие программисты) именно так пишут. 

Я имею ввиду что Ваш стиль процедурный по сути. Т.е. он процедурный и внутри и снаружи, со всеми вытекающими отсюда проблемами. На юзер-уровне принципиально нельзя раскрывать деталей реализации. А у Вас уже в коде юзер-уровня идет предельная конкретика:

double GetData(EA *ea,int id,int shift,double &data[])
{
#ifdef __MQL4__
   // для 4-ки всё просто - по идентификаторам серии и бара получить данные
   switch ((ENUM_SERIES)id) {
      case FAST_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,FAST_MA_PERIOD,0,FAST_MA_METHOD,FAST_MA_PRICE,shift);
      case SLOW_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,SLOW_MA_PERIOD,0,SLOW_MA_METHOD,SLOW_MA_PRICE,shift);
   }
   return EMPTY_VALUE;
#else
   ...
#endif
}

Макросы условной компиляции, вызовы конкретных реализаций функции MA, ну и т.д. и т.п. Т.е. не ООП, не ФП, а такое матерое процедурное программирование. Ну и как вишенка на торте: ea.Symbol т.е. формально все же ООП. 

 
Maxim Kuznetsov:

Попробую (или попробуем, если будут заинтересованные) сделать основу для советников.

получится такая же бесполезная (для большинства) шляпа как и все упомянутые в ветке.

потому что вы сразу пытаетесь писать не хорошо, а по-своему. как и авторы всех упомянутых.

 
Vasiliy Sokolov:

Я имею ввиду что Ваш стиль процедурный по сути. Т.е. он процедурный и внутри и снаружи, со всеми вытекающими отсюда проблемами. На юзер-уровне принципиально нельзя раскрывать деталей реализации. А у Вас уже в коде юзер-уровня идет предельная конкретика:

Макросы условной компиляции, вызовы конкретных реализаций функции MA, ну и т.д. и т.п. Т.е. не ООП, не ФП, а такое матерое процедурное программирование. Ну и как вишенка на торте: ea.Symbol т.е. формально все же ООП. 

ещё раз - use-case написан с предополагаемой точки зрения потенциальных пользователей.

Но в достаточном объёме чтобы можно было приступать к библиотеке, не трогая больше сам use-case. 

Условную компиляцию приходится ставить, потому-что на форуме и 4-ка и 5-ка. 

 

 
Maxim Kuznetsov:

ещё раз - use-case написан с предополагаемой точки зрения потенциальных пользователей. 

Перефразирую: где у процедурного стиля требование вставлять вызовы конкретных платформозависимых функций вроде iMA(...)?

Maxim Kuznetsov:

Но в достаточном объёме чтобы можно было приступать к библиотеке, не трогая больше сам use-case.  

Как не трогая, если use-case пестрит конкретными вызовами платформо-зависимых функций?

Maxim Kuznetsov:

Условную компиляцию приходится ставить, потому-что на форуме и 4-ка и 5-ка.   

Т.е. "универсальный код" user-case уровня даже не может быть платформонезависимым?

 
Maxim Kuznetsov:

...

Если мы говорим о user-case - заповедь номер один: ни каких конкретных реализаций на этом уровне. У Вас же уже на уровне user-case полная зависимость от: 1) платформы, 2) API терминала. Т.е. предлагаемая реализация полностью не соответствует заявленной концепции.

 
Vasiliy Sokolov:

Если мы говорим о user-case - заповедь номер один: ни каких конкретных реализаций на этом уровне. У Вас же уже на уровне user-case полная зависимость от: 1) платформы, 2) API терминала. Т.е. предлагаемая реализация полностью не соответствует заявленной концепции.

тут в общем-то пишут на языке MQL и под API торговых терминалов MT4,MT5 :-) поэтому обращения к API терминала это нормально.  

use-case должен демонстрировать/делать типичные вещи для области. Не просто складывать пару чисел, а иметь цель понятную пользователю, ту которую хотим достигать.   Минимально-возможная цель советников - торговать :-)  Самый простой советник который могу придумать - торговать по пересечению средних. Он полностью приведён в  исходном посте

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

 

 
Maxim Kuznetsov:

тут в общем-то пишут на языке MQL и под API торговых терминалов MT4,MT5 :-) поэтому обращения к API терминала это нормально.  

use-case должен демонстрировать/делать типичные вещи для области. Не просто складывать пару чисел, а иметь цель понятную пользователю, ту которую хотим достигать.   Минимально-возможная цель советников - торговать :-)  Самый простой советник который могу придумать - торговать по пересечению средних. Он полностью приведён в  исходном посте

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

Ну так правильно все пишите. Но пользователю куда понятнее вот такой псевдокод:

if(SMA(Close, 12) > SMA(Close, 24))
   BUY();
else
   SELL();

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

 
Vasiliy Sokolov:

Перефразирую: где у процедурного стиля требование вставлять вызовы конкретных платформозависимых функций вроде iMA(...)?

Как не трогая, если use-case пестрит конкретными вызовами платформо-зависимых функций?

Т.е. "универсальный код" user-case уровня даже не может быть платформонезависимым?

платформы 4/5 имеют различный API, тут так сложилось.

Я не пишу ещё один слой совместимости для всего, или универсальную библиотеку. Как бы не хотелось :-)

только основа для советников. 

 
Vasiliy Sokolov:

Ну так правильно все пишите. Но пользователю куда понятнее вот такой псевдокод:

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

в приниципе внутри GetData OnCrossSignal можно будет использовать запись подобную приведённой вами. Потенциально можно будет даже скрипты писать :-) Но всему своё время...Работа с данными строится как элетронноя таблица.

 
Maxim Kuznetsov:

платформы 4/5 имеют различный API, тут так сложилось.

Я не пишу ещё один слой совместимости для всего, или универсальную библиотеку. Как бы не хотелось :-)

только основа для советников. 

Посмотрите на код Артема. У его кода один единственный API, который не зависит от целевой платформы. Поэтому довод что "так сложилось" слышать странно. 

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