我的方法。核心是引擎。 - 页 138 1...131132133134135136137138139140141142143144145...184 新评论 Maxim Kuznetsov 2019.01.11 04:58 #1371 "扩大OOP支持者的创造潜力"，维列夏金，画布，油彩 Реter Konow 2019.01.11 09:45 #1372 谢谢你们的信息量很大的帖子。 今天我们将测试EA和引擎之间通过资源的通信。刚刚完成。在测试器中应该也能工作。 Vasiliy Sokolov 2019.01.11 10:03 #1373 Реter Konow:你正在使用CCanvas类。它是你的发展中唯一的一个。 该班是系统的一部分。如果它是一个，就没有系统。 那么为什么要创建类对象 并通过OOP规则来引用它的功能呢？ 在处理一个类时，你实际上不需要OOP。但是，你在处理一个类时确实使用了OOP。不过，你不需要OOP。彼得，在OOP中，类对象的创建是为了让你能够处理多个互不依赖的对象。当你用CCanvas工作时，你有一个图形，一切都很好，你在这里真的不需要OOP。但是当你需要在不同的区域显示几个图的时候，如果没有OOP和创建CCanvas的多个实例，就很难做到。 或者再举一个例子。最近，我被要求修改一个程序化的专家顾问，以便它可以同时在不同的符号上进行交易（在一个图表上运行）。程序化的风格将需要长期和复杂的努力，使其在同一时间在不同的符号上独立交易。相比之下，我只是将整个程序性代码放在一个类中，并创建了三个示例。我为他们每个人指定了一套单独的设置，包括工作符号等。这段代码在第一次尝试时就发挥了它应有的作用。用户很满意。 甚至你在你的内核中也在使用OOP。虽然你是暗地里这么做的。 Retag Konow:为了不至于毫无根据，让我最后给你举个例子，说明这个 "内核"。更确切地说，它是一个启动文件。这里面有几个核心。 让我提醒你，它是自动打印的，基于KIB-代码。然后放置在发动机中。接下来，发动机与之配合。在OOP术语中，你的每个内核都是一个类的实例。无论你如何称呼它，但它是OOP的一个元素。但不幸的是，这种元素是自制的，在概念力量上不如已经被成千上万的未经训练的头脑发明和打磨的东西。 Georgiy Merts 2019.01.11 10:12 #1374 你们这些人为什么要试图说服彼得相信OOP的好处？ 你不会说服他的!如果你有像他那样的记忆力，你会想为什么所有这些OOP的东西都那么复杂，而你可以做所有的事情都那么简单？我们让所有的变量都是全局性的，从任何地方都可以直接访问，没有禁令和限制--很好! 这是为那些在他们孱弱的头脑中可能忘记他们十年前写的东西的人准备的--编译器和语言在各方面限制它是必要的。而当你清楚地记得为什么以及为什么在你的代码中写了这个或那个结构，这已经是很多年前的事情了--OOP只是车中的第五个轮子而已。 彼得的问题不在于 "OOP或程序性方法 "的选择，彼得的问题在于目标受众。一方面缺乏擅长编程的人，另一方面又喜欢换手。我不观察这种人。 Vasiliy Sokolov 2019.01.11 10:13 #1375 Реter Konow:1.没错。在构造函数中可以规定有限数量的元素。因此，一个动态表必须由有限的行数组成，但同时又是不受限制的。解决办法只在于为添加的参数创建特殊数组，并通过表格单元滚动它们的值。 2.是的，构造器根据你引用的代码为引擎创建内核。+ 打印连接文件。然后，我把内核放入引擎（DRIVE）。之后，该引擎可以播放所需的GUI。配对文件被连接到EA，并开始与它互动。事实证明，每次为了一个新的gui，你必须对引擎进行修改（为它提供适当的GUI内核）。我认为这是一个根本性的错误解决方案。想象一下，你的引擎有数百个用户。但托管在市场或其他地方的引擎只是一个。在这种情况下，你将如何做？对于每个用户来说，放置一个特定的引擎，他必须为自己下载？你是如何为引擎准备gui核心的？你会为每个用户提供一个单独的引擎吗？- 这将很快成为一场恶梦。因此，你的解决方案是不可扩展的。 Реter Konow 2019.01.11 10:13 #1376 Vasiliy Sokolov:彼得，在OOP中，类对象的创建是为了让你能够处理多个互不依赖的对象。当你用CCanvas工作时，你有一个图形，一切都很好，你在这里真的不需要OOP。但是当你需要在不同的区域显示几个图的时候，如果没有OOP和创建CCanvas的多个实例，就很难做到。 或者再举一个例子。最近，我被要求修改一个程序化的专家顾问，以便它可以同时在不同的符号上进行交易（在一个图表上运行）。程序化的风格将需要长期和复杂的努力，使其在同一时间在不同的符号上独立交易。相比之下，我只是将整个程序性代码放在一个类中，并创建了三个示例。我为他们每个人指定了一套单独的设置，包括工作符号等。这段代码在第一次尝试时就发挥了它应有的作用。用户很满意。 甚至你在你的内核中也在使用OOP。虽然你是暗地里这么做的。 在OOP术语中，你的每个内核都是一个类的实例。不管你怎么称呼它，它都是OOP的一个元素。但不幸的是，这个元素是自制的，在概念的力量上屈服于已经被成千上万的未经尝试的头脑发明和打磨过的东西。Vasily，我明白为什么要把绘图功能做成一个类。因为除了它们之外，还有其他几组功能。 但我的问题有点不同。究竟为什么尼古拉要通过一个类来调用绘图函数，如果他不使用任何其他类的话。他只画画。 该问题的重点正是如此。 我强调了这种行为在逻辑上的无意义性，而且他并没有意识到这一点。 我还强调，按照要解决的任务的大小，使用OOP 往往是不合理的。毕竟，OOP需要一个分支分类，如果没有这样的分类，是否值得故意创造它？ 问题是，开发者应该以机制的要求为指导，而不是工具。 Artyom Trishkin 2019.01.11 10:14 #1377 Vasiliy Sokolov:彼得，在OOP中，类对象的创建是为了让你能够处理多个互不依赖的对象。当你用CCanvas工作时，你有一个图形，一切都很好，你在这里真的不需要OOP。但是当你需要在不同的区域显示几个图的时候，如果没有OOP和创建CCanvas的多个实例就很难做到。 或者再举一个例子。最近，我被要求修改一个程序化的专家顾问，以便它可以同时在不同的符号上进行交易（在一个图表上运行）。程序化的风格将需要长期和复杂的努力，使其在同一时间在不同的符号上独立交易。相比之下，我只是将整个程序性代码放在一个类中，并创建了三个示例。我为他们每个人指定了一套单独的设置，包括工作符号等。这段代码在第一次尝试时就发挥了它应有的作用。用户很满意。 甚至你在你的内核中也在使用OOP。虽然你是暗地里这么做的。 在OOP术语中，你的每个内核都是一个类的实例。不管你怎么称呼它，它都是OOP的一个元素。但不幸的是，这个元素是自制的，在概念的力量上屈服于已经被成千上万的无能的头脑发明和打磨过的东西。你在浪费你的时间。首先，你和珀斯的顾问的例子是一个膏药--他不会写专家，他不明白有什么，有什么意义，他不能理解你非常清楚的例子--你会看到，他，眨着眼睛，会告诉你和他告诉尼古拉一样的事情。其次，你会给他一个借口，把他的鼻子推得更高，说他在自己的桶里做了一个超级独特的代码，没有得到成千上万的前人的帮助，有一个比以前任何解决方案都好的杰出解决方案。你会看到--这正是他将用滑块定位他独特的桶的方式...... 我可能说得很难听，但我很少容忍不可逾越的愚蠢行为。 Georgiy Merts 2019.01.11 10:15 #1378 Vasiliy Sokolov:在OOP术语中，你的每个内核都是一个类的实例。而且不管你怎么称呼它，它都是OOP的一个元素。但不幸的是，这个元素是自制的，在概念的力量上屈服于已经被成千上万的无能的头脑发明和打磨过的东西。因此，它是。但是，仍然有显著的区别。就我而言，在彼得家--在这个阶级的典范--几乎什么都有。而这并不符合OOP的封装范式。另外，还有全局变量。 所以在这里--只有 "OOP的元素"。 但是，我担心，人们不会喜欢相反的情况--我确信，Vasily，当我推出我的OOP-项目时，相反的，人们会尖叫 "你不能用这个界面做任何事情，除了它的目的":) Реter Konow 2019.01.11 10:16 #1379 Vasiliy Sokolov:事实证明，每当你制作一个新的gui时，你必须对引擎进行修改（为它配备适当的GUI内核）。我认为这是一个根本性的错误解决方案。想象一下，你的引擎有数百个用户。但托管在市场或其他地方的引擎只是一个。在这种情况下，你将如何做？对于每个用户来说，放置一个特定的引擎，他必须为自己下载？你是如何为引擎准备gui核心的？你会为每个用户提供一个单独的引擎吗？- 这将很快成为一场恶梦。因此，你的解决方案是不可扩展的。不，瓦西里，你倾向于把一切都戏剧化）。 在设计器中有一个按钮，点击后可以打印出所有的文件。 而引擎将从一个文本文件中加载内核。这并不难做到。 Maxim Dmitrievsky 2019.01.11 10:17 #1380 Nikolai Semko: 彼得，你真的误解了一些关于OOP的应用。对不起，但这有精神分裂症的味道。这是一种特殊的意识形式，不要阻止它的发展。 1...131132133134135136137138139140141142143144145...184 新评论 原因: 取消 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
"扩大OOP支持者的创造潜力"，维列夏金，画布，油彩
谢谢你们的信息量很大的帖子。
今天我们将测试EA和引擎之间通过资源的通信。刚刚完成。在测试器中应该也能工作。
你正在使用CCanvas类。它是你的发展中唯一的一个。
该班是系统的一部分。如果它是一个，就没有系统。
那么为什么要创建类对象 并通过OOP规则来引用它的功能呢？
在处理一个类时，你实际上不需要OOP。
但是，你在处理一个类时确实使用了OOP。不过，你不需要OOP。
彼得，在OOP中，类对象的创建是为了让你能够处理多个互不依赖的对象。当你用CCanvas工作时，你有一个图形，一切都很好，你在这里真的不需要OOP。但是当你需要在不同的区域显示几个图的时候，如果没有OOP和创建CCanvas的多个实例，就很难做到。
或者再举一个例子。最近，我被要求修改一个程序化的专家顾问，以便它可以同时在不同的符号上进行交易（在一个图表上运行）。程序化的风格将需要长期和复杂的努力，使其在同一时间在不同的符号上独立交易。相比之下，我只是将整个程序性代码放在一个类中，并创建了三个示例。我为他们每个人指定了一套单独的设置，包括工作符号等。这段代码在第一次尝试时就发挥了它应有的作用。用户很满意。
甚至你在你的内核中也在使用OOP。虽然你是暗地里这么做的。
为了不至于毫无根据，让我最后给你举个例子，说明这个 "内核"。更确切地说，它是一个启动文件。这里面有几个核心。
让我提醒你，它是自动打印的，基于KIB-代码。然后放置在发动机中。接下来，发动机与之配合。
在OOP术语中，你的每个内核都是一个类的实例。无论你如何称呼它，但它是OOP的一个元素。但不幸的是，这种元素是自制的，在概念力量上不如已经被成千上万的未经训练的头脑发明和打磨的东西。
你们这些人为什么要试图说服彼得相信OOP的好处？
你不会说服他的!如果你有像他那样的记忆力，你会想为什么所有这些OOP的东西都那么复杂，而你可以做所有的事情都那么简单？我们让所有的变量都是全局性的，从任何地方都可以直接访问，没有禁令和限制--很好!
这是为那些在他们孱弱的头脑中可能忘记他们十年前写的东西的人准备的--编译器和语言在各方面限制它是必要的。而当你清楚地记得为什么以及为什么在你的代码中写了这个或那个结构，这已经是很多年前的事情了--OOP只是车中的第五个轮子而已。
彼得的问题不在于 "OOP或程序性方法 "的选择，彼得的问题在于目标受众。一方面缺乏擅长编程的人，另一方面又喜欢换手。我不观察这种人。
1.没错。在构造函数中可以规定有限数量的元素。因此，一个动态表必须由有限的行数组成，但同时又是不受限制的。解决办法只在于为添加的参数创建特殊数组，并通过表格单元滚动它们的值。
2.是的，构造器根据你引用的代码为引擎创建内核。+ 打印连接文件。然后，我把内核放入引擎（DRIVE）。之后，该引擎可以播放所需的GUI。配对文件被连接到EA，并开始与它互动。
事实证明，每次为了一个新的gui，你必须对引擎进行修改（为它提供适当的GUI内核）。我认为这是一个根本性的错误解决方案。想象一下，你的引擎有数百个用户。但托管在市场或其他地方的引擎只是一个。在这种情况下，你将如何做？对于每个用户来说，放置一个特定的引擎，他必须为自己下载？你是如何为引擎准备gui核心的？你会为每个用户提供一个单独的引擎吗？- 这将很快成为一场恶梦。因此，你的解决方案是不可扩展的。
彼得，在OOP中，类对象的创建是为了让你能够处理多个互不依赖的对象。当你用CCanvas工作时，你有一个图形，一切都很好，你在这里真的不需要OOP。但是当你需要在不同的区域显示几个图的时候，如果没有OOP和创建CCanvas的多个实例，就很难做到。
或者再举一个例子。最近，我被要求修改一个程序化的专家顾问，以便它可以同时在不同的符号上进行交易（在一个图表上运行）。程序化的风格将需要长期和复杂的努力，使其在同一时间在不同的符号上独立交易。相比之下，我只是将整个程序性代码放在一个类中，并创建了三个示例。我为他们每个人指定了一套单独的设置，包括工作符号等。这段代码在第一次尝试时就发挥了它应有的作用。用户很满意。
甚至你在你的内核中也在使用OOP。虽然你是暗地里这么做的。
在OOP术语中，你的每个内核都是一个类的实例。不管你怎么称呼它，它都是OOP的一个元素。但不幸的是，这个元素是自制的，在概念的力量上屈服于已经被成千上万的未经尝试的头脑发明和打磨过的东西。
Vasily，我明白为什么要把绘图功能做成一个类。因为除了它们之外，还有其他几组功能。
但我的问题有点不同。究竟为什么尼古拉要通过一个类来调用绘图函数，如果他不使用任何其他类的话。他只画画。
该问题的重点正是如此。
我强调了这种行为在逻辑上的无意义性，而且他并没有意识到这一点。
我还强调，按照要解决的任务的大小，使用OOP 往往是不合理的。毕竟，OOP需要一个分支分类，如果没有这样的分类，是否值得故意创造它？
问题是，开发者应该以机制的要求为指导，而不是工具。
彼得，在OOP中，类对象的创建是为了让你能够处理多个互不依赖的对象。当你用CCanvas工作时，你有一个图形，一切都很好，你在这里真的不需要OOP。但是当你需要在不同的区域显示几个图的时候，如果没有OOP和创建CCanvas的多个实例就很难做到。
或者再举一个例子。最近，我被要求修改一个程序化的专家顾问，以便它可以同时在不同的符号上进行交易（在一个图表上运行）。程序化的风格将需要长期和复杂的努力，使其在同一时间在不同的符号上独立交易。相比之下，我只是将整个程序性代码放在一个类中，并创建了三个示例。我为他们每个人指定了一套单独的设置，包括工作符号等。这段代码在第一次尝试时就发挥了它应有的作用。用户很满意。
甚至你在你的内核中也在使用OOP。虽然你是暗地里这么做的。
在OOP术语中，你的每个内核都是一个类的实例。不管你怎么称呼它，它都是OOP的一个元素。但不幸的是，这个元素是自制的，在概念的力量上屈服于已经被成千上万的无能的头脑发明和打磨过的东西。
你在浪费你的时间。首先，你和珀斯的顾问的例子是一个膏药--他不会写专家，他不明白有什么，有什么意义，他不能理解你非常清楚的例子--你会看到，他，眨着眼睛，会告诉你和他告诉尼古拉一样的事情。其次，你会给他一个借口，把他的鼻子推得更高，说他在自己的桶里做了一个超级独特的代码，没有得到成千上万的前人的帮助，有一个比以前任何解决方案都好的杰出解决方案。你会看到--这正是他将用滑块定位他独特的桶的方式......
我可能说得很难听，但我很少容忍不可逾越的愚蠢行为。
在OOP术语中，你的每个内核都是一个类的实例。而且不管你怎么称呼它，它都是OOP的一个元素。但不幸的是，这个元素是自制的，在概念的力量上屈服于已经被成千上万的无能的头脑发明和打磨过的东西。
因此，它是。但是，仍然有显著的区别。就我而言，在彼得家--在这个阶级的典范--几乎什么都有。而这并不符合OOP的封装范式。另外，还有全局变量。
所以在这里--只有 "OOP的元素"。
但是，我担心，人们不会喜欢相反的情况--我确信，Vasily，当我推出我的OOP-项目时，相反的，人们会尖叫 "你不能用这个界面做任何事情，除了它的目的":)
事实证明，每当你制作一个新的gui时，你必须对引擎进行修改（为它配备适当的GUI内核）。我认为这是一个根本性的错误解决方案。想象一下，你的引擎有数百个用户。但托管在市场或其他地方的引擎只是一个。在这种情况下，你将如何做？对于每个用户来说，放置一个特定的引擎，他必须为自己下载？你是如何为引擎准备gui核心的？你会为每个用户提供一个单独的引擎吗？- 这将很快成为一场恶梦。因此，你的解决方案是不可扩展的。
不，瓦西里，你倾向于把一切都戏剧化）。
在设计器中有一个按钮，点击后可以打印出所有的文件。
而引擎将从一个文本文件中加载内核。这并不难做到。
彼得，你真的误解了一些关于OOP的应用。
这是一种特殊的意识形式，不要阻止它的发展。