文章 "轻松快捷开发 MetaTrader 程序的函数库(第 二十七部分):操控交易请求 - 下挂单" - 页 4 12345 新评论 Реter Konow 2019.12.17 08:13 #31 Artyom Trishkin:他们为什么每秒发送一次?是为了淹没交易服务器吗? 这是重复请求之间的条件间隔。这是可以配置的。 Реter Konow 2019.12.17 08:17 #32 Artyom Trishkin:我需要完整的对象来实现我的进一步计划。 但你还没有意识到这一点,你只是试图为进一步的工作提供无效的方法来解决任务的一小部分。但在这里,所有事情都是联系在一起的,总体概念也是一样的--未来计划中的其他事情都取决于这一小部分。无论如何,感谢您的意见--任何意见都是有用的、有意义的。ZЫ.是的,与其为了下一个任务而不断重写漫不经心地编写的不完整的解决方案,还不如写出能用的乱七八糟的代码,这并不可怕。 好吧,如果我们需要它们,我们就需要它们。找出原因会很有趣。 ZЫ.如果它能摆脱修改和重新设计,那就不可怕了,但事实上并没有。什么对象或不对象 - 所有相同的概念的发展迫使重新设计了很多东西。 Artyom Trishkin 2019.12.17 08:29 #33 Реter Konow:好吧,如果需要,那就需要。我很想知道是为了什么。ZY,如果能避免修改和重新设计,那就不可怕了,但事实上并没有。不管是不是对象--都一样,概念的发展迫使我们重新设计很多东西。 你没有把 "重新设计 "和 "扩展 "这两个概念分开。重新设计就是把现成的东西扔进垃圾桶,然后从头开始写一个新的。而扩展就是在现成的基础上增加新的功能。 在大多数情况下,这里只是添加,而不是逐条重写。 但是,当从头开始创建一个新东西时,是的,会有很多改写。但那是在文章的幕后。只有两个例外--一开始是对已发布的内容进行小幅修改,以进一步扩展所有库组件的功能;现在--一开始是先在简化代码上测试解决方案,然后--通过一篇文章--进行全面的对象-交易查询,然后--用它们制作一个工作类。 现在,所有工作都在一个地方完成--在交易类中。但它不应该在那里--虽然它是贸易,但它不是贸易方法--它是管理贸易方法的一种方式。 Реter Konow 2019.12.17 13:01 #34 Artyom Trishkin:你没有把 "重做 "和 "扩展 "这两个概念分开。重新设计就是扔掉现成的,从头开始写一个新的。而扩展则是在现成的基础上增加新的功能。在大多数情况下,这里只是添加,而不是逐条重写。 但在从头开始创建新内容时,是的,会有很多改写。但那是在文章的幕后。只有两个例外--一开始是对已发布的内容进行小幅修改,以进一步扩展所有库组件的功能,而现在--一开始是在简化代码上测试解决方案,然后--通过一篇文章--制作成熟的对象--交易请求,然后--用它们制作一个工作类。 现在,所有工作都在一个地方完成--在交易类中。但它不应该在那里--虽然它是贸易,但它不是贸易方法--它是管理贸易方法的一种方式。 我非常清楚地分享了一切,也知道自己在说什么。而你却不知道我在说什么。 你一心想把世界上的一切都变成对象,这说明你不了解对象的概念边界。在 OOP 中,没有任何规则要求把所有东西都变成对象,但你似乎对此一无所知。 想想你要花多少时间来处理对象,而我指出的简洁和现成的解决方案已经削弱了处理对象的必要性。你还能想出什么好办法?我没有足够的想象力。也许你有。说吧。 Реter Konow 2019.12.17 13:36 #35 什么可以成为对象,什么不可以? 1.交易请求 是对象。 2. 待处理的交易请求不是对象。为什么?因为如果我们将其作为对象,它将是交易请求对象的完全副本,只有一个不同点--重复和删除标准。这个差别太小,无法将挂起的 交易申请 从交易申请 中 "解包 "出来。 Artyom Trishkin 2019.12.17 14:10 #36 嗯,也是一种观点。 Реter Konow 2019.12.18 15:49 #37 了解我们方法的不同之处。为什么简单的解决方案不适合你。你遵循 "万物皆对象 "的原则。我遵循的是 "一切皆对象 "原则。你创建了许多小而简单的对象,而我创建了一个大而复杂的对象。我的解决方案要求你压缩要开发的对象的内容,而你的解决方案要求你为每个对象填充内容,使其作为一个合理的实体进行开发。我给出的解决方案不需要延迟查询对象。你的下一篇文章表明,围绕向服务器重放失败请求这一简单任务,你创建了多么杂乱的实体及其相互关系。只需重复未满足的服务器请求即可,但你的解决方案却令人吃惊地创建了一个实体世界,让人迷失在其中,如入丛林。我对这种编程做法感到纳闷,不知该作何感想。一方面,它令人钦佩,另一方面,它又令人发指。如果我这样解决问题,我将没有足够的生命去做我想做的事。因此,我无法给出明确的评价。我知道一件事:如果你被逼到墙角,要求在明天晚上之前找到解决办法,你不会制造任何物品,而是使用我的解决办法,效果也不会差到哪里去。 Denis Kirichenko 2019.12.18 17:05 #38 Реter Konow:......你创建了许多小而简单的对象,而我创建了一个大而复杂的....。 彼得,这是超类吗?你能塞进你塞不进的东西吗?:-)他们在书中写道,这样做不好.....。 我想向阿尔乔姆指出,阿纳托利 在写一系列关于图形的文章时,给出了类之间的相互关系结构(读作层次结构)。例如 Artyom,你做得很好。你可以为此写一整本教科书。有些地方甚至比文档还要详细。这很酷。但有时教材中的插图不够多。当然... Artyom Trishkin 2019.12.18 17:13 #39 Denis Kirichenko:彼得,这是什么,超级课堂?你能塞进去你塞不进去的东西?:-)书上说不好....我想向阿尔乔姆指出,阿纳托利 在写一系列关于图形的文章时,给出了类之间的相互关系结构(读作层次结构)。例如Artyom,你做得很好。你可以为此写一整本教科书。有些地方甚至比文档还要详细。这很酷。但有时材料中的插图不够。当然,这是个人意见... 谢谢。层次结构稍后再确定。如果需要修改,我不想重做。 Реter Konow 2019.12.18 17:21 #40 Denis Kirichenko:彼得,这是什么,超级课堂?你能塞进你塞不进去的东西吗?:-)书上说,这不是好.... 一切结果和效果都很好。萝卜白菜,各有所爱。我在读文章,却找不到 "实体生成器"--所有这一切的原理。我试图学会用这种方式思考,并理解自己为什么会有不同的想法。以及不同思维方式的好处(如果有的话)是什么。我也跟阿尔乔姆说过图书馆计划。 12345 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
他们为什么每秒发送一次?是为了淹没交易服务器吗?
我需要完整的对象来实现我的进一步计划。 但你还没有意识到这一点,你只是试图为进一步的工作提供无效的方法来解决任务的一小部分。但在这里,所有事情都是联系在一起的,总体概念也是一样的--未来计划中的其他事情都取决于这一小部分。
无论如何,感谢您的意见--任何意见都是有用的、有意义的。
ZЫ.是的,与其为了下一个任务而不断重写漫不经心地编写的不完整的解决方案,还不如写出能用的乱七八糟的代码,这并不可怕。
好吧,如果我们需要它们,我们就需要它们。找出原因会很有趣。
ZЫ.如果它能摆脱修改和重新设计,那就不可怕了,但事实上并没有。什么对象或不对象 - 所有相同的概念的发展迫使重新设计了很多东西。
好吧,如果需要,那就需要。我很想知道是为了什么。
ZY,如果能避免修改和重新设计,那就不可怕了,但事实上并没有。不管是不是对象--都一样,概念的发展迫使我们重新设计很多东西。
你没有把 "重新设计 "和 "扩展 "这两个概念分开。重新设计就是把现成的东西扔进垃圾桶,然后从头开始写一个新的。而扩展就是在现成的基础上增加新的功能。
在大多数情况下,这里只是添加,而不是逐条重写。
但是,当从头开始创建一个新东西时,是的,会有很多改写。但那是在文章的幕后。只有两个例外--一开始是对已发布的内容进行小幅修改,以进一步扩展所有库组件的功能;现在--一开始是先在简化代码上测试解决方案,然后--通过一篇文章--进行全面的对象-交易查询,然后--用它们制作一个工作类。
现在,所有工作都在一个地方完成--在交易类中。但它不应该在那里--虽然它是贸易,但它不是贸易方法--它是管理贸易方法的一种方式。
你没有把 "重做 "和 "扩展 "这两个概念分开。重新设计就是扔掉现成的,从头开始写一个新的。而扩展则是在现成的基础上增加新的功能。
在大多数情况下,这里只是添加,而不是逐条重写。
但在从头开始创建新内容时,是的,会有很多改写。但那是在文章的幕后。只有两个例外--一开始是对已发布的内容进行小幅修改,以进一步扩展所有库组件的功能,而现在--一开始是在简化代码上测试解决方案,然后--通过一篇文章--制作成熟的对象--交易请求,然后--用它们制作一个工作类。
现在,所有工作都在一个地方完成--在交易类中。但它不应该在那里--虽然它是贸易,但它不是贸易方法--它是管理贸易方法的一种方式。
我非常清楚地分享了一切,也知道自己在说什么。而你却不知道我在说什么。
你一心想把世界上的一切都变成对象,这说明你不了解对象的概念边界。在 OOP 中,没有任何规则要求把所有东西都变成对象,但你似乎对此一无所知。
想想你要花多少时间来处理对象,而我指出的简洁和现成的解决方案已经削弱了处理对象的必要性。你还能想出什么好办法?我没有足够的想象力。也许你有。说吧。
什么可以成为对象,什么不可以?
1.交易请求 是对象。
2. 待处理的交易请求不是对象。为什么?因为如果我们将其作为对象,它将是交易请求对象的完全副本,只有一个不同点--重复和删除标准。这个差别太小,无法将挂起的 交易申请 从交易申请 中 "解包 "出来。
......你创建了许多小而简单的对象,而我创建了一个大而复杂的....。
彼得,这是超类吗?你能塞进你塞不进的东西吗?:-)他们在书中写道,这样做不好.....。
我想向阿尔乔姆指出,阿纳托利 在写一系列关于图形的文章时,给出了类之间的相互关系结构(读作层次结构)。例如
Artyom,你做得很好。你可以为此写一整本教科书。有些地方甚至比文档还要详细。这很酷。但有时教材中的插图不够多。当然...
彼得,这是什么,超级课堂?你能塞进去你塞不进去的东西?:-)书上说不好....
我想向阿尔乔姆指出,阿纳托利 在写一系列关于图形的文章时,给出了类之间的相互关系结构(读作层次结构)。例如
Artyom,你做得很好。你可以为此写一整本教科书。有些地方甚至比文档还要详细。这很酷。但有时材料中的插图不够。当然,这是个人意见...
彼得,这是什么,超级课堂?你能塞进你塞不进去的东西吗?:-)书上说,这不是好....