那里的大部分争论都是从你的手指中吸出来的。一些 "证明 "OOP无效的实验根本就不正确。在正常的OOP语言中，sum(int a, int b)永远是干净的，即使你在内部写了a += b这样的废话。同样，如果一个对象被分配到一个方法内的堆上，它总是被保护的，因为只有调用它的方法有对它的引用。你可以随意改变它。有参考和重要类型。没有人阻止你在OOP语言中编写没有任何副作用的干净函数。例如，标准的数学函数是这样的。是的，有时你不能没有共享资源，但有方便的线程安全集合和更多。毕竟，任何纯粹的FP将不可避免地与IO、BD、网络请求和其他许多东西进行交互，这就是可修改性守护程序将突破的地方。
这是对话题的破坏性反应，也是一种破坏性的讨论。告诉我一个程序化编程的追随者，如何避免OOP中的 "面条化"，如何解析以及使用别人的 "面条 "是否有意义？
毕竟，事实证明，OOP主要是为了可读性和团队编程，也就是为了大型项目。一个专家顾问，在其图表上交易一个符号，控制账户中的余额/资金的最大风险，好了，不能被称为一个大项目 - 它是足够的，更有利的内存/速度 - 程序化编程。
问题。
- 个人经验中的OOP（作为必须的）的缺点/劣势
- 从个人经验来看，FP的缺点/劣势（作为声明性的）。
而对前景的看法当然是有趣的，特别是在并行计算 的方向。我不认为触及量子话题有任何意义。
我需要看看它是从哪里来的，我完全不明白什么是spargeting。
任何代码的一个很好的特点是函数越短越好。你最好有更多的人。
例如，有一半的OOP属性是我们为了可用性而想要分离的东西--例如，把一些函数分离成一组，并给它们自己的变量，这些变量将生活在它们的命名空间中）。
由于我们正在使用一个存储类型的 "类"，我们可以清楚地预先定义所有的变量，使其具有某种类型....。
它可以方便地创建外部API。你可以在工作时使用类参考（8字节）--非常经常使用。
例子。各种各样的链接节点列表之类的东西。
//在这里我只写了我所看到的特殊性，很明显，写受保护方法的可能性和属性以及其他东西是没有意义的....。那只是糖而已。
FP的属性是我们想做的地方，在一些事情之后，例如，我们想在函数中飞快地组成一个新的函数--划分当前函数，这将使用我们函数中的一些当前变量。要把它的执行传递给另一个函数--事实证明，我们只是把延迟的函数、尚未发生的计算传递给它--只是作为一段代码....
事实上，这是很方便的。
这就留下了完整的代码展开的属性，因为事实上我们清楚地知道我们得到的是什么函数--这在计算上可能比OOP更快。你可以组织相当巧妙的计算从一个函数转移到另一个函数--函数也完全记住了过去函数的调用变量的环境--这非常酷（尽管事实上它只是从外部范围保存声明变量）。另一方面，FP，你可以设置一个函数的 地址，并像一个类一样把它存储在一个数组中--尽管不是特别有用。
易于为延迟动作、各种异步函数、并行计算编写代码
让我根据引用的文章和决定论的概念本身来解释我的担忧。是什么让我对 "修饰 "感到恐惧（代码本身的复杂性和寻找计算错误 的任务）？嗯，这就是文章的重点--变量中的 "垃圾 "值或函数的非确定性返回。
我建立/训练我的变量（演变）结构的神经网络。而对他们来说，价值观中的 "垃圾 "不知从何而来，是非常关键的。
就像文章中所说的那样--你踩下刹车踏板，而踏板并不关心你。那是在使用中。如果在构建（自动选择架构）和训练你的神经网络的初始阶段，"垃圾 "是可能的 - 它是如何构建/训练的？
如何在OOP中尽量避免 "垃圾"（非确定性）？
让我根据引用的文章和决定论的概念本身来解释我的担忧。是什么让我对 "修饰 "感到恐惧（代码本身的复杂性和寻找计算错误 的任务）？那么，文章的重点是什么--变量中的 "垃圾 "值或函数的非确定性返回。
我建立/训练我的变量（演变）结构的神经网络。而对他们来说，价值观中的 "垃圾 "不知从何而来，是非常关键的。
就像文章中所说的那样--你踩下刹车踏板，而踏板并不关心你。那是在使用中。如果在建立（自动选择架构）和训练你的神经网络的初始阶段，"垃圾 "是可能的 - 它是如何建立/训练的？
如何在OOP中尽量避免 "垃圾"（非确定性）？
这篇文章总的来说有些奇怪，这个人显然忘记了指定const变量的类型，就像他在js中那样，至少是只读的。在那之后，他写道，当不能改变大小的对象（是一个常数）在某种程度上不是一个常数时，他应该有一个错误.....，基于此，他得出结论，在OOP中出现错误的概率很大））。
一般来说，OOP允许你控制变量的区域。OOP的设计是为了从一个函数中传递变量，也就是说，类型应该已经被默认定义，因为很可能很少。而且，如果有必要的话，这个功能本身也可以随即扩展。
也就是说，在OOP中，有更多的初始控制权
就是这样，我一直怀疑)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23我不明白是谁写了这样的 "文章"，空洞的言辞，一般的短语，最低限度的意义。
"代码作为一个整体是混乱的和杂乱的--在俚语中被称为 " 意大利面条"--因为丰田 的坏程序员，我们将认为在OOP 中代码是混乱的。
"内置的OOP功能只会让人更加困惑。"--好的逻辑，使用功能的能力使代码更加混乱，随着OOP（C#）功能数量的不断增加，将不可能再编写简单的代码。是的。
"在大多数面向对象的语言中，数据是通过引用传递的，也就是说，程序的不同部分可以处理相同的数据结构--并改变它。这就把程序变成了一大坨全局状态，与OOP的最初理念相违背。"-私有的，受保护的？
"......如果你不喜欢这句话，那是因为一般的非决定论让你一无所获。"嗯，是的，不可预测的函数GetMicrosecondCount、MathRand、CoptBuffer、所有的网络函数和其他函数应该被扔掉，因为那里的结果取决于外部状态。这是很可怕的。
好了，够了，这里一切都很清楚了。
你去那里，总是被怀疑)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23那里的大部分争论都是从你的手指中吸出来的。一些 "证明 "OOP无效的实验根本就不正确。在正常的OOP语言中，sum(int a, int b)永远是干净的，即使你在内部写了a += b这样的废话。同样，如果一个对象被分配到一个方法内的堆上，它总是被保护的，因为只有调用它的方法有对它的引用。你可以随意改变它。有参考和重要类型。没有人阻止你在OOP语言中编写没有任何副作用的干净函数。例如，标准的数学函数是这样的。是的，有时你不能没有共享资源，但有方便的线程安全集合和更多。毕竟，任何纯粹的FP将不可避免地与IO、BD、网络请求和其他许多东西进行交互，这就是可修改性守护程序将突破的地方。
奇怪的文章....
数量往往会转变为质量。
当有很多收音机时，可能会出现电磁不相容的情况，它们会停止工作。
代码的面条属性通常来自于数量，在不同状态下有很多用途时，没有考虑到包装器的所有属性。
在功能上，反馈的存在将导致同样的事情。滞后是个笑话)
理解问题，并使之正确......。))))
// 我在这里只描述了我能看到的功能，显然没有必要去写受保护方法和其他东西的可能性和属性....。那只是糖而已。
FP的属性是我们想做的地方，后的东西，例如，我们想组成一个新的函数在飞行的函数 - 共享当前的，这将使用一些当前的变量从我们的函数。要把它的执行传递给另一个函数--事实证明，我们只是把延迟的函数、尚未发生的计算传递给它--只是作为一段代码....
事实上，这相当方便。
那么，谁能阻止在OOP中做同样的事情呢？即使是在纯粹的程序性语言中？你把一个函数的指针传给另一个函数，得到延迟执行。
一般来说，异步是一种纯粹的设计模式。你也可以用纯C语言编写异步代码。你只需要做一个状态机，分头执行任务。顺便说一下，我是用MQL中的指标做的，这需要很长的时间来计算。我这样做是为了避免降低图表的速度，并显示一个漂亮的状态栏，改变其实现的百分比。
那么，谁能阻止你在OOP中做同样的事情？即使是在纯粹的程序性语言中？你把一个函数的指针传给另一个函数，实现延迟执行。
一般来说，异步是一种纯粹的设计模式。你也可以用纯C语言编写异步代码。你只需要做一个状态机，分头执行任务。顺便说一下，我是用MQL中的指标做的，这需要很长的时间来计算。它可以帮助我不放慢图表的速度，并显示一个漂亮的状态栏，改变其实施的百分比。
) 你也可以使用汇编程序。问题是哪里更容易。
也不要把我放在一个或另一个方面....我并不拘泥于某件事情。
奇怪的文章。OOP与程序化风格没有什么区别，因为在OOP中，你可以默认用程序化风格做所有的事情，反之亦然，没有可怕的代码膨胀，也就是说，OOP是一种 "上层建筑"，不是一种根本不同的风格。
如果这篇文章真的是关于功能性的而不是程序性的（如果你挑剔的话，这并不那么明显），那么为什么要比较那些用途完全不同的东西。
托皮卡启动器，你自己写的，现在说的是哪个？ 功能性的还是程序性的？
毕竟，事实证明，OOP主要是为了可读性和团队编程，也就是为了大项目。
我不知道如何使用OOP。但我确实使用了它的原始东西。从最近的情况来看，发布了一些非常简单的代码。
在FP中开始写，当时我不明白我最终需要看什么。
通过OOP的原始元素完成。可能是失去了FP技能，但这里的OOP似乎更简单，更易读。
该代码非常简单和简短（描述）。如果你把它写在FP中，比较一下会很有意思。