学童的EOP。 - 页 6 12345678910111213...18 新评论 Dmitry Fedoseev 2019.10.04 11:58 #51 Ihor Herasko: 好的。给出你对 "获得者 "的定义。 不是马 Ihor Herasko 2019.10.04 12:10 #52 Dmitry Fedoseev: 不是马。 我以为我面对的是一个能够解释他所知道的东西的人。但在这里，即使是在定义的层面上，也存在着麻烦。 Dmitry Fedoseev 2019.10.04 12:16 #53 Ihor Herasko: 我以为我面对的是一个能够解释他所知道的东西的人。我以为我面对的是一个能够解释他所知道的东西的人。 是的，想怎么幻想就怎么幻想，我早就和你们中的一些人也明白了一切，准备把你们的耳朵冻掉以报复你们的祖母。 Ihor Herasko 2019.10.04 12:19 #54 Dmitry Fedoseev: 你可以尽情地幻想，我和你们这里的一些人也已经理解了很长时间的一切。 一切对你来说都很清楚。你就是无法解释)) Dmitry Fedoseev 2019.10.04 12:20 #55 Ihor Herasko: 一切对你来说都很清楚。你就是无法解释)。 继续冻住你的耳朵，以报复你的祖母。 Igor Makanu 2019.10.04 12:22 #56 Alexey Viktorov: 我从它创建的第一分钟起就一直在读它。 阅读是不够的，我认为，你需要尝试设置任务，并以程序化的方式编写，然后（这并不困难）以OOP方式重写这个任务。 正如TC反复写的那样，OOP可以让你迅速扩大任务规模，加快开发速度，减少编写程序时的错误数量 对于MQL：我最不喜欢的问题之一是部分关闭一系列订单；在程序化编程风格中，在调用一个将关闭一个订单的子程序后，需要组织错误处理--如果我在一次调用中未能部分关闭所有订单，该怎么做？- 服务器不允许部分关闭？- 我在年初的时候问过这个问题，好吧，像往常一样，在99%的情况下，所有常见的解决方案都被简化为对订单注释的分析--比如在那里读，服务器会写一切.....imho，不专业 在OOP风格中，这个问题在 "2次点击 "中得到解决，我们调用部分关闭订单的方法，关于订单状态 的数据--票据，其修改的必要性.....，以及与订单相关的方法都存储在ORDER类中--为接下来的任务提供最大的灵活性和可扩展性的解决方案，我认为 这同样适用于MQL中的图形任务--如果你有一个文本标签，用它来工作不是问题，但如果你有10-100个标签？- 如果你需要改变颜色方案，有选择地对一些标签采用 "珊瑚 "色，而对其他标签采用 "带按钮的珍珠色"，怎么办？....，一周后又增加了3个按钮....。一个星期后，又花了10个按钮来删除....。 ZS：另一个风车之争话题....不，记得有人（忘了他们的姓））。)- 谁说地球是圆的，然后他就被烧死了？))))- 这就是与文盲作斗争和/或拓宽思想的模样 Alexey Viktorov 2019.10.04 14:01 #57 Igor Makanu: 阅读是不够的，我认为，你需要尝试设置任务，并以程序化的方式编写，然后（这并不困难）以OOP方式重写这个任务。 正如TC反复写的那样，OOP可以让你迅速扩大任务规模，加快开发速度，减少编写程序时的错误数量 对于MQL：我最不喜欢的问题之一是部分关闭一系列订单；在程序化编程风格中，在调用一个将关闭一个订单的子程序后，需要组织错误处理--如果我在一次调用中未能部分关闭所有订单，该怎么做？- 服务器不允许部分关闭？- 我在年初的时候问过这个问题，好吧，像往常一样，在99%的情况下，所有常见的解决方案都被简化为对订单评论的分析--比如在那里阅读，服务器会在那里写下一切.....imho，不专业。 在OOP风格中，这个问题在 "2次点击 "中得到解决，我们调用部分关闭订单的方法，关于订单状态 的数据--票据，其修改的必要性.....，以及与订单相关的方法都存储在ORDER类中--为接下来的任务提供了最大的灵活性和可扩展性的解决方案，我认为。 这同样适用于MQL中的图形任务--如果你有一个文本标签，用它来工作不是问题，但如果你有10-100个标签？- 如果你需要改变颜色方案，有选择地对某些标签采用 "珊瑚 "色，而对其他标签采用 "带按钮的珍珠色"，怎么办？....，并在一周后增加了3个按钮....。一个星期后，又花了10个按钮来删除....。 ZS：另一个风车之争话题....不，记得有人（忘了他们的姓））。)- 谁说地球是圆的，然后他就被烧死了？))))- 这就是与文盲作斗争和/或开阔眼界的样子 在我看来，在mql中，通过OOP解决的问题的范围是非常狭窄的。在我看来，这门语言本身不过是C++或其他什么的OOP。而这种OOP是以标准库的形式提供的。对这个OOP，建议增加，否则我不会说，另一个OOP。 然后再走一步...说得很对，术士虽然生气，但仁者见仁智者见智，对于我的任务来说，OOP就像一个狗的转盘。而且，如果这个问题可以用程序式解决而没有任何问题，那么设定一个问题然后通过OOP来实现它又有什么用呢。 例如，从 fxsaber`a 取出 .mqh，为 MT5 以及 MT4 写代码。也许有人需要它，但看看谁...对那些不想或绝对不能掌握mql5的人来说。或者从Nikolay......我忘了他的名字，采取iCanvas。它似乎是一个有用的库，但要理解它并不容易，而且没有任何文档，甚至连一个最小的描述都没有。这不是抱怨，对不起，尼古拉，这是一个事实。 因此，当我决定尝试写一个图形标签时，不参考标准库或尼古拉的库来写就比较容易。 Igor Makanu 2019.10.04 14:16 #58 Alexey Viktorov: 在我看来，mql的任务范围很窄，需要通过OOP来解决。在我看来，这种语言本身不过是C++中的OOP或其他什么东西。而这种OOP是以标准库的形式提供的。对这个OOP，建议增加，否则我不会说，另一个OOP。然后再走一步...说得很对，术士虽然生气，但仁者见仁智者见智，对于我的任务来说，OOP就像一个狗的转盘。而且，如果这个问题可以用程序式解决而没有任何问题，那么设定一个问题然后通过OOP来实现它又有什么用呢。 不幸的是，你说对了90%，但只是因为交易者要求写的交易策略....。坦率地说，它们是原始的。 当有可能在MQL中创建高质量的图形面板时，有一些兴奋，但结果是最终用户也不需要它--这是行业的问题，公众虽然杂乱，但对它感兴趣....。他们只想要一个按钮：钱......。 阿列克谢-维克多罗夫。 例如，从 fxsaber`a 取出 .mqh，用于编写 MT5 以及 MT4 的代码。也许有人需要它，但看看谁......。不想或绝对不能掌握mql5的人。 我正在使用这个库，因为我需要MT5，但我不想花时间研究订单系统，但我在MT5新手主题中试着问过一两次...我真的不想花时间研究订单系统，但我在MT5新手分部尝试了几次......没有结果--事实上，那里没有人知道订单系统如何运作，也没有人回答我的问题......说得好听点，这是一个 "大杂烩"（Jumblebug）。 阿列克谢-维克多罗夫。 或者从Nikolay那里拿iCanvas......我忘了他姓什么，你明白的。似乎是一个有用的库，但要理解它并不容易，而且没有任何文档，甚至是最小的描述。这不是抱怨，对不起，尼古拉，这是一个事实。因此，当我决定尝试写一个图形标签时，不参考标准库或尼古拉的库来写就比较容易。 用过@Nikolai Semko的 库几次--没什么特别的，插上就用......。这个原则就像KB中99%的日常发布的EA一样--那里的版主并不关心订单系统，不是吗？- AdS是以OOP的形式编写的，他产生了任何他认为的专家顾问。 Реter Konow 2019.10.04 14:27 #59 Alexey Viktorov: 在我看来，mql的任务范围很窄，需要通过OOP来解决。在我看来，这种语言本身不过是C++中的OOP或其他什么东西。而这种OOP是以标准库的形式提供的。对这个OOP，建议增加，否则我不会说，另一个OOP。然后再走一步...说得很对，术士虽然生气，但仁者见仁智者见智，对于我的任务来说，OOP就像一个狗的转盘。而且，如果这个问题可以用程序式解决而没有任何问题，那么设定一个问题然后通过OOP来实现它又有什么用呢。 例如，取fxsaber的.mqh来写MT5的代码和MT4的代码。也许有人需要它，但看看是谁。那些不想或绝对不能掌握mql5的人。或者从Nikolay......我忘了他的名字，采取iCanvas。它似乎是一个有用的库，但要理解它并不容易，而且没有任何文档，甚至连一个最小的描述都没有。这不是抱怨，对不起，尼古拉，这是一个事实。因此，当我决定尝试写一个图形标签时，不参考标准库或尼古拉的库来写就比较容易。 OOP的应用 意味着任务的复杂程度，远远高于算法的复杂程度。这就是为什么会有争议。专业的程序员和开发人员需要OOP来处理复杂的程序。这种严肃的做法没有什么空间。 在小例子上解释OOP的含义是错误的。OOP的意义在于有大量数据和函数的大规模工作。数据的多样性需要分离和分类，然后是描述的封装、属性的继承和分层分离的类之间的方法的相关性。 这在小任务上是没有意义的。 Реter Konow 2019.10.04 14:38 #60 当程序员学习OOP 时，他们立即被引入大型程序的世界，并开始在那里遨游。然而，他们自己在这个 "世界 "的功能可能很小。这并不重要。他们只是加入了项目和图书馆的共同海洋，以及他们在那里所做的事情。证券交易商需要吗？这很难说。那些需要它的人将掌握它。其余的人会思考很久，尝试一些东西，并称之为OOP...... 12345678910111213...18 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
好的。给出你对 "获得者 "的定义。
不是马
不是马。
我以为我面对的是一个能够解释他所知道的东西的人。但在这里，即使是在定义的层面上，也存在着麻烦。
我以为我面对的是一个能够解释他所知道的东西的人。我以为我面对的是一个能够解释他所知道的东西的人。
是的，想怎么幻想就怎么幻想，我早就和你们中的一些人也明白了一切，准备把你们的耳朵冻掉以报复你们的祖母。
你可以尽情地幻想，我和你们这里的一些人也已经理解了很长时间的一切。
一切对你来说都很清楚。你就是无法解释))
一切对你来说都很清楚。你就是无法解释)。
继续冻住你的耳朵，以报复你的祖母。
我从它创建的第一分钟起就一直在读它。
阅读是不够的，我认为，你需要尝试设置任务，并以程序化的方式编写，然后（这并不困难）以OOP方式重写这个任务。
正如TC反复写的那样，OOP可以让你迅速扩大任务规模，加快开发速度，减少编写程序时的错误数量
对于MQL：我最不喜欢的问题之一是部分关闭一系列订单；在程序化编程风格中，在调用一个将关闭一个订单的子程序后，需要组织错误处理--如果我在一次调用中未能部分关闭所有订单，该怎么做？- 服务器不允许部分关闭？- 我在年初的时候问过这个问题，好吧，像往常一样，在99%的情况下，所有常见的解决方案都被简化为对订单注释的分析--比如在那里读，服务器会写一切.....imho，不专业
在OOP风格中，这个问题在 "2次点击 "中得到解决，我们调用部分关闭订单的方法，关于订单状态 的数据--票据，其修改的必要性.....，以及与订单相关的方法都存储在ORDER类中--为接下来的任务提供最大的灵活性和可扩展性的解决方案，我认为
这同样适用于MQL中的图形任务--如果你有一个文本标签，用它来工作不是问题，但如果你有10-100个标签？- 如果你需要改变颜色方案，有选择地对一些标签采用 "珊瑚 "色，而对其他标签采用 "带按钮的珍珠色"，怎么办？....，一周后又增加了3个按钮....。一个星期后，又花了10个按钮来删除....。
ZS：另一个风车之争话题....不，记得有人（忘了他们的姓））。)- 谁说地球是圆的，然后他就被烧死了？))))- 这就是与文盲作斗争和/或拓宽思想的模样
阅读是不够的，我认为，你需要尝试设置任务，并以程序化的方式编写，然后（这并不困难）以OOP方式重写这个任务。
正如TC反复写的那样，OOP可以让你迅速扩大任务规模，加快开发速度，减少编写程序时的错误数量
对于MQL：我最不喜欢的问题之一是部分关闭一系列订单；在程序化编程风格中，在调用一个将关闭一个订单的子程序后，需要组织错误处理--如果我在一次调用中未能部分关闭所有订单，该怎么做？- 服务器不允许部分关闭？- 我在年初的时候问过这个问题，好吧，像往常一样，在99%的情况下，所有常见的解决方案都被简化为对订单评论的分析--比如在那里阅读，服务器会在那里写下一切.....imho，不专业。
在OOP风格中，这个问题在 "2次点击 "中得到解决，我们调用部分关闭订单的方法，关于订单状态 的数据--票据，其修改的必要性.....，以及与订单相关的方法都存储在ORDER类中--为接下来的任务提供了最大的灵活性和可扩展性的解决方案，我认为。
这同样适用于MQL中的图形任务--如果你有一个文本标签，用它来工作不是问题，但如果你有10-100个标签？- 如果你需要改变颜色方案，有选择地对某些标签采用 "珊瑚 "色，而对其他标签采用 "带按钮的珍珠色"，怎么办？....，并在一周后增加了3个按钮....。一个星期后，又花了10个按钮来删除....。
ZS：另一个风车之争话题....不，记得有人（忘了他们的姓））。)- 谁说地球是圆的，然后他就被烧死了？))))- 这就是与文盲作斗争和/或开阔眼界的样子
在我看来，在mql中，通过OOP解决的问题的范围是非常狭窄的。在我看来，这门语言本身不过是C++或其他什么的OOP。而这种OOP是以标准库的形式提供的。对这个OOP，建议增加，否则我不会说，另一个OOP。 然后再走一步...说得很对，术士虽然生气，但仁者见仁智者见智，对于我的任务来说，OOP就像一个狗的转盘。而且，如果这个问题可以用程序式解决而没有任何问题，那么设定一个问题然后通过OOP来实现它又有什么用呢。
例如，从 fxsaber`a 取出 .mqh，为 MT5 以及 MT4 写代码。也许有人需要它，但看看谁...对那些不想或绝对不能掌握mql5的人来说。或者从Nikolay......我忘了他的名字，采取iCanvas。它似乎是一个有用的库，但要理解它并不容易，而且没有任何文档，甚至连一个最小的描述都没有。这不是抱怨，对不起，尼古拉，这是一个事实。 因此，当我决定尝试写一个图形标签时，不参考标准库或尼古拉的库来写就比较容易。
在我看来，mql的任务范围很窄，需要通过OOP来解决。在我看来，这种语言本身不过是C++中的OOP或其他什么东西。而这种OOP是以标准库的形式提供的。对这个OOP，建议增加，否则我不会说，另一个OOP。然后再走一步...说得很对，术士虽然生气，但仁者见仁智者见智，对于我的任务来说，OOP就像一个狗的转盘。而且，如果这个问题可以用程序式解决而没有任何问题，那么设定一个问题然后通过OOP来实现它又有什么用呢。
不幸的是，你说对了90%，但只是因为交易者要求写的交易策略....。坦率地说，它们是原始的。 当有可能在MQL中创建高质量的图形面板时，有一些兴奋，但结果是最终用户也不需要它--这是行业的问题，公众虽然杂乱，但对它感兴趣....。他们只想要一个按钮：钱......。
例如，从 fxsaber`a 取出 .mqh，用于编写 MT5 以及 MT4 的代码。也许有人需要它，但看看谁......。不想或绝对不能掌握mql5的人。
我正在使用这个库，因为我需要MT5，但我不想花时间研究订单系统，但我在MT5新手主题中试着问过一两次...我真的不想花时间研究订单系统，但我在MT5新手分部尝试了几次......没有结果--事实上，那里没有人知道订单系统如何运作，也没有人回答我的问题......说得好听点，这是一个 "大杂烩"（Jumblebug）。
或者从Nikolay那里拿iCanvas......我忘了他姓什么，你明白的。似乎是一个有用的库，但要理解它并不容易，而且没有任何文档，甚至是最小的描述。这不是抱怨，对不起，尼古拉，这是一个事实。因此，当我决定尝试写一个图形标签时，不参考标准库或尼古拉的库来写就比较容易。
用过@Nikolai Semko的 库几次--没什么特别的，插上就用......。这个原则就像KB中99%的日常发布的EA一样--那里的版主并不关心订单系统，不是吗？- AdS是以OOP的形式编写的，他产生了任何他认为的专家顾问。
在我看来，mql的任务范围很窄，需要通过OOP来解决。在我看来，这种语言本身不过是C++中的OOP或其他什么东西。而这种OOP是以标准库的形式提供的。对这个OOP，建议增加，否则我不会说，另一个OOP。然后再走一步...说得很对，术士虽然生气，但仁者见仁智者见智，对于我的任务来说，OOP就像一个狗的转盘。而且，如果这个问题可以用程序式解决而没有任何问题，那么设定一个问题然后通过OOP来实现它又有什么用呢。
例如，取fxsaber的.mqh来写MT5的代码和MT4的代码。也许有人需要它，但看看是谁。那些不想或绝对不能掌握mql5的人。或者从Nikolay......我忘了他的名字，采取iCanvas。它似乎是一个有用的库，但要理解它并不容易，而且没有任何文档，甚至连一个最小的描述都没有。这不是抱怨，对不起，尼古拉，这是一个事实。因此，当我决定尝试写一个图形标签时，不参考标准库或尼古拉的库来写就比较容易。
OOP的应用 意味着任务的复杂程度，远远高于算法的复杂程度。这就是为什么会有争议。专业的程序员和开发人员需要OOP来处理复杂的程序。这种严肃的做法没有什么空间。 在小例子上解释OOP的含义是错误的。OOP的意义在于有大量数据和函数的大规模工作。数据的多样性需要分离和分类，然后是描述的封装、属性的继承和分层分离的类之间的方法的相关性。
这在小任务上是没有意义的。