给OOP专家的一个问题。 - 页 5 123456789101112...55 新评论 Реter Konow 2019.08.25 16:16 #41 Artyom Trishkin: 所有的列表都已经配备了二进制搜索。这并不意味着逐一浏览列表，而是通过搜索的属性进行过滤。结果是，我们得到了我们正在寻找的项目的索引。 这些列表是否附在OOP内部的任何东西上？也就是说，他们携带的是什么 "货物"？类、构造函数、接口...？他们已经融入了班级环境，不是吗？ Реter Konow 2019.08.25 16:17 #42 Nikolai Semko: 当一个类对象被创建时，除了为该类的所有属性（变量）分配内存 外，还会启动一个构造函数（可能不止一个）。 构造函数可以是非参数化的（默认），参数化的（当创建一个类的实例时指定了一些参数，或者是一个复制构造函数，当另一个类的实例被指定为一个类的实例的参数。 我明白了，谢谢你，尼古拉。我会注意的。 Igor Makanu 2019.08.25 16:18 #43 Реter Konow: 我已经公开解决了这项任务。我们的想法是创建一个包含所有符号和所有时间段的表格，并通过它进行循环，固定一个新条的事件。在第一次调用该事件的任何函数后，其标志将从表中删除。我无法判断它比OOP中复杂多少。但是，事实上，相当简单和方便的解决方案。 如你所写，一切都是相对的....。使用片段中的最后一个镜头... 你看过MT交付的标准库 吗？ 它都是OOP风格，这里有两个选择，要么Metakvot的程序员是专业人士，使用可理解的风格，要么...你的版本;) Реter Konow 2019.08.25 16:33 #44 Igor Makanu: 如你所写，一切都是相对的....。使用片段中的最后一个镜头... 你看过MT交付的标准库 吗？ 它都是OOP风格，这里有两个选择，要么Metakvot的程序员是专业人士，使用可理解的风格，要么...你的版本;) 我对OOP还不是很精通。他们告诉我名单，但我不知道他们在用什么 "吃"。它们如何被宣布，如何被访问，如何被改变，等等。对我来说，列表只是一个动态数组，没有任何额外的语法。一个对象是一个数组中的一组属性。而在OOP中，对象是一个完整的类。继承--对象的链接。通过命名的引用来访问对象的属性。因此，在我的情况下，一切都要简单得多，因此我发现很难比较功能和效率。我需要更深入地了解它。 但有一件事我已经学会了。如果不了解整个OOP并完全转换到它，你就无法理解和使用OOP概念中的任何一个实体。它要么是OOP，要么是你想要的任何东西。仅仅使用它的一个方便的机制可能是不行的。 Igor Makanu 2019.08.25 16:43 #45 Реter Konow: 简单地使用它的一个方便的机制可能不会奏效。 OOP可以毫无问题地与程序化风格共存，但函数必须是完全独立的代码块，也就是说，函数使用的所有东西都必须在其中或作为参数传递给它。 一般来说，正如他们在Wiki中写的那样，OOP是程序性风格的延伸。 Retag Konow: 但有一件事我已经明白了。如果不了解整个OOP，不完全去了解它，你就无法理解和使用OOP概念中的任何一个实体。 你可以，我举了一个例子，在论坛上，90%的OOP风格的资料都是程序化风格的包装--没有继承，没有抽象，没有.....，只有封装，但无论如何，它至少是方便的--有一段完全可以转移到另一个任务的代码是很方便的--毕竟一切都在一个类里面？;) Реter Konow 2019.08.25 16:52 #46 Igor Makanu: 与OOP程序化风格相比没有问题，但函数必须是完全独立的代码块，也就是说，函数使用的所有东西都必须在其中，或者作为参数传递给它。 一般来说，正如他们在Wiki中写的那样，OOP是程序化风格的延伸。 你可以，我举了一个例子，在论坛上，90%的OOP风格的资料都是程序化风格的包装--没有继承，没有抽象，没有.....，只有封装，但至少还是很方便的--有一个完全可移植的代码块用于另一个任务是很方便的--一切都在一个类里面，对吧？;) 是的，代码可移植性是OOP的一大优点。在我的案例中，只有个别函数是可移植的（而且只是很少），但当我建立一个大的机制时，没有什么是可移植的。就像人体器官是不能转移的（没有专业干预）。我的机制更像 "生物体"，因为它们被分成大块，每块都执行一系列的任务。因此，可移植性几乎是不存在的。然而，这些块很容易扩展其功能。你只需 "添加 "几行，就可以了。- 块执行整层的新工作，你必须为其编写许多单独的函数。总而言之，是有好处的。 嗯，全局范围是一个令人难以置信的强大工具。区块工作的材料对他们来说是绝对可用的，没有必要转移任何东西。工作所需的一切都已经在那里了。总而言之，这些方法是不同的，各有各的优势。 Georgiy Merts 2019.08.25 16:54 #47 Реter Konow: 我对OOP还不是很了解。他们告诉我名单，我不知道他们是 "用什么吃的"。它们如何被声明，如何被访问，如何被改变，等等。对我来说，列表只是一个动态数组，没有任何额外的语法。一个对象是一个数组中的一组属性。而在OOP中，对象是一个完整的类。继承--对象的链接。通过命名的引用来访问对象的属性。因此，在我的情况下，一切都要简单得多，因此我发现很难比较功能和效率。我得更深入地研究它。 但是我学到了一件事。如果不了解整个OOP，不彻底地去了解它，你就无法理解和使用OOP概念中的任何一个实体。 它要么是OOP，要么是你想要的任何东西。仅仅使用它的一个方便的机制可能是不行的。 彼得，你一定要试试。我建议在列表结构上进行尝试，因为在那里你可以看到OOP在三个方面的所有优势--继承、封装和多态性。 由于继承的关系，你有一个单一的接口（一组虚拟函数）来处理列表内的对象。对象可以是简单的，也可以是复杂的，从基地继承下来。 通过多态性--你可以用这个单一的接口来处理根本不同的对象。 由于封装的原因--你只有这个接口，而不能接触到任何实现的细节--因此，你不能把事情搞砸。此外，你不仅清楚地知道现在的那些对象是如何工作的，而且知道那些还没有写的对象将如何与你的代码互动。 Artyom Trishkin 2019.08.25 16:58 #48 Реter Konow: 这些清单是否附属于OOP内的任何东西？我的意思是，他们带着什么 "负荷"？类、构造函数、接口...？他们已经融入了班级环境，不是吗？ 本质上--列表非常接近于数组。你可以把它声明为一个列表类型的变量，或者通过new操作符 创建一个新的变量。但在新的情况下，列表不受终端子系统的控制，必须始终在工作结束后删除 - 删除。但如果这样的列表被添加到另一个列表中作为一个对象，则不需要被监控。 Igor Makanu 2019.08.25 17:03 #49 Реter Konow: 嗯，全局范围是一个令人难以置信的强大工具。区块工作的材料对他们来说是绝对可用的，没有必要转移任何东西。你需要的一切工作都已经在那里了。 当涉及到要用作函数或代码部分参数的变量的全局范围 时，那么....我认为，这是得到一个完全不可传送的代码的最好方法，有可能得到后来不可能发现的隐藏的错误。 SZZ：我为MT4 EAs修改过很多次这样的代码，一开始我给全局声明的变量重新命名--然后在看到编译器错误时做了修改，但最后一次我做得很正确--我给函数签名添加了新的参数，然后我删除了全局声明的变量，因为如果你设法修改了一次这种可恶的代码，你将不得不重新做一遍？- 唉，我很懒，但还算懒)))))。 Реter Konow 2019.08.25 17:58 #50 Igor Makanu: 当涉及到要用作函数或代码部分参数的变量的全局范围 时，那么.... 我认为，这是得到一个完全不可传送的代码的最好方法，有可能得到后来不可能发现的隐藏的错误。 SZZ：我为MT4 EAs修改过很多次这样的代码，一开始我给全局声明的变量重新命名--然后在看到编译器错误时做了修改，但最后一次我做得很正确--我给函数签名添加了新的参数，然后我删除了全局声明的变量，因为如果你设法修改了一次这种可恶的代码，你将不得不重新做一遍？- 唉，我是个懒人，但也算得上是懒人)))))。 代码是不可移植的，所以这就是它的特殊之处。它的目的不是要让人携带。它有另一个目的。那么，变量的全局范围是处理复杂机制的有力工具。你只需要知道如何使用它。当人们告诉我隐藏的错误和bug时，我感到很困惑。我从来没有遇到过任何与全局变量可见性有关的错误。一句话，完全没有。 123456789101112...55 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
所有的列表都已经配备了二进制搜索。这并不意味着逐一浏览列表，而是通过搜索的属性进行过滤。结果是，我们得到了我们正在寻找的项目的索引。
当一个类对象被创建时，除了为该类的所有属性（变量）分配内存 外，还会启动一个构造函数（可能不止一个）。 构造函数可以是非参数化的（默认），参数化的（当创建一个类的实例时指定了一些参数，或者是一个复制构造函数，当另一个类的实例被指定为一个类的实例的参数。
我已经公开解决了这项任务。我们的想法是创建一个包含所有符号和所有时间段的表格，并通过它进行循环，固定一个新条的事件。在第一次调用该事件的任何函数后，其标志将从表中删除。我无法判断它比OOP中复杂多少。但是，事实上，相当简单和方便的解决方案。
如你所写，一切都是相对的....。使用片段中的最后一个镜头...
你看过MT交付的标准库 吗？ 它都是OOP风格，这里有两个选择，要么Metakvot的程序员是专业人士，使用可理解的风格，要么...你的版本;)
如你所写，一切都是相对的....。使用片段中的最后一个镜头...
你看过MT交付的标准库 吗？ 它都是OOP风格，这里有两个选择，要么Metakvot的程序员是专业人士，使用可理解的风格，要么...你的版本;)
我对OOP还不是很精通。他们告诉我名单，但我不知道他们在用什么 "吃"。它们如何被宣布，如何被访问，如何被改变，等等。对我来说，列表只是一个动态数组，没有任何额外的语法。一个对象是一个数组中的一组属性。而在OOP中，对象是一个完整的类。继承--对象的链接。通过命名的引用来访问对象的属性。因此，在我的情况下，一切都要简单得多，因此我发现很难比较功能和效率。我需要更深入地了解它。
但有一件事我已经学会了。如果不了解整个OOP并完全转换到它，你就无法理解和使用OOP概念中的任何一个实体。它要么是OOP，要么是你想要的任何东西。仅仅使用它的一个方便的机制可能是不行的。
简单地使用它的一个方便的机制可能不会奏效。
OOP可以毫无问题地与程序化风格共存，但函数必须是完全独立的代码块，也就是说，函数使用的所有东西都必须在其中或作为参数传递给它。
一般来说，正如他们在Wiki中写的那样，OOP是程序性风格的延伸。
但有一件事我已经明白了。如果不了解整个OOP，不完全去了解它，你就无法理解和使用OOP概念中的任何一个实体。
你可以，我举了一个例子，在论坛上，90%的OOP风格的资料都是程序化风格的包装--没有继承，没有抽象，没有.....，只有封装，但无论如何，它至少是方便的--有一段完全可以转移到另一个任务的代码是很方便的--毕竟一切都在一个类里面？;)
与OOP程序化风格相比没有问题，但函数必须是完全独立的代码块，也就是说，函数使用的所有东西都必须在其中，或者作为参数传递给它。
一般来说，正如他们在Wiki中写的那样，OOP是程序化风格的延伸。
你可以，我举了一个例子，在论坛上，90%的OOP风格的资料都是程序化风格的包装--没有继承，没有抽象，没有.....，只有封装，但至少还是很方便的--有一个完全可移植的代码块用于另一个任务是很方便的--一切都在一个类里面，对吧？;)
是的，代码可移植性是OOP的一大优点。在我的案例中，只有个别函数是可移植的（而且只是很少），但当我建立一个大的机制时，没有什么是可移植的。就像人体器官是不能转移的（没有专业干预）。我的机制更像 "生物体"，因为它们被分成大块，每块都执行一系列的任务。因此，可移植性几乎是不存在的。然而，这些块很容易扩展其功能。你只需 "添加 "几行，就可以了。- 块执行整层的新工作，你必须为其编写许多单独的函数。总而言之，是有好处的。 嗯，全局范围是一个令人难以置信的强大工具。区块工作的材料对他们来说是绝对可用的，没有必要转移任何东西。工作所需的一切都已经在那里了。总而言之，这些方法是不同的，各有各的优势。
我对OOP还不是很了解。他们告诉我名单，我不知道他们是 "用什么吃的"。它们如何被声明，如何被访问，如何被改变，等等。对我来说，列表只是一个动态数组，没有任何额外的语法。一个对象是一个数组中的一组属性。而在OOP中，对象是一个完整的类。继承--对象的链接。通过命名的引用来访问对象的属性。因此，在我的情况下，一切都要简单得多，因此我发现很难比较功能和效率。我得更深入地研究它。
但是我学到了一件事。如果不了解整个OOP，不彻底地去了解它，你就无法理解和使用OOP概念中的任何一个实体。 它要么是OOP，要么是你想要的任何东西。仅仅使用它的一个方便的机制可能是不行的。
彼得，你一定要试试。我建议在列表结构上进行尝试，因为在那里你可以看到OOP在三个方面的所有优势--继承、封装和多态性。
由于继承的关系，你有一个单一的接口（一组虚拟函数）来处理列表内的对象。对象可以是简单的，也可以是复杂的，从基地继承下来。
通过多态性--你可以用这个单一的接口来处理根本不同的对象。
由于封装的原因--你只有这个接口，而不能接触到任何实现的细节--因此，你不能把事情搞砸。此外，你不仅清楚地知道现在的那些对象是如何工作的，而且知道那些还没有写的对象将如何与你的代码互动。
这些清单是否附属于OOP内的任何东西？我的意思是，他们带着什么 "负荷"？类、构造函数、接口...？他们已经融入了班级环境，不是吗？
嗯，全局范围是一个令人难以置信的强大工具。区块工作的材料对他们来说是绝对可用的，没有必要转移任何东西。你需要的一切工作都已经在那里了。
当涉及到要用作函数或代码部分参数的变量的全局范围 时，那么....我认为，这是得到一个完全不可传送的代码的最好方法，有可能得到后来不可能发现的隐藏的错误。
SZZ：我为MT4 EAs修改过很多次这样的代码，一开始我给全局声明的变量重新命名--然后在看到编译器错误时做了修改，但最后一次我做得很正确--我给函数签名添加了新的参数，然后我删除了全局声明的变量，因为如果你设法修改了一次这种可恶的代码，你将不得不重新做一遍？- 唉，我很懒，但还算懒)))))。
当涉及到要用作函数或代码部分参数的变量的全局范围 时，那么.... 我认为，这是得到一个完全不可传送的代码的最好方法，有可能得到后来不可能发现的隐藏的错误。
SZZ：我为MT4 EAs修改过很多次这样的代码，一开始我给全局声明的变量重新命名--然后在看到编译器错误时做了修改，但最后一次我做得很正确--我给函数签名添加了新的参数，然后我删除了全局声明的变量，因为如果你设法修改了一次这种可恶的代码，你将不得不重新做一遍？- 唉，我是个懒人，但也算得上是懒人)))))。
代码是不可移植的，所以这就是它的特殊之处。它的目的不是要让人携带。它有另一个目的。那么，变量的全局范围是处理复杂机制的有力工具。你只需要知道如何使用它。当人们告诉我隐藏的错误和bug时，我感到很困惑。我从来没有遇到过任何与全局变量可见性有关的错误。一句话，完全没有。