OOP与程序化编程 - 页 11 1...456789101112131415161718...48 新评论 Georgiy Merts 2017.08.12 10:10 #101 Реter Konow:在我看来，你的问题解决系统中存在一个缺陷。问题本身应该是非常清晰和准确的，因此它的解决方案也是如此。如果解决方案是云里雾里的，并由 "该系统显示出非常合理 "这句话来定义（270kb的代码怎么可能合理呢！），这意味着作者大致了解他的系统如何工作。而正是解决方案中那些可怕的构思句法和多余的实体阻碍了他理解到最后。 合理性在于 "预测能力"--工作规程的重大改变不需要改变负责工作逻辑的专家的守则。代码的修改只是在直接处理终端的低层次的地方。所给的代码很好地展示了所有的OOP-黑客是如何被 "功能黑客 "所取代的。这正是我在上面所说的--它可以从两个方面来写。 但看了你的代码，我发现你必须在内存中保留更多的东西。说，在你的大多数如果中，我 "淹没 "在一瞬间。他们是正确的，但如果我不得不维护这段代码--我会在每个条件之前插入几行注释，说明这个检查是做什么的，为什么在数组中使用这些域。类似于在我的代码中声明 CTradePositionI 接口之前的评论。另外--复杂的条件--也会给我个人带来很大的压力。我个人会在你的代码中犯更多的错误，而且会更难抓住它们。也就是说，尽管这样的代码是正确的、有逻辑的，但对我来说，维护它将比我用OOP风格写的代码更困难。 在OOP风格中，我会声明窗口、画布的一部分、元素、画布的接口，然后我会写出这些对象的真正的类，然后我会在正确的区块中给出这些接口的指针，并专门与这些实体一起工作，这在当时是需要的--其他一切在那时都是不可用的。这样你就不必记住什么属于什么，什么要负责什么。当你得到由几个功能组成的最简单的界面时，你只需用它来工作，其他的都是不必要的，你无法使用。你根本不需要记住什么。 Alexey Volchanskiy 2017.08.12 10:19 #102 George Merts:好吧，你把事情搞得一团糟......。很明显，任何任务都可以用OOP风格来解决，包括分配接口、建立继承层次、声明虚拟函数，也可以用纯程序风格来解决--你甚至可以把所有东西都放在一个巨大的函数中。 问题在于支持的便利和效率。在MT--最适合OOP的地方是订单系统。就个人而言，我有 "位置 "和 "位置组件 "的虚拟接口。"头寸 "在MT4中是一组订单，在MT5中是一组头寸。"头寸组成部分 "是指单个订单或单个MT5头寸（对冲或净值）。 这是实际的界面文件（Retag Konow，你可以欣赏到与代码量相比，注释的数量，当我遇到一些我不记得的微妙之处，我定期在那里添加注释。例如，我经常忘记哪些真实物体构成了 "位置组件"。我只是不需要记住它--专家顾问根据界面与组件一起工作，现实中界面后面是什么并不重要。但是，我必须在修改过程中回到它 - 这就是为什么我经常需要这个文件中的第一个注释）。贸易组件接口的文件如下（我已经在上面给出了，但我要重复一下。根据这些接口--我同时实现了MT4和MT5的订单系统，用于真实和历史订单。 专家顾问通过申请仓位收到这个界面，完全不必考虑MT4和MT5订单之间的区别。如果增加了一个新的订单类型，或者改变了与它们的工作顺序--对专家顾问来说不会有任何改变，只会增加新的订单类型类，它也将支持这个接口。 在引入对冲账户时，该系统被证明是非常聪明的。专家们--绝对不会因此而改变。 Reg Konow，你是如何处理MT4和MT5中订单类型的差异的？如果引入一个新的账户类型（除了套期保值和净额结算外）--需要做哪些改变，而且是在同一个地方？ 在我看来，真的，如果你把所有的代码都记得一清二楚，并且可以很容易地说出一年前为什么要在你的代码中写这一行或那一行--那么，真的，所有这些OOP增强器都只是不必要的姿态。 恰恰是当你在修改代码时不记得所有的东西时，OOP是必要的--OOP允许你将块相互隔离，以限制在任何特定时刻可用的实体集在程序中的特定位置。 乔治，你有时会写这样一个关于女性的诊所，但尊重代码))))。 Реter Konow 2017.08.12 10:33 #103 George Merts:合理性在于 "预测能力"--操作规程的重大改变--并不要求改变负责其操作逻辑的EA代码。代码修改只在直接处理终端的低层地方进行。所给的代码很好地展示了所有的OOP-黑客是如何被 "功能黑客 "所取代的。这正是我在上面所说的--它可以从两个方面来写。 但看了你的代码，我发现你必须在内存中保留更多的东西。说，在你的大多数如果中，我 "淹没 "在一瞬间。他们是正确的，但如果我不得不维护这段代码--我会在每个条件之前插入几行注释，说明这个检查是做什么的，为什么在数组中使用这些域。类似于在我的代码中声明 CTradePositionI 接口之前的评论。另外--复杂的条件--也会给我个人带来很大的压力。我个人会在你的代码中犯更多的错误，而且会更难抓住它们。也就是说，对于这样的代码的正确性和逻辑性来说，对我来说，维护它将比我用OOP风格写的代码更困难。 在OOP风格中，我会声明窗口、画布的一部分、元素、画布的接口，然后我会写出这些对象的真正的类，然后我会在正确的区块中给出这些接口的指针，并专门与这些实体一起工作，这在当时是需要的--其他一切在那时都是不可用的。这样你就不必记住什么属于什么，什么要负责什么。当你得到由几个功能组成的最简单的界面时，你只需用它来工作，其他的都是不必要的，你无法使用。你根本不需要记住任何东西。在我的代码中，大量的字体和它们的嵌套是由于不同的控制定义在不同的事件和不同的状态下的复杂行为。然而，这个功能涵盖了所有这些选项，完全 "服务 "于整个GUI。当重绘任何元素时，部件的颜色由内核中的原始颜色值 和这个函数决定。 P.S. 关于OOP或程序性风格，那么--"各取所需"（c）。 Georgiy Merts 2017.08.12 11:14 #104 Alexey Volchanskiy: 乔治，你有时会写这样一个关于女性的诊所，但要尊重代码））。关于代码--我受宠若惊。(真的，不开玩笑）。而关于小鸡...我不像你那样是个卡萨诺瓦...我是一个忍气吞声的人，不说自己的想法......我在这方面一直有而且仍然有很多问题，尽管舒适的个人生活对我来说一直很重要......。好在有时运气向我微笑，毕竟有一些东西可以记住。 Alexey Volchanskiy 2017.08.12 16:42 #105 George Merts:关于代码--我受宠若惊。(真的，不开玩笑）。而关于女人...我不像你那样是个卡萨诺瓦......我是一个忍气吞声，不说自己想法的人......我在这方面一直有而且仍然有很多问题，尽管舒适的个人生活对我来说一直很重要......。好在有时运气向我微笑，毕竟有一些东西可以记住。 只是我们对女性的态度不同。我认为他们应该得到帮助。是的，他们是任性的，有自己的争论，善变的偏好，等等。你只要不把它们当回事，否则就会出现道德悲剧。 Dmitry Fedoseev 2017.08.12 16:53 #106 George Merts:好吧，你把事情搞得一团糟......。很明显，任何任务都可以用OOP风格来解决，包括分配接口、建立继承层次、声明虚拟函数，也可以用纯程序风格来解决--你甚至可以把所有东西都放在一个巨大的函数中。 问题在于支持的便利和效率。 我们可以做到这一点，但操作的效率各不相同。我们在这里谈的不是支持，这太相对了。有一些任务在程序上无法以最佳方式解决。 Dmitry Fedoseev 2017.08.12 16:55 #107 Alexey Volchanskiy: 我们只是对女性有不同的态度。我认为他们应该得到帮助。是的，他们脾气暴躁，有自己的怪癖，喜好无常，等等。你只要不把它们当回事，否则就会出现道德悲剧。阿列克谢，你有没有做过一个实验，女人的求助欲望有多无止境？你是否遇到了满意的帮助，持续了多长时间？ Alexey Navoykov 2017.08.12 17:34 #108 Реter Konow: 我认为你甚至不使用结构来存储数据？你的多维 数组勾起了对古老的MQL4的回忆，在那里你不得不使用这样的解决方案，因为缺乏结构。但现在有什么意义呢？比如说 int Элемент = G_CORE[Окно][Деталь_полотна][_MAIN_ELEMENT]; int Состояние_детали = G_CORE[Окно][Элемент][_CURRENT_STATE]; 你可以把它换成 int Элемент = G_CORE[Окно][Деталь_полотна].MAIN_ELEMENT; int Состояние_детали = G_CORE[Окно][Элемент].CURRENT_STATE; 这样做更短、更安全、更快速。在第一种情况下，在编译阶段对你传递给它的那些数组索引值没有控制。然后你必须在运行时清理各种 "数组超出范围 "的情况--而这充其量是一种情况。更糟糕的是当指数可以接受但不正确时。这就是为什么良好的编程实践是尽可能地让编译器参与进来，在编译阶段检测错误，而不是像你的情况那样在运行时捕捉错误。是的，现在你很好地记住了要把什么价值喂给哪里。但这可能是因为你一直在为这个项目忙碌。试着休息一下，比如说，六个月，你会感觉到不同。有些人已经提到了这一点。还是你认为我们都是硬化症患者还是什么？:)对于一个程序员来说，这是一件很平常的事情...因此，我们的任务是最大限度地减少向自己开枪的概率。我强烈建议你使用enum而不是无处不在的int来创建你自己的类型。而且它们不一定要有枚举值，最主要的是它是一个独立的类型，它将由编译器控制，不允许你交换函数参数等。 Yuriy Asaulenko 2017.08.12 17:39 #109 我只写而且只写OOP。早在20世纪，我就无法入手--Pascal 6.0，然后是Borland C++ 4.5。但当我掌握了它，我无法想象其他的东西--它就是这么简单和方便。 Реter Konow 2017.08.12 17:54 #110 Alexey Navoykov:我认为你甚至不使用结构来存储数据？你的多维 数组勾起了对古老的MQL4的回忆，在那里你不得不使用这样的解决方案，因为缺乏结构。但现在有什么意义呢？比如说你可以把它换成这样做更短、更安全、更快速。在第一种情况下，在编译阶段对你传递给它的那些数组索引值没有控制。然后你必须在运行时清理各种 "数组超出范围 "的情况--而这充其量是一种情况。更糟糕的是当指数可以接受但不正确时。这就是为什么良好的编程实践是尽可能地让编译器参与进来，在编译阶段检测错误，而不是像你的情况那样在运行时捕捉错误。是的，现在你很好地记住了要把什么价值喂给哪里。但这可能是因为你一直在为这个项目忙碌。试着休息一下，比如说，休息半年，感受一下差异。有些人已经提到了这一点。还是你认为我们都是硬化症患者还是什么？:)对于一个程序员来说，这是一件很平常的事情...因此，我们的任务是最大限度地减少向自己开枪的概率。我强烈建议你使用enum而不是无处不在的int来创建你自己的类型。而且它们不一定要有枚举值，最主要的是它是一个独立的类型，它将由编译器控制，不允许你交换函数参数等。我读了你在其他主题上的帖子，发现你是个编程方面的大专家。当然，我不是，也不声称自己是这样。然而，我认为自己是解决此类任务的专家。那么，你不同意解决方案的有效性是最重要的事情吗？ 语法的重载和规则的复杂性从未有助于保持解决方案的效率。这是在代码块的简洁性、普遍性和可读性方面所表现出来的简单和简短。 我在编程方面的规则是以使用母语和有意义的变量和函数名称为代价，减少代码、减少规则、减少语法和减少注释。 我的主要论点是 "如果你能在解决方案中不使用某些东西，你肯定应该不使用它"。 我认为这里根本就没有硬化的人））。仅仅看一下给定的代码，就会明白为什么它们容易被遗忘。甚至用外语编程这一事实本身也起了作用。当你用自己的语言编程时，感觉绝对不同。你感到力量和自由，而不是紧张和束缚。一门外语需要更多的努力，需要更多的时间来进入代码，并更快地从你的头脑中滑落。这只是一个 "生物因素"。 因此，我认为（相当合理地）使用一般的OOP来解决我的任务是低效的。大量的规则、句法和所有的外语。这样一来，人才就不能真正发展，这意味着结果会更差。 1...456789101112131415161718...48 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
在我看来，你的问题解决系统中存在一个缺陷。问题本身应该是非常清晰和准确的，因此它的解决方案也是如此。如果解决方案是云里雾里的，并由 "该系统显示出非常合理 "这句话来定义（270kb的代码怎么可能合理呢！），这意味着作者大致了解他的系统如何工作。而正是解决方案中那些可怕的构思句法和多余的实体阻碍了他理解到最后。
合理性在于 "预测能力"--工作规程的重大改变不需要改变负责工作逻辑的专家的守则。代码的修改只是在直接处理终端的低层次的地方。
所给的代码很好地展示了所有的OOP-黑客是如何被 "功能黑客 "所取代的。这正是我在上面所说的--它可以从两个方面来写。
但看了你的代码，我发现你必须在内存中保留更多的东西。说，在你的大多数如果中，我 "淹没 "在一瞬间。他们是正确的，但如果我不得不维护这段代码--我会在每个条件之前插入几行注释，说明这个检查是做什么的，为什么在数组中使用这些域。类似于在我的代码中声明 CTradePositionI 接口之前的评论。另外--复杂的条件--也会给我个人带来很大的压力。
我个人会在你的代码中犯更多的错误，而且会更难抓住它们。也就是说，尽管这样的代码是正确的、有逻辑的，但对我来说，维护它将比我用OOP风格写的代码更困难。
在OOP风格中，我会声明窗口、画布的一部分、元素、画布的接口，然后我会写出这些对象的真正的类，然后我会在正确的区块中给出这些接口的指针，并专门与这些实体一起工作，这在当时是需要的--其他一切在那时都是不可用的。这样你就不必记住什么属于什么，什么要负责什么。当你得到由几个功能组成的最简单的界面时，你只需用它来工作，其他的都是不必要的，你无法使用。你根本不需要记住什么。
好吧，你把事情搞得一团糟......。
很明显，任何任务都可以用OOP风格来解决，包括分配接口、建立继承层次、声明虚拟函数，也可以用纯程序风格来解决--你甚至可以把所有东西都放在一个巨大的函数中。
问题在于支持的便利和效率。
在MT--最适合OOP的地方是订单系统。就个人而言，我有 "位置 "和 "位置组件 "的虚拟接口。"头寸 "在MT4中是一组订单，在MT5中是一组头寸。"头寸组成部分 "是指单个订单或单个MT5头寸（对冲或净值）。
这是实际的界面文件（Retag Konow，你可以欣赏到与代码量相比，注释的数量，当我遇到一些我不记得的微妙之处，我定期在那里添加注释。例如，我经常忘记哪些真实物体构成了 "位置组件"。我只是不需要记住它--专家顾问根据界面与组件一起工作，现实中界面后面是什么并不重要。但是，我必须在修改过程中回到它 - 这就是为什么我经常需要这个文件中的第一个注释）。
贸易组件接口的文件如下（我已经在上面给出了，但我要重复一下。
根据这些接口--我同时实现了MT4和MT5的订单系统，用于真实和历史订单。
专家顾问通过申请仓位收到这个界面，完全不必考虑MT4和MT5订单之间的区别。如果增加了一个新的订单类型，或者改变了与它们的工作顺序--对专家顾问来说不会有任何改变，只会增加新的订单类型类，它也将支持这个接口。
在引入对冲账户时，该系统被证明是非常聪明的。专家们--绝对不会因此而改变。
Reg Konow，你是如何处理MT4和MT5中订单类型的差异的？
如果引入一个新的账户类型（除了套期保值和净额结算外）--需要做哪些改变，而且是在同一个地方？
在我看来，真的，如果你把所有的代码都记得一清二楚，并且可以很容易地说出一年前为什么要在你的代码中写这一行或那一行--那么，真的，所有这些OOP增强器都只是不必要的姿态。
恰恰是当你在修改代码时不记得所有的东西时，OOP是必要的--OOP允许你将块相互隔离，以限制在任何特定时刻可用的实体集在程序中的特定位置。
乔治，你有时会写这样一个关于女性的诊所，但尊重代码))))。
合理性在于 "预测能力"--操作规程的重大改变--并不要求改变负责其操作逻辑的EA代码。代码修改只在直接处理终端的低层地方进行。
所给的代码很好地展示了所有的OOP-黑客是如何被 "功能黑客 "所取代的。这正是我在上面所说的--它可以从两个方面来写。
但看了你的代码，我发现你必须在内存中保留更多的东西。说，在你的大多数如果中，我 "淹没 "在一瞬间。他们是正确的，但如果我不得不维护这段代码--我会在每个条件之前插入几行注释，说明这个检查是做什么的，为什么在数组中使用这些域。类似于在我的代码中声明 CTradePositionI 接口之前的评论。另外--复杂的条件--也会给我个人带来很大的压力。
我个人会在你的代码中犯更多的错误，而且会更难抓住它们。也就是说，对于这样的代码的正确性和逻辑性来说，对我来说，维护它将比我用OOP风格写的代码更困难。
在OOP风格中，我会声明窗口、画布的一部分、元素、画布的接口，然后我会写出这些对象的真正的类，然后我会在正确的区块中给出这些接口的指针，并专门与这些实体一起工作，这在当时是需要的--其他一切在那时都是不可用的。这样你就不必记住什么属于什么，什么要负责什么。当你得到由几个功能组成的最简单的界面时，你只需用它来工作，其他的都是不必要的，你无法使用。你根本不需要记住任何东西。
在我的代码中，大量的字体和它们的嵌套是由于不同的控制定义在不同的事件和不同的状态下的复杂行为。然而，这个功能涵盖了所有这些选项，完全 "服务 "于整个GUI。当重绘任何元素时，部件的颜色由内核中的原始颜色值 和这个函数决定。
P.S. 关于OOP或程序性风格，那么--"各取所需"（c）。
乔治，你有时会写这样一个关于女性的诊所，但要尊重代码））。
关于代码--我受宠若惊。(真的，不开玩笑）。
而关于小鸡...我不像你那样是个卡萨诺瓦...我是一个忍气吞声的人，不说自己的想法......我在这方面一直有而且仍然有很多问题，尽管舒适的个人生活对我来说一直很重要......。好在有时运气向我微笑，毕竟有一些东西可以记住。
关于代码--我受宠若惊。(真的，不开玩笑）。
而关于女人...我不像你那样是个卡萨诺瓦......我是一个忍气吞声，不说自己想法的人......我在这方面一直有而且仍然有很多问题，尽管舒适的个人生活对我来说一直很重要......。好在有时运气向我微笑，毕竟有一些东西可以记住。
只是我们对女性的态度不同。我认为他们应该得到帮助。是的，他们是任性的，有自己的争论，善变的偏好，等等。你只要不把它们当回事，否则就会出现道德悲剧。
好吧，你把事情搞得一团糟......。
很明显，任何任务都可以用OOP风格来解决，包括分配接口、建立继承层次、声明虚拟函数，也可以用纯程序风格来解决--你甚至可以把所有东西都放在一个巨大的函数中。
问题在于支持的便利和效率。
我们可以做到这一点，但操作的效率各不相同。我们在这里谈的不是支持，这太相对了。
有一些任务在程序上无法以最佳方式解决。
我们只是对女性有不同的态度。我认为他们应该得到帮助。是的，他们脾气暴躁，有自己的怪癖，喜好无常，等等。你只要不把它们当回事，否则就会出现道德悲剧。
阿列克谢，你有没有做过一个实验，女人的求助欲望有多无止境？你是否遇到了满意的帮助，持续了多长时间？
我认为你甚至不使用结构来存储数据？你的多维 数组勾起了对古老的MQL4的回忆，在那里你不得不使用这样的解决方案，因为缺乏结构。但现在有什么意义呢？比如说
你可以把它换成
这样做更短、更安全、更快速。在第一种情况下，在编译阶段对你传递给它的那些数组索引值没有控制。然后你必须在运行时清理各种 "数组超出范围 "的情况--而这充其量是一种情况。更糟糕的是当指数可以接受但不正确时。这就是为什么良好的编程实践是尽可能地让编译器参与进来，在编译阶段检测错误，而不是像你的情况那样在运行时捕捉错误。
是的，现在你很好地记住了要把什么价值喂给哪里。但这可能是因为你一直在为这个项目忙碌。试着休息一下，比如说，六个月，你会感觉到不同。有些人已经提到了这一点。还是你认为我们都是硬化症患者还是什么？:)对于一个程序员来说，这是一件很平常的事情...
因此，我们的任务是最大限度地减少向自己开枪的概率。我强烈建议你使用enum而不是无处不在的int来创建你自己的类型。而且它们不一定要有枚举值，最主要的是它是一个独立的类型，它将由编译器控制，不允许你交换函数参数等。
我只写而且只写OOP。
早在20世纪，我就无法入手--Pascal 6.0，然后是Borland C++ 4.5。但当我掌握了它，我无法想象其他的东西--它就是这么简单和方便。
我认为你甚至不使用结构来存储数据？你的多维 数组勾起了对古老的MQL4的回忆，在那里你不得不使用这样的解决方案，因为缺乏结构。但现在有什么意义呢？比如说
你可以把它换成
这样做更短、更安全、更快速。在第一种情况下，在编译阶段对你传递给它的那些数组索引值没有控制。然后你必须在运行时清理各种 "数组超出范围 "的情况--而这充其量是一种情况。更糟糕的是当指数可以接受但不正确时。这就是为什么良好的编程实践是尽可能地让编译器参与进来，在编译阶段检测错误，而不是像你的情况那样在运行时捕捉错误。
是的，现在你很好地记住了要把什么价值喂给哪里。但这可能是因为你一直在为这个项目忙碌。试着休息一下，比如说，休息半年，感受一下差异。有些人已经提到了这一点。还是你认为我们都是硬化症患者还是什么？:)对于一个程序员来说，这是一件很平常的事情...
因此，我们的任务是最大限度地减少向自己开枪的概率。我强烈建议你使用enum而不是无处不在的int来创建你自己的类型。而且它们不一定要有枚举值，最主要的是它是一个独立的类型，它将由编译器控制，不允许你交换函数参数等。
我读了你在其他主题上的帖子，发现你是个编程方面的大专家。当然，我不是，也不声称自己是这样。然而，我认为自己是解决此类任务的专家。那么，你不同意解决方案的有效性是最重要的事情吗？
语法的重载和规则的复杂性从未有助于保持解决方案的效率。这是在代码块的简洁性、普遍性和可读性方面所表现出来的简单和简短。
我在编程方面的规则是以使用母语和有意义的变量和函数名称为代价，减少代码、减少规则、减少语法和减少注释。
我的主要论点是 "如果你能在解决方案中不使用某些东西，你肯定应该不使用它"。
我认为这里根本就没有硬化的人））。仅仅看一下给定的代码，就会明白为什么它们容易被遗忘。甚至用外语编程这一事实本身也起了作用。当你用自己的语言编程时，感觉绝对不同。你感到力量和自由，而不是紧张和束缚。一门外语需要更多的努力，需要更多的时间来进入代码，并更快地从你的头脑中滑落。这只是一个 "生物因素"。
因此，我认为（相当合理地）使用一般的OOP来解决我的任务是低效的。大量的规则、句法和所有的外语。这样一来，人才就不能真正发展，这意味着结果会更差。