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

新评论
 
A100:

我也是如此--一点一点地......4-5年后才会完全理解（这对一个普通人来说是正常的）。

在我看来，"充分理解 "是没有必要的。最主要的是要 "抓住本质"。 我，当我熟悉OOP方法学的时候，是1995年。

我已经对K&R精神中的 "常规C "有了一些经验（老家伙们一定记得），此外我还经常使用汇编函数。起初我对OOP的想法相当怀疑，甚至不是因为程序员必须执行一些额外的动作，而是因为纯粹的CPU "开销"。但我很快就相信了这项技术的实用性，CString类 是我心中的主要 "开关"。

不仅如此，与字符串打交道要简单得多：当时我们正在编写一个数据打包器，我的部分是输入文本分析器。因此，在CString类的基础上创建各种字符串的层次结构似乎非常方便，这对我们的打包器来说有重要的区别。

我特别喜欢这样一个事实：在数据打包器编写完成后，我有任务将其用于字符串，其中有大量的数字信息，而打包器最初并不是为这些信息设计的。它当然可以打包这类数据，但是，它考虑到输入的字母只是字符，但知道字符串由一些单词和数字组成--这大大改善了打包器的速度。 因此，写了一个代表这种带有数字的字符串的类（还有一个专门针对数字的压缩器），所有东西都被添加到现有的类中，打包器开始处理新的数据，尽管这个功能最初并不被期待。

这时我检查了OOP的可能性，以修改和支持代码。当然，有一些CPU的开销，但它被程序员的工作减少所补偿。

这就是为什么我建议每个开始学习OOP的人从这样的任务开始，OOP的优势会很明显地显现出来。 也就是说，随着处理列表中的不同对象的任务，这些对象将代表具有共同祖先的类的实例。
 
Igor Makanu:

听着，我的订阅里有这个频道，总的来说，我对作者有积极的看法，甚至有一个重复你的视频的主题，为之争论开始。

我几乎完全同意视频中的所有想法。 有几个小问题甚至不是反对，而是澄清（例如，我认为NULL是一个非常有用的指针，它可以告诉你一个错误，你只是应该记住，函数可以返回这个空指针，当然，视频中正确地指出--你不能像对待一个对象那样处理它）。

而其他关于不准确的地方、发展的顺序、获得者的设置和相同的NULL都是正确的。

为作者点赞。

 

很奇怪的是，作为一个富有哲理和善于抽象的人，我是如此迫切地想拒绝专业人士所钟爱的编程方法。虽然它被设计成实用的，但OOP已经被实体所淹没，并且对其任务来说是多余的。工具的 "冗余 "阻碍了解决方案，同时也阻碍了稀缺性。而这种冗余无疑是营销的一个结果。仔细想想，一个最小的OOP就足以解决计算机领域的一切问题。就像一切都可以用简单的函数和适当的内存处理来创建一样。 在最初的层面上，我马上就采用了OOP。然后我注意到，一些实体无法证明其存在的必要性，并在不断增长的概念中过着自己的、从任务中抽象出来的生活。是的，它们被嵌入到解决方案中，但它们是寄生在开发者的智力上的。它们减缓了工作进程，降低了其效率。它们通过混淆、语法、规则等阻碍了工作流程。这就是我不喜欢解决方案内部的这种可选择性的原因。

所以，我打算使用最简单的OOP。在营销之前就已经创建的那个。

 
Реter Konow:

很奇怪的是，作为一个富有哲理和善于抽象的人，我是如此迫切地想拒绝专业人士所钟爱的编程方法。虽然它被设计成实用的，但OOP已经被实体所淹没，并且对其任务来说是多余的。工具的 "冗余 "阻碍了解决方案，同时也阻碍了稀缺性。而这种冗余无疑是营销的一个结果。仔细想想，一个最小的OOP就足以解决计算机领域的一切问题。就像一切都可以用简单的函数和适当的内存处理来创建一样。 在最初的层面上，我马上就采用了OOP。然后我注意到，一些实体无法证明其存在的必要性，并在不断增长的概念中过着自己的、从任务中抽象出来的生活。是的，它们被嵌入到解决方案中，但它们是寄生在开发者的智力上的。它们减缓了工作进程，降低了其效率。 它们通过混淆、语法、规则等阻碍了工作流程。这就是我不喜欢解决方案内部的这种可选择性的原因。

所以，我打算使用最简单的OOP。在营销之前就已经创建的那个。

是的，你创建一个类，比如说，与一个文件一起工作。你开始使用它，你就会有虫子。你关闭了代码的一个部分，并试图在另一个部分做一些事情。有两种方法。第一个是试图总是记住东西是在哪里生产的，即使有一个开发商，这可能也不是很好。第二--在检查行动之前要做的事。好了，下一个错误：在验证操作中，分散在整个代码中，这里和那里有错别字，错误的符号，在一个地方纠正了，在另一个地方忘记了，等等。结果，你从这样一个心爱的代码效率变成了一件微不足道的简单事情：每一个读/写方法和类似的方法都包括一个对检查方法的调用，允许你在调用时撤销它，而你几乎不会用到它。然后你意识到这是一件好事，因为现代硬件允许你在98%的解决任务中不计算时钟周期和内存消耗。

 
Vladimir Simakov:

是的，你创建一个类，比如说，与一个文件一起工作。你开始使用它，你就会有虫子。你关闭了代码的一个部分，并试图在另一个部分做一些事情。有两种方法。第一个是试图永远记住东西是在哪里生产的，即使是一个开发商，你也可能做不到这一点。

彼得很擅长这个。

这就是问题所在--彼得很喜欢使用一个包含所有变量的巨大表格，这个表格总是可以从整个程序中获得，而且他随时可以从中获取他需要的东西。对于背诵的巨人来说，这是很方便的。

在OOP中，封装是一种存档功能，它只是用来确保代码中任何地方的用户只能访问他需要的变量，而不能访问其他变量。但对Peter来说，这是一个减分项，他已经记住了他使用的地点、内容和方式。 他希望能够在任何时候访问程序中任何部分的任何变量。他不喜欢我的方法，当为了访问一个变量，你必须首先得到一个指向接口的指针，从接口中你必须得到函数，只有这样它才能返回你需要的值。而在这些步骤中的任何一个，你都可能遇到访问限制。我认为这是一件好事，因为如果有一个限制--它的存在是有原因的，这意味着我没有考虑到一些重要的细节。而对彼得来说，这是一个障碍，因为他总是把一切都考虑在内。

 
Vladimir Simakov:

是的，你已经创建了一个类来处理，比如，一个文件。你开始使用它，得到了错误。你关闭了代码的一个部分，并试图在另一个部分做一些事情。有两种方法。第一个是试图总是记住东西是在哪里生产的，即使有一个开发商，这可能也不是很好。第二--在检查行动之前要做的事。好了，下一个错误：在验证操作中，分散在整个代码中，这里和那里有错别字，错误的符号，在一个地方纠正了，在另一个地方忘记了，等等。结果，你从这样一个心爱的代码效率变成了一件微不足道的简单事情：每一个读/写方法等等都有一个对检查方法的调用，有一个撤销这个调用的选项，而你几乎永远不会用到这个选项。然后你意识到这是一件好事，因为现代硬件允许你在98%的解决任务中不计算时钟周期和内存消耗。

让我们想象一下相反的情况。嗯，你没有虫子。完全没有，也几乎没有，因为你记住了所有的东西，并把所有的东西都考虑进去了。你会仅仅因为你的 "职业责任 "而使用OOP 吗？我不这么认为。那时你会关心什么呢？- 只有你的代码的效率。你将尝试去除所有的开销，以便代码尽可能快地工作。你也将尝试以这样的方式创建你的代码，使其快速发展。

当人们告诉我这里和那里出现的bug时，我可以理解，但当它们与使用或不使用OOP有关时，我就不同意了。错误的数量取决于一个人对自己代码的认识和理解。编写代码的人比插入代码的人更了解它。一个人写的东西总是有较少的错误。正如你所理解的，OOP促进了代码的可移植性，其反面是其他程序员的理解能力差。这就是错误的来源。

我自己写所有的东西，在没有剖析器和检查器功能的情况下，我在2000行的块中发现错误。很简单，我知道我的代码。虫子的最佳治疗方法））。

 
Georgiy Merts:

这对彼得有用。

这就是问题所在--彼得对使用一个包含所有变量的巨大表格感到很舒服，这个表格总是可以从整个程序中获得，而且他随时可以从中获取他所需要的东西。对于背书的泰斗来说，这是很方便的。

OOP中的封装是一种归档功能，它正是用来确保用户在代码的任何地方只能访问他所需要的那些变量，而不能访问更多。但对Peter来说，这是一个减分项，他已经记住了他使用的地点、内容和方式。 他希望能够在任何时候访问程序中任何部分的任何变量。他不喜欢我的方法，当为了访问一个变量，你必须首先得到一个指向接口的指针，从接口中你必须得到函数，只有这样它才能返回你需要的值。而在这些步骤中的任何一个，你都可能遇到访问限制。我认为这是一件好事，因为如果有一个限制--它的存在是有原因的，这意味着我没有考虑到一些重要的细节。而对彼得来说，这是一个障碍，因为他总是把一切都考虑在内。

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

不要让他们认为我在敦促你重视职业精神。绝对不是。我唾弃它是因为我过度膨胀的自负。事实证明，它不仅可以是坏事，也可以是好事。:)

 
Реter Konow:


彼得，你的想法表明你从来没有在一个团队中工作过。你还没有看到每个人是如何在一项巨大的任务中做自己的那部分工作的，以及最后是如何一起完成的。

例如，如果没有OOP，就不可能创建和开发Windows。

如果没有必要，我也会尽量不应用类。 但当我决定把我的机器人变成一个多货币机器人 时，我立即应用了类，因为已经很清楚没有OOP会发生什么。

通过应用类，很明显，所使用的对象对是同一类的，同时处理它们已经非常容易。

 
Petros Shatakhtsyan:

彼得，你的想法表明你从来没有在一个团队中工作过。你没有看到每个人是如何在一项巨大的任务中做自己的那部分工作的，以及最后是如何一起完成的。

例如，如果没有OOP，就不可能创建和开发Windows。

如果没有必要，我也会尽量不应用类。 但当我决定把我的机器人变成一个多货币机器人 时，我立即应用了类，因为已经很清楚没有OOP会发生什么。

通过应用类，很明显，所使用的对象对是同一类的，同时处理它们已经非常容易。

是的，我没有在一个团队中工作过。我的方法应该被看作是一个开发者的实验。我没有被说服去遵循它。我的做法有太多的大胆之处）。
 
Реter Konow:
是的，我不是这个团队的一员。我的方法应该被看作是一个开发者的实验。我不是在劝说跟随它。我的做法有太多的无礼之处）。

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

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

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

1...34567891011121314151617...55
新评论