结构规则。 学习如何构建方案，探索可能性、错误、解决方案等。 - 页 10

新评论
 

我对国家编程并不陌生，自己也用了好几年。然而，在使用这个方法一段时间后，我决定放弃它，并在其基础上开发了一个更透明、更简单、更适合的交易模式。

仔细阅读这篇文章：自动编程是创建自动交易系统的新方法

然后仔细阅读这些关于它的评论。

然后非常、非常认真地思考文章中的一个难看的斑块，并思考它可能意味着什么。

如果在读完这些之后，你仍然会说："哇！国家编程太酷了！"- 那么，就指望它吧。

我想补充一点，状态编程的主要问题是产生大量无用模式的情况（见N列状态）。在国家编程中，每种模式都应单独描述自己的规则。让我们举例说明，假设我们处于购买模式。一切都很好，直到机器人决定再开一个位置。为什么不呢？退出旧仓的条件还没有达到，现在平仓还为时过早，而新的信号则不应该错过。而这里就是问题的开始，因为在新信号到达的时刻，机器人处于买入模式，而开立新仓的规则处于状态模式（等待和寻找新的进入信号）。现在在买入模式下，我们必须重新描述在状态模式下使用的相同的开仓规则。如果一个新的头寸在方向上是相反的（对冲）呢？这个位置已经打开，但该如何处理？毕竟，其管理逻辑是在卖出模式下描述的，而机器人是在买入模式下。我们可以简单地切换到卖出模式，但如何处理剩余的买入头寸？一般来说，在这种情况下，我们必须再写一个像BuyAndSell那样的无用模式。模式的冗余产生了另外一种情况：一个相同的动作由不同的代码部分来执行。总而言之，对于那些喜欢指数型编程混乱的人来说，这就是最好的。

 
C-4:
(fcplm)
 
C-4:

"这就是米哈伊奇"（C）......这也是我所暗示的。

TheXpert。
(fcplm)

不可能。

 
C-4:
我只是在想，如果MQL5支持多重继承，并且一个类可以声明抽象方法，那么就会开辟一条使用接口的途径，这对于大型项目来说是非常好的。

抽象方法没有被明确禁止（我经常使用替代符号）。

而多重继承将是一个巨大的优势。

 
A100:
抽象方法没有被明确禁止。

引用Rosh 的话：这对你锯木柴有什么帮助？

冯氏问答 ，坐拥四合院，对抽象方法和多重继承不屑一顾。

是否会有抽象方法并不重要，反正项目结构化的任务不会得到解决。

顺便说一下，一个人的实施变体越多，选择使用哪个变体就越困难。

因此，事实证明，程序员经常被卡在代码美的任务上。这是一种为艺术而艺术的行为。

我注意到，一般来说（就我自己而言），项目规划的印章越多，就越容易。

然后你可以改变、修改、再修改、过度修改。

但最初的框架（即使它不是很好）为整个建设定下了基调。

 
Urain:

引用罗什 的话：这对你锯木柴有什么帮助？

然后你可以改变，重新修改，再修改，过度修改。

但最初的框架（即使它不是很好）为整个建设定下了基调。

锯木头的速度会提高。

如果你已经有了一个清晰的想法，知道应该怎么做，应该是什么样子--你可能可以在MQL4中巧妙地完成一切。

而如果没有这样的概念--这意味着将有大量的变化和补充。而且多重继承允许以最小的成本进行改变。

我同意抽象的方法--它只是一种很好的记录形式。

 
A100:

锯木头的速度会提高。

如果你已经有了一个清晰的想法，知道应该怎么做，应该是什么样子--你可能可以在MQL4中聪明地做一切。

而如果你没有这样的想法--这意味着大量的改变和补充。特别是多重继承允许以最小的成本做出改变。

如今，继承权正在被放弃，而支持包容。你能想象对多重遗产的态度吗？
 
Vladix:
如今，继承权被试图放弃，以支持包容。你能想象对多重遗产的态度吗？
如果没有多重继承，就无法在界面层面组织横向关系。这个范式很简单：任何对象都可以支持任何数量的接口。但多重继承本身肯定是邪恶的。在C#中禁止使用接口并不是没有道理的，相反，接口的使用是被鼓励的。
 
Urain: 有 FAQ ，坐在四合院上，没有抽象方法或多重继承困扰着他。


A narkarkal :https://www.mql5.com/ru/forum/13114
 

FAQ:

不可能。

不是的。使用开关...案例和使用状态机模式是两件不同的事情。你可以从文本中看出，没有所谓的模式，就像你引用的那篇文章。

它的内容是："我发明了一个独特的获胜系统......"，然后是一个歪歪扭扭的马丁声明。

1...34567891011121314151617...20
新评论