OOP与程序化编程
我不想在这里引起大合唱，但我想知道OOP的支持者是否可以提交一些解决某个问题的代码，其中可以清楚地看到这个解决方案比没有OOP的解决方案更有效率？
我是一个没有OOP的解决问题的高手，希望能和一个用OOP解决问题的高手交手。
我不想在这里引起大合唱，但我想知道OOP的支持者是否可以提交一些解决某个问题的代码，清楚地表明这种解决方案比没有OOP的解决方案更有效率？
我是一个没有OOP的问题解决者，也想和一个 有OOP的问题解决者战斗。
这不是一个可以复制比较的平台--程序是单页的（单文件）。在这里，你可以随心所欲地写作，而程序的性能和访问量将几乎保持在同一水平。尽管在任何一种写作风格中，程序化或OOP都有可能被搞砸。
这不是一个可以复制比较的平台--该方案是单页（单文件）。在这里，你可以随心所欲地写作，而性能和程序的访问几乎会保持在同一水平。虽然你可以在任何编程风格中搞砸 - 程序化或OOP。
我不太理解你。你说的 "单页程序 "是什么意思？你可以简单地比较解决一项任务的两种不同方法。在比较时，你应该通过主要标准来估计每个解决方案：解决方案本身、代码紧凑性和代码可读性。
这些是编程中的主要标准。
- www.metatrader5.com
我不想在这里引起大合唱，但我想知道OOP的支持者是否可以提交一些解决某个问题的代码，清楚地表明这种解决方案比没有OOP的解决方案更有效率？
我是一个在没有OOP的情况下解决问题的高手，希望能和一个用OOP解决问题的高手较量一下。
我已经在上面介绍了这样的代码。有一个完全虚拟的界面，其中处理了交易历史。在我的工作中，在目前的位置 和其他类似的地方，也使用了同样的系统。
正是因为有了OOP，我们才有了MT4和MT5的完全统一，在MT5中，不管是对冲还是净值，都能发挥作用。
此外，正是由于我的OOP，在一个EA中我可以很容易地使用几个TS，它们的魔法是不同的。
事实上，OOP是为了简化代码支持而发明的。同时，在写作过程中，你必须付出很大的代价。如果你写了代码，不加修改地使用它，然后把它删除，那么费力地使用OOP就没有意义了。当许多地方都需要相同的代码，并且需要定期进行修改时，OOP正好提供了一个优势。
相应地，OOP应用和非应用的范围是由代码维护和修改的必要性决定的。
区块的多功能性是另一个评价标准。当然，一个街区应该可以用于广泛的任务，并且容易适应不断变化的条件。这正是我的情况。例如，我使用所谓的 "聚焦 "技术。也就是说，主要参数的值一直固定在全局变量 中，这些变量并放在所有的块中。
恐怕全局变量也是一个缺点。所有区块中都应该有尽可能少的全局变量。只是为了确保每个区块只收到它所需要的数据，而且只要有可能--只以恒定的形式，这样就没有办法改变一些不应该改变的东西。
我的项目中只有两个全局变量，一个是CExpert类对象，它的功能是封装Init()、OnTick()和其他事件的功能，另一个是CLogFile对象--一个日志文件，用于输出跟踪，因为跟踪宏必须在程序的任何地方工作。
在我看来，依靠记忆并不是最好的解决办法，至少，正如夏洛克-福尔摩斯所说--在某个时刻，需要的知识会被埋没在一堆不必要的垃圾中。记忆也会失效。
恐怕全局变量也是一个缺点。所有区块中都应该有尽可能少的全局变量。只是为了确保每个区块只收到它所需要的数据，而且只要有可能--只以恒定的形式，这样就没有办法改变一些不应该改变的东西。
在我的项目中，唯一的两个全局变量是CExpert类对象，它的功能封装了Init()、OnTick()和其他事件的功能，以及CLogFile对象--一个输出跟踪的日志文件，因为跟踪宏必须在程序的任何地方工作。
依靠记忆并不是最好的解决办法，至少是因为正如夏洛克-福尔摩斯所说，在某个时刻，必要的知识会被埋没在一堆不必要的垃圾中。记忆也会失效。
这需要在实践中进行比较。否则这就是一个无用的讨论。
为什么 "无用"？非常有用。
但我们如何在实践中比较 "支持的便利性"？
比方说，把代码写成一个巨大的块，和把代码分割成几个功能部分--在这两种情况下引入变化是完全一样的。 唯一的区别是，在第一种情况下，应该记住所有会受到修改影响的环节，并把它们考虑进去。在第二种情况下，由于该单位只能访问它需要工作的链接--修改将影响所有可用的链接。你不需要记住任何东西--始终如一地调整你想修改的区块所能获得的一切。
这就是如何评估这里的差异？工作量是完全一样的 !
