对巴解组织的看法很有意思
你去那里，总是被怀疑)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23你应该明白，这类文章很可能是由不熟悉FP的人写的，其混乱的钩子，可以包括20个标签....。
硬性FP是另一回事。然后你开始考虑OOP的简洁性和便利性，你可以提前声明一些功能，等等.....。在本质上，一个人与另一个人的相似性。这只是这样的文章往往写的人谁已经掌握了只有程序代码 - 而这甚至不是接近FP，所以，如果你不知道什么钩和生动的使用它，没有FP是出了问题
此外，文章中列出的许多 "垂死的语言"都支持FP和OOP的全部功能，它们为什么要死亡呢！而且其中有几位是独联体国家 中收入最高的。它更多的是关于OOP中的 "修饰"，完全没有考虑 "淹没 "在FP中。在我看来，程序化范式是现实的，比OOP更节约资源。
是的，有一个构造函数，在某些情况下，它的代码通常比较长....。从技术上讲，FP的部署对于机器代码的生成应该是更有效的....。但代码并没有变得更简单，就打字而言，不可能做出正常的包装器......
这些天，你经常可以找到一个和另一个的混合体--方式不互相干扰
是的，有一个构造函数，在某些情况下，它的代码通常比较长....。从技术上讲，FP的部署对于机器代码的生成应该是更有效的....。但代码并没有变得更简单，就打字而言，不可能做出正常的包装器......
如今，经常可以看到一种和另一种的混合。
如果没有OOP和FP，一切工作都会更容易和更快（是的，没有 "美女"、面板等），但有时甚至很难理解自己的代码）
没有OOP和FP，一切工作都更容易、更快（是的，没有 "美女"、面板等），但有时连自己的代码都难以理解）。
首先掌握一个或另一个，或者最好两个都掌握，然后再决定你喜欢哪个。而像现在这样的做法，随着时间的推移，你会变成费多谢夫，同意一切你不理解的东西（即几乎所有的东西）。
告诉我，作为一个程序员，如何避免OOP中的 "拼凑 "现象？
引用的文章中给出了秘诀：努力编写确定性的函数。
如何拆解，用别人的 "面条 "有意义吗？
好的代码，是的，但不是意大利面条。
毕竟你能得到什么，OOP主要是为了可读性和团队编程，也就是为了大项目。
对。
一个EA在图表上交易一个符号，并对余额/账户资金进行最大限度的风险控制，嗯，不能称之为一个大项目--所以程序化编程是足够的，而且在内存/速度方面更有利。
去澳大利亚旅行，用飞机比较方便（OOP），去邻近的城市旅行，用汽车甚至自行车就可以了（PP）。你只需要选择更方便的手段来实现目标。
你去那里，总是被怀疑)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23