给OOP专家的一个问题。 - 页 11

新评论
 
Petros Shatakhtsyan:

如果一个程序员进入外汇世界，没有必要成为一个专业人员，也不需要知道OOP。

最好是学习市场的复杂性，并制定一个有利可图的交易策略。而且，你是否使用OOP 并不重要。专家顾问的盈利能力不会因此受到影响。

你没有必要浪费你的精力。

这就是问题所在，它可能。我的那位朋友因为代码中的一个错误而损失了一部分存款，而OOP使错误的可能性降低。
 
Реter Konow:

乔治，这不仅仅是记忆的问题。我已经为自己创造了一个舒适的开发环境，同时使用我的母语和英语。双语代码的记忆比单语代码好得多。特别是当你不拘泥于标准词，用任何你想要的名字来称呼变量时。证实了这一点。我根本无视编程的专业性，开始随心所欲地写作。因此，我开始快速浏览我的代码，并轻松地阅读、回忆和开发它。其余的你知道...

我不认为它可以帮助。对我来说，任何语言中的变量名称几乎瞬间就从我的记忆中抹去了，我从电脑后面站起来，已经只记得一般的原理，而无法分辨哪些变量被输入到哪个地方。

顺便说一下，这就是为什么我总是使用成对的mqh-mq5文件，而不是完全用mqh文件来写类--我需要经常查看头文件，只是为了提醒自己在这种或那种情况下有什么可用的东西，我在标签中打开必要的头mqh文件，当我需要再次刷新这些信息时，我会切换到它们。当整个班级（甚至更多的几个班级）被描述在一个mqh文件中时，即使有标签的帮助，也很难在这个文件中 "跳跃"。

我不能把所有的结构都保留在我的内存中，虽然在我年轻的时候，正如我已经提到的，我甚至用汇编程序来写，但是没有其他的选择--你只有内存地址，而宏汇编程序允许的最大限度是使用宏替换来创建特定区域的名称。 这也是可行的。但我早就确信，这种方式的错误数量要大得多，而且这种代码的调试也更加困难。

我在上面已经举了一个例子：一个错误发生了，一个变量由于某种原因被错误地修改了。而且这个变量在程序中的很多地方都可以访问。如何抓住一个有错误的地方？有了OOP封装，就非常简单了--我们在修改变量的接口函数中设置一个断点，一旦发生不正确的修改--我们就停下来，通过调用层次结构，立即看到不正确的修改是在哪里发生的。而用你的方法，彼得，我们必须挖掘所有的代码，查看所有访问这个变量的地方，把断点放在各个地方，分析所有的调用，而不仅仅是错误的调用。

 
Aliaksandr Hryshyn:
这就是问题所在，它可以受到影响。我的朋友因为代码中的一个错误而损失了他的部分存款，而OOP使错误的可能性降低。

这意味着他不是一个好的程序员。在复杂的OOP结构中，你会比没有OOP结构时更容易感到困惑。

在有必要的情况下，必须采用班级制。我注意到，一些程序员不知为何有一种执着，在没有必要的地方应用许多函数。课堂上也是如此。

有些程序员不写一个没有OOP的紧凑而简短的程序，而是开始应用类、许多函数，一个简单的解决方案变成了一公里长的文字。

 
Petros Shatakhtsyan:

这意味着他不是一个好的程序员。在复杂的OOP结构中，你会比没有OOP结构时更容易感到困惑。

所有其他事情都一样吗？我非常怀疑这一点。如果结构体的复杂性相同，用OOP来理解它们就会容易得多。

然而，它并没有取消 "用大炮打麻雀 "的规则，在任务非常简单和紧凑的情况下，使用大型OOP的复杂性是没有意义的。

虽然，正如这里已经说过的--OOP允许我们建立类库，然后在许多项目中使用。

说，同样的数组类，文件类...即使你写一个非常简单的指标，不使用OOP，声明一个CFile类 并使用它的函数，比使用处理文件的标准函数要容易得多。更不用说用更具体的CFile替换的可能性了，例如，我有一个CLogFile类，它能够自动将时间和一些额外的数据插入字符串（用于日志文件）或CIniFile类，它能够将数据组织成标准的ini文件，然后在必要时读取和使用它们。

 
Petros Shatakhtsyan:

这意味着他不是一个好的程序员。在复杂的OOP结构中，你会比没有OOP结构时更容易感到困惑。

在有必要的情况下，必须采用班级制。我注意到，一些程序员不知为何有一种执着，在没有必要的地方应用许多函数。课堂上也是如此。

有些程序员不写一个没有OOP的紧凑而简短的程序，而是开始应用类、许多函数，一个简单的解决方案变成了一公里长的文字。

实际工作是一百多行，剩下的几千行是很久以前写好的、调试好的库，这样可以吗？)))
 
Vladimir Simakov:
实际工作是一百多行，剩下的几千行是很久以前写的和调试的库，这样可以吗？)))

如果一个程序员在他/她的程序中使用现成的类，例如：CTALO、CAccountInfo、CPositionInfo，这并不意味着他/她的程序是基于OOP的。

这取决于程序员是自己创建这样的类，还是仅仅使用这些类而不知道这些类的内部情况（在源文本层面）。

 
Georgiy Merts:
....

上面已经给出了一个例子--发生了一个错误，由于某种原因，一个变量被错误地修改了。而这个变量是在程序中的很多地方被访问的。如何抓住一个错误的地方？有了OOP封装，就非常简单了--我们在修改变量的接口函数中设置一个断点，一旦发生不正确的修改--我们就停下来，通过调用层次结构，立即看到不正确的修改是在哪里发生的。而用你的方法，彼得，我们必须挖掘所有的代码，查看所有访问这个变量的地方，把断点放在各个地方，分析所有的调用，而不仅仅是错误的调用。

是的，我的内核在程序的所有部分都被修改了，错误发生了，但我不需要断点。我在心里计算，并在几个地方提醒，以检查价值。我就是这样发现的。我强调--我非常了解我的项目。

但是，从好的方面看，有了这些知识，没有句法障碍，又有母语，我就有了快速发展的巨大机会。 这就是为什么我在解决方案中反对OOP。

分割代码，其外来的单一语言，新的语法，额外的规则--所有这些都会减缓程序的发展。我将失去更多的努力，得到更少的结果。我知道这是一个事实。


如果我的任务是用现成的代码片断来构建和调试一个程序，那么只有OOP和库才行。勾通和开发新的解决方案是不同的事情。许多人提倡OOP，因为他们想使用别人的大块代码，节省精力。我使用专有技术创建自己的解决方案，我对OOP有不同的需求和看法。

 
Реter Konow:

是的，我的内核在程序的所有部分都被修改了，错误发生了，但我不需要断点。我在心里计算，并在几个地方提醒，以检查价值。我就是这样发现的。我强调--我非常了解我的项目。

但有利的一面是，有了这样的知识，没有句法障碍和母语，我有巨大的机会快速发展。这就是为什么我在解决方案中反对OOP。

分割代码，其外来的单一语言，新的语法，额外的规则--所有这些都会减缓程序的发展。我将失去更多的努力，得到更少的结果。我知道这是一个事实。


如果我的任务是用现成的代码片断来构建和调试一个程序，那么只有OOP和库才行。勾通和开发新的解决方案是不同的事情。许多人提倡OOP，因为他们想使用别人的大块代码，节省精力。我使用专有技术创建自己的解决方案，我对OOP有不同的需求和看法。

我建议至少使用一次VC++的对话框 模板，在MFC的CDialog基础上创建应用程序，在可视化模式下在上面设置各种控件，使用现成的函数来理解OOP的所有力量。

我还想补充一点，Borland C++有非常方便的类来与Oracle一起工作。我一直用它工作到2012年，现在我不知道怎么了。

 
Petros Shatakhtsyan:

我建议至少使用一次VC++的对话框模板，在MFC的CDialog基础上创建应用程序，在可视化模式下为其设置各种控件，使用现成的函数，以了解OOP的所有力量。

我还想补充一点，Borland C++有非常方便的类来与Oracle一起工作。我一直用它工作到2012年，现在我不知道怎么了。

在这次讨论中，我们所说的权力 是指不同的东西。对你来说，权力表现为快速和容易地从库中装配现成的代码片断，而这些库已经有很多了。轻量级的建筑也是力量。但这是不同的。我说的是开发新解决方案的力量。从零开始。在开发环境中增长程序的力量，没有现成的代码片断。毕竟，他们不会把图形化的 C++库移植到MQL。你不得不开发出你自己的相同水平的解决方案。而在这里，考验力量的不是建筑的速度，而是程序开发的速度。我花了两年半的时间，从头开始创建我自己的标记语言。我的API。这比图形化的MQL库要多。我非常接近于创建一个可视化的构造器。而这，是该方法的力量 的一个指标。很遗憾这里没有人需要它......
 

这是2019年下半年....，但20日和25日和....。也会争论是否需要使用OOP？

))))

如果我们喜欢它，我们就使用它，如果我们不喜欢它，我们就不使用它。

如果你习惯于用以前写的小子程序来写程序--写吧，你起错床了......你把所有这些子程序放在源代码中，你会得到一大堆混乱的代码。


给人们提供了很多开源的可能性，它仍然是不一样的，修剪功能到纯C，同样是不一样的))))。

ZS: 我怀疑有些开发者反正也在看论坛...我认为这条线索肯定会让他们高兴起来的。))))

1...456789101112131415161718...55
新评论