你去那里,总是被怀疑)
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