结构规则。 学习如何构建方案,探索可能性、错误、解决方案等。 - 页 10 1...34567891011121314151617...20 新评论 Vasiliy Sokolov 2013.07.24 11:51 #91 我对国家编程并不陌生,自己也用了好几年。然而,在使用这个方法一段时间后,我决定放弃它,并在其基础上开发了一个更透明、更简单、更适合的交易模式。仔细阅读这篇文章:自动编程是创建自动交易系统的新方法然后仔细阅读这些关于它的评论。然后非常、非常认真地思考文章中的一个难看的斑块,并思考它可能意味着什么。如果在读完这些之后,你仍然会说:"哇!国家编程太酷了!"- 那么,就指望它吧。我想补充一点,状态编程的主要问题是产生大量无用模式的情况(见N列状态)。在国家编程中,每种模式都应单独描述自己的规则。让我们举例说明,假设我们处于购买模式。一切都很好,直到机器人决定再开一个位置。为什么不呢?退出旧仓的条件还没有达到,现在平仓还为时过早,而新的信号则不应该错过。而这里就是问题的开始,因为在新信号到达的时刻,机器人处于买入模式,而开立新仓的规则处于状态模式(等待和寻找新的进入信号)。现在在买入模式下,我们必须重新描述在状态模式下使用的相同的开仓规则。如果一个新的头寸在方向上是相反的(对冲)呢?这个位置已经打开,但该如何处理?毕竟,其管理逻辑是在卖出模式下描述的,而机器人是在买入模式下。我们可以简单地切换到卖出模式,但如何处理剩余的买入头寸?一般来说,在这种情况下,我们必须再写一个像BuyAndSell那样的无用模式。模式的冗余产生了另外一种情况:一个相同的动作由不同的代码部分来执行。总而言之,对于那些喜欢指数型编程混乱的人来说,这就是最好的。 TheXpert 2013.07.24 11:57 #92 C-4:(fcplm) Rustamzhan Salidzhanov 2013.07.24 11:58 #93 C-4:"这就是米哈伊奇"(C)......这也是我所暗示的。TheXpert。(fcplm)不可能。 A100 2013.07.24 12:34 #94 C-4: 我只是在想,如果MQL5支持多重继承,并且一个类可以声明抽象方法,那么就会开辟一条使用接口的途径,这对于大型项目来说是非常好的。 抽象方法没有被明确禁止(我经常使用替代符号)。 而多重继承将是一个巨大的优势。 Mykola Demko 2013.07.24 12:45 #95 A100: 抽象方法没有被明确禁止。引用Rosh 的话:这对你锯木柴有什么帮助?冯氏问答 ,坐拥四合院,对抽象方法和多重继承不屑一顾。是否会有抽象方法并不重要,反正项目结构化的任务不会得到解决。顺便说一下,一个人的实施变体越多,选择使用哪个变体就越困难。因此,事实证明,程序员经常被卡在代码美的任务上。这是一种为艺术而艺术的行为。我注意到,一般来说(就我自己而言),项目规划的印章越多,就越容易。然后你可以改变、修改、再修改、过度修改。但最初的框架(即使它不是很好)为整个建设定下了基调。 A100 2013.07.24 13:04 #96 Urain: 引用罗什 的话:这对你锯木柴有什么帮助? 然后你可以改变,重新修改,再修改,过度修改。 但最初的框架(即使它不是很好)为整个建设定下了基调。 锯木头的速度会提高。 如果你已经有了一个清晰的想法,知道应该怎么做,应该是什么样子--你可能可以在MQL4中巧妙地完成一切。 而如果没有这样的概念--这意味着将有大量的变化和补充。而且多重继承允许以最小的成本进行改变。 我同意抽象的方法--它只是一种很好的记录形式。 Vladimir Kustikov 2013.07.24 13:08 #97 A100: 锯木头的速度会提高。 如果你已经有了一个清晰的想法,知道应该怎么做,应该是什么样子--你可能可以在MQL4中聪明地做一切。 而如果你没有这样的想法--这意味着大量的改变和补充。特别是多重继承允许以最小的成本做出改变。 如今,继承权正在被放弃,而支持包容。你能想象对多重遗产的态度吗? Vasiliy Sokolov 2013.07.24 13:20 #98 Vladix: 如今,继承权被试图放弃,以支持包容。你能想象对多重遗产的态度吗? 如果没有多重继承,就无法在界面层面组织横向关系。这个范式很简单:任何对象都可以支持任何数量的接口。但多重继承本身肯定是邪恶的。在C#中禁止使用接口并不是没有道理的,相反,接口的使用是被鼓励的。 Rustamzhan Salidzhanov 2013.07.24 13:33 #99 Urain: 有 FAQ ,坐在四合院上,没有抽象方法或多重继承困扰着他。 A narkarkal :https://www.mql5.com/ru/forum/13114 TheXpert 2013.07.24 13:46 #100 FAQ:不可能。不是的。使用开关...案例和使用状态机模式是两件不同的事情。你可以从文本中看出,没有所谓的模式,就像你引用的那篇文章。它的内容是:"我发明了一个独特的获胜系统......",然后是一个歪歪扭扭的马丁声明。 1...34567891011121314151617...20 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
我对国家编程并不陌生,自己也用了好几年。然而,在使用这个方法一段时间后,我决定放弃它,并在其基础上开发了一个更透明、更简单、更适合的交易模式。
仔细阅读这篇文章:自动编程是创建自动交易系统的新方法
然后仔细阅读这些关于它的评论。
然后非常、非常认真地思考文章中的一个难看的斑块,并思考它可能意味着什么。
如果在读完这些之后,你仍然会说:"哇!国家编程太酷了!"- 那么,就指望它吧。
我想补充一点,状态编程的主要问题是产生大量无用模式的情况(见N列状态)。在国家编程中,每种模式都应单独描述自己的规则。让我们举例说明,假设我们处于购买模式。一切都很好,直到机器人决定再开一个位置。为什么不呢?退出旧仓的条件还没有达到,现在平仓还为时过早,而新的信号则不应该错过。而这里就是问题的开始,因为在新信号到达的时刻,机器人处于买入模式,而开立新仓的规则处于状态模式(等待和寻找新的进入信号)。现在在买入模式下,我们必须重新描述在状态模式下使用的相同的开仓规则。如果一个新的头寸在方向上是相反的(对冲)呢?这个位置已经打开,但该如何处理?毕竟,其管理逻辑是在卖出模式下描述的,而机器人是在买入模式下。我们可以简单地切换到卖出模式,但如何处理剩余的买入头寸?一般来说,在这种情况下,我们必须再写一个像BuyAndSell那样的无用模式。模式的冗余产生了另外一种情况:一个相同的动作由不同的代码部分来执行。总而言之,对于那些喜欢指数型编程混乱的人来说,这就是最好的。
"这就是米哈伊奇"(C)......这也是我所暗示的。
(fcplm)
不可能。
我只是在想,如果MQL5支持多重继承,并且一个类可以声明抽象方法,那么就会开辟一条使用接口的途径,这对于大型项目来说是非常好的。
抽象方法没有被明确禁止(我经常使用替代符号)。
而多重继承将是一个巨大的优势。
抽象方法没有被明确禁止。
引用Rosh 的话:这对你锯木柴有什么帮助?
冯氏问答 ,坐拥四合院,对抽象方法和多重继承不屑一顾。
是否会有抽象方法并不重要,反正项目结构化的任务不会得到解决。
顺便说一下,一个人的实施变体越多,选择使用哪个变体就越困难。
因此,事实证明,程序员经常被卡在代码美的任务上。这是一种为艺术而艺术的行为。
我注意到,一般来说(就我自己而言),项目规划的印章越多,就越容易。
然后你可以改变、修改、再修改、过度修改。
但最初的框架(即使它不是很好)为整个建设定下了基调。
引用罗什 的话:这对你锯木柴有什么帮助?
然后你可以改变,重新修改,再修改,过度修改。
但最初的框架(即使它不是很好)为整个建设定下了基调。
锯木头的速度会提高。
如果你已经有了一个清晰的想法,知道应该怎么做,应该是什么样子--你可能可以在MQL4中巧妙地完成一切。
而如果没有这样的概念--这意味着将有大量的变化和补充。而且多重继承允许以最小的成本进行改变。
我同意抽象的方法--它只是一种很好的记录形式。
锯木头的速度会提高。
如果你已经有了一个清晰的想法,知道应该怎么做,应该是什么样子--你可能可以在MQL4中聪明地做一切。
而如果你没有这样的想法--这意味着大量的改变和补充。特别是多重继承允许以最小的成本做出改变。
如今,继承权被试图放弃,以支持包容。你能想象对多重遗产的态度吗?
FAQ:
不可能。
不是的。使用开关...案例和使用状态机模式是两件不同的事情。你可以从文本中看出,没有所谓的模式,就像你引用的那篇文章。
它的内容是:"我发明了一个独特的获胜系统......",然后是一个歪歪扭扭的马丁声明。