更少的代码，更多的行动......写一个EA - 页 2

新评论
 
Maxim Kuznetsov:

用例风格从根本上说是程序性的，因为它是最常见的。潜在的用户（新手程序员）以这种方式写作。

我的意思是，你的风格在本质上是程序性的。也就是说，它的内部和外部都是程序化的，并由此产生了各种问题。在用户层面，作为一个原则问题，你不能披露实施细节。而你的代码中在用户层面上有一个非常具体的事情在进行。

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函数实现的调用，等等，等等。也就是说，不是OOP，不是FP，而是这种消光的程序化编程。而作为蛋糕上的樱桃：Ea.Symbol，即正式的，它仍然是OOP。

 
Maxim Kuznetsov:

我将尝试（或将尝试，如果有兴趣的话）为EA做一个基础。

其结果将与主题中提到的所有那些人一样毫无用处（对大多数人来说）。

因为你马上就想用自己的方式来写，而不是写好。就像所有提到的那些作者一样。

 
Vasiliy Sokolov:

我的意思是，你的风格在本质上是程序性的。也就是说，它在内部和外部都是程序化的，并有随之而来的所有问题。在用户层面，作为一个原则问题，不能披露实施的细节。而你的代码中在用户层面上有一个非常具体的事情在进行。

有条件的编译宏，调用特定的MA函数实现，等等，等等。也就是说，不是OOP，不是FP，而是这种消光的程序化编程。而作为蛋糕上的樱桃：Ea.Symbol，即正式它仍然是OOP。

再一次，用例是从假定的潜在用户的角度来写的。

但在足够的程度上，能够在不触及用例本身的情况下进行库。

我们必须使用条件编译，因为4和5都在论坛中。

 
Maxim Kuznetsov:

再一次，使用案例是从假定的潜在用户的角度来写的。

换句话说：哪里有程序性风格的要求来插入调用特定的平台依赖函数，如iMA(...)？

Maxim Kuznetsov:

但要有足够的数量，使人们能够在不触及用例本身的情况下启动图书馆。

当用例中充满了对平台相关函数的具体调用时，我们如何能做到这一点？

Maxim Kuznetsov:

你必须使用条件性编译，因为论坛里有4和5两种。

所以用户案例级别的 "通用代码 "甚至不能独立于平台？

 
Maxim Kuznetsov:

...

如果我们谈论的是用户案例--第一条戒律：在这个层面上没有具体的实现。但在用户案例层面，你已经完全依赖于：1）平台，2）终端的API。也就是说，拟议的实施方案与所述的概念完全不一致。

 
Vasiliy Sokolov:

如果我们谈论的是用户案例--第一条戒律：在这个层面上没有具体的实现。在用户案例层面，你已经完全依赖：1）平台，2）终端API。也就是说，建议的实现方式完全不符合所述的概念。

一般来说，开发人员用MQL编写，对于交易终端 MT4、MT5的API :-) 因此，使用API终端是正常的。

用例应该展示/做该地区的典型事情。不仅仅是添加几个数字，而是要有一个用户可以理解的目的，也就是我们想要实现的目的。专家顾问的最小可能目的是交易：-）我能想到的最简单的专家顾问是在交叉平均线上交易。源帖中给出了完整的内容。

顺便说一句，它是有效的。此时此刻，我正在编写/调试数据，而不是交易函数存根和复选标记的绘制。只要有数据的部分，虽然粗糙，但准备好讨论--我就会把它贴出来。

 
Maxim Kuznetsov:

你一般用MQL和MT4,MT5交易终端 的API来写:-)所以提到API终端是正常的。

用例应该展示/做该领域的典型事情。不要只是添加几个数字，而是要有一个用户可以理解的目标，即我们想要实现的目标。专家顾问的最小可能目的是交易 :-) 我能想到的最简单的专家顾问是在交叉平均线上交易。它的全文见于源帖

顺便说一下它的作用。目前，我正在编写/调试数据，而不是交易函数和绘制刻度线:-)。只要有数据的部分，虽然是原始的，但将为讨论做好准备--我也会把它贴出来。

你写得很正确。但用户对这样的伪代码理解得更透彻。

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

另一件事是，要让它以这种形式（程序性的，我注意到）工作是非常困难的，但它仍然是可能的。这就是人们应该努力实现的目标--使用户级指令尽可能地简单和抽象。但在你的代码中，用户必须指定条件编译宏，计算平均数的特定函数和其他技术细节，而他根本无法处理。

 
Vasiliy Sokolov:

重新表述一下：程序化风格哪里有要求插入平台特定的函数调用，如iMA(...)？

如果用例中充斥着特定平台的函数调用，那么如何不可触及？

所以用户案例级别的 "通用代码 "甚至不能独立于平台？

4/5个平台有不同的API，这只是碰巧。

我不是在为所有东西写另一层兼容性，也不是在写一个通用库。尽管我不愿意 :-)

仅仅是EA的基础。

 
Vasiliy Sokolov:

嗯，你写得很对。但用户对这样的伪代码理解得更透彻。

另一点是，以这种特殊的形式（程序性的，我注意到了）使其发挥作用要难得多，但还是有可能的。这就是人们应该努力实现的目标--使用户级指令尽可能地简单和抽象。但在你的代码中，用户需要指定条件编译宏，计算平均数的特定函数和其他他根本无法处理的技术细节。

原则上，你可以在GetData OnCrossSignal里面使用一个像你所引用的条目。有可能，你甚至可以编写脚本 :-)但一切都来得及......数据处理是作为一个电子表格建立的。

 
Maxim Kuznetsov:

4/5的平台有不同的API，这就是它的方式。

我不是在为所有东西写另一个兼容层，也不是在写一个通用库。尽管我不愿意 :-)

仅仅是EA的基础。

看看Artem的代码。他的代码有一个单一的API，这与目标平台无关。这就是为什么 "它的工作方式 "的论点听起来很奇怪。

12345678910
新评论