学童的EOP。 - 页 4 1234567891011...18 新评论 Ivan Butko 2019.10.04 10:13 #31 Dmitry Fedoseev: 不，他们（小学生）不会理解。特别是没有某种矩阵。他们会说：为什么我们需要这种多态性......。某种多态性？ 聚什么... Dmitry Fedoseev 2019.10.04 10:14 #32 Ihor Herasko: 胡说什么呢？打开获取器 的定义并 阅读。 但检索私人数据的机制可能是不同的。在C#中是一种方式，在C++和MQL中是另一种方式。但这并没有剥夺方法的 "getter "定义。 这里我们读到 "特殊 "方法。 Реter Konow 2019.10.04 10:14 #33 Dmitry Fedoseev: 这只是不方便 - 你需要知道哪个元素有x，哪个元素有y。使用结构时，一切都很清楚，而且可以消除错误，减少代码量。 在这种情况下（比方说），结构是作为一种语法技术使用的，当访问它的数据时，你需要乘以实例，而不是数组，这就平衡了不便。 使用该结构的意义更深，但TC仅以这种方式呈现。事实证明--OOP是一套句法技术。这就是 "学童 "要学习的东西。然后他们会明白，他们可以在任务中简化语法，并开始否定OOP。 我们需要从概念上证明OOP的必要性，而不是语法上的证明。 Ivan Butko 2019.10.04 10:15 #34 谢谢你的分行。我喜欢它。 Ihor Herasko 2019.10.04 10:17 #35 Dmitry Fedoseev: 这里我们读到了 "特殊 "的方法。 再往下翻一点，阅读这篇文章。没有MQL，但有C++。或者在C++中也没有获取器？ Dmitry Fedoseev 2019.10.04 10:19 #36 Реter Konow: 在这种情况下，（比方说）结构被用作一种语法技术，当访问它的数据时，你必须乘以实例，这与数组不同，它平衡了不便之处。 使用该结构的意义更深，但TC仅以这种方式呈现。事实证明--OOP是一套句法技术。这就是 "学童 "要学习的东西。然后他们会明白，他们可以在任务中简化语法，并开始否定OOP。 你需要一个概念上的证明，证明OOP是必要的，但不是一个语法上的证明。 你不需要让任何东西受精。它的工作方式与普通的数组一样，只是更加方便。 概念性证明...那么它也需要在制砖领域...到直接用粘土涂抹墙壁更方便，并试图证明它不是这样。 Dmitry Fedoseev 2019.10.04 10:21 #37 Ihor Herasko: 在文章中再滚动一下。没有MQL，但有C++。或者在C++中也没有获取器？ 我甚至还没有打开这篇文章。我应该在那里看到什么呢？C++与此有什么关系？ Реter Konow 2019.10.04 10:32 #38 Dmitry Fedoseev: 没有必要乘以任何东西。工作起来就像普通的阵列，只是一切都更方便了。 概念性证明...那么它也需要在制砖领域...直接用粘土涂抹墙壁更方便，并试图证明它不是这样。 数据操作中对OOP的需求。我重复一遍--有数据。 OOP帮助你分配数据并组织对数据的访问。你需要类和结构来实现这一点。 在一个坐标任务中，数据太少，因此不需要结构和类。如果你扩大任务规模，将许多类型的数据 带入其 "领域"，就需要进行分类。然后课程和结构将随之而来。 没有分类的需要，就没有上课的需要。没有结构化的需要，就没有结构的需要。 如果没有由不同对象联合起来的各种数据--在OOP中就没有必要。 把OOP放到有单调数据的平面程序中，即使在训练中也是有害的，因为概念是错误的。人们开始认为，OOP是一套语法技巧，他们随心所欲地使用它。在必要和不需要的地方。 Dmitry Fedoseev 2019.10.04 10:37 #39 Реter Konow: 1.在数据处理方面需要一个OOP。再次，用数据说话。 OOP帮助你轻松地分配和访问数据。这需要类和结构。 2.在一个坐标任务中，数据太少，因此不需要结构和类。如果你扩大任务规模并将许多类型的数据 引入其 "领域"，就需要进行分类。接下来将是课程和结构。 没有分类的需要，就没有上课的需要。没有结构化的需要，就没有结构的需要。 3.如果没有不同对象的各种数据的联合，就没有必要在OOP中。 把OOP放到有单调数据的平面程序中，即使在训练中也是有害的，因为概念的暴露是错误的。人们开始认为OOP是一套语法，他们随心所欲地使用它。他们应该和不应该的地方。 1.空谈。所有的编程，无一例外，都是关于数据的工作。 2.协调任务本身没有多少数据，但如果有大量的工作，就会比较容易。不要在OOP中寻找史诗般的东西。它是一种将数据和处理它们的方法分组的方式，也是一种重复使用代码的方式。 3.任何流形，如果能在其中区分出独立的种群，就能被划分为类，就会很好。 Koldun Zloy 2019.10.04 10:47 #40 Реter Konow: 好了，让我们继续讨论代码。 其目的是什么？- 为了方便地存储点的坐标。为了什么？- 对于快速访问。 如果任务只是为了快速访问数据，那么POINT结构及其实例在解决方案中是不必要的实体。 看看通过矩阵的访问是多么容易。 你说你不是哲学家，但 "结构 "是一个哲学概念，它在解决方案中的存在必须有理由。 对你来说，叫："1号手 "和 "2号手 "可能更容易，但大多数人更愿意叫他们 "左 "和 "右"。 1234567891011...18 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
不，他们（小学生）不会理解。特别是没有某种矩阵。他们会说：为什么我们需要这种多态性......。某种多态性？
聚什么...
胡说什么呢？打开获取器 的定义并 阅读。
但检索私人数据的机制可能是不同的。在C#中是一种方式，在C++和MQL中是另一种方式。但这并没有剥夺方法的 "getter "定义。这里我们读到 "特殊 "方法。
这只是不方便 - 你需要知道哪个元素有x，哪个元素有y。使用结构时，一切都很清楚，而且可以消除错误，减少代码量。
在这种情况下（比方说），结构是作为一种语法技术使用的，当访问它的数据时，你需要乘以实例，而不是数组，这就平衡了不便。
使用该结构的意义更深，但TC仅以这种方式呈现。事实证明--OOP是一套句法技术。这就是 "学童 "要学习的东西。然后他们会明白，他们可以在任务中简化语法，并开始否定OOP。
我们需要从概念上证明OOP的必要性，而不是语法上的证明。
这里我们读到了 "特殊 "的方法。
再往下翻一点，阅读这篇文章。没有MQL，但有C++。或者在C++中也没有获取器？
在这种情况下，（比方说）结构被用作一种语法技术，当访问它的数据时，你必须乘以实例，这与数组不同，它平衡了不便之处。
使用该结构的意义更深，但TC仅以这种方式呈现。事实证明--OOP是一套句法技术。这就是 "学童 "要学习的东西。然后他们会明白，他们可以在任务中简化语法，并开始否定OOP。
你需要一个概念上的证明，证明OOP是必要的，但不是一个语法上的证明。
你不需要让任何东西受精。它的工作方式与普通的数组一样，只是更加方便。
概念性证明...那么它也需要在制砖领域...到直接用粘土涂抹墙壁更方便，并试图证明它不是这样。
在文章中再滚动一下。没有MQL，但有C++。或者在C++中也没有获取器？
我甚至还没有打开这篇文章。我应该在那里看到什么呢？C++与此有什么关系？
没有必要乘以任何东西。工作起来就像普通的阵列，只是一切都更方便了。
概念性证明...那么它也需要在制砖领域...直接用粘土涂抹墙壁更方便，并试图证明它不是这样。
数据操作中对OOP的需求。我重复一遍--有数据。
OOP帮助你分配数据并组织对数据的访问。你需要类和结构来实现这一点。
在一个坐标任务中，数据太少，因此不需要结构和类。如果你扩大任务规模，将许多类型的数据 带入其 "领域"，就需要进行分类。然后课程和结构将随之而来。
没有分类的需要，就没有上课的需要。没有结构化的需要，就没有结构的需要。
如果没有由不同对象联合起来的各种数据--在OOP中就没有必要。
把OOP放到有单调数据的平面程序中，即使在训练中也是有害的，因为概念是错误的。人们开始认为，OOP是一套语法技巧，他们随心所欲地使用它。在必要和不需要的地方。
1.在数据处理方面需要一个OOP。再次，用数据说话。
OOP帮助你轻松地分配和访问数据。这需要类和结构。
2.在一个坐标任务中，数据太少，因此不需要结构和类。如果你扩大任务规模并将许多类型的数据 引入其 "领域"，就需要进行分类。接下来将是课程和结构。
没有分类的需要，就没有上课的需要。没有结构化的需要，就没有结构的需要。
3.如果没有不同对象的各种数据的联合，就没有必要在OOP中。
把OOP放到有单调数据的平面程序中，即使在训练中也是有害的，因为概念的暴露是错误的。人们开始认为OOP是一套语法，他们随心所欲地使用它。他们应该和不应该的地方。
1.空谈。所有的编程，无一例外，都是关于数据的工作。
2.协调任务本身没有多少数据，但如果有大量的工作，就会比较容易。不要在OOP中寻找史诗般的东西。它是一种将数据和处理它们的方法分组的方式，也是一种重复使用代码的方式。
3.任何流形，如果能在其中区分出独立的种群，就能被划分为类，就会很好。好了，让我们继续讨论代码。
其目的是什么？- 为了方便地存储点的坐标。为了什么？- 对于快速访问。
如果任务只是为了快速访问数据，那么POINT结构及其实例在解决方案中是不必要的实体。 看看通过矩阵的访问是多么容易。
你说你不是哲学家，但 "结构 "是一个哲学概念，它在解决方案中的存在必须有理由。
对你来说，叫："1号手 "和 "2号手 "可能更容易，但大多数人更愿意叫他们 "左 "和 "右"。