In the past months, many new features were added to Red/System, the low-level dialect embedded in Red. Here is a sum up if you missed them. Subroutines During the work on the low-level parts of the new Red lexer, the need arised for intra-function factorization abilities to keep the lexer code as DRY as possible. Subroutines were introduced to...
如果问题是针对我的例子--至少你隐藏了实现（你甚至对你自己也隐藏了）--即你只写了计算的逻辑，这很方便，可读性强，它允许你避免逻辑错误。
SZZY：关于交易--我写过并仍在做订单网格的实验，我把下订单的逻辑写成A+B-C，其中A、B和C--就是有预定参数的订单，对遗传算法 非常有用--有趣的话题。
封装器是一个很好的、合乎逻辑的解决方案。当它适合于目的时。而且我认为包装器是程序性语言的一种创新。确切地说，是在新颖性和实用性的意义上。
至于交易--我写过并仍在进行订单网格的实验，我把订单放置的逻辑写成A+B-C，其中A、B和C是具有预定义参数的订单--它对遗传算法 非常有用--这是一个有趣的话题。
有预定参数 的 A、B、C--作为遗传算法的表型？
封装给了名字的自由。而如果这个问题通过名称逻辑来解决。这当然是有成本的。那么python可以用函数来写，但它不会是一个有市场的解决方案。但这是可能的。
在python中，任何函数都是一个对象，就像一个变量一样)
顺便说一下，连续OOP的一个例子是Python。在那里，反而没有人知道OOP以外的东西存在。
有闭包，而且你可以不用OOP来写，至少在老的OOP中是这样，不管你喜欢哪种。
在Python中，任何函数，像变量一样，都是一个对象)
你能做的就是用引用来解决一切问题，只要名字不重合。一个函数当然是一个对象，但它的结果在内部是统一的，只有在全局和公共的情况下你才能看里面的内容。我喜欢Python的逻辑））)
有闭包，而且可以不用op来写，至少在旧版中是这样的，不管你喜欢哪一种，都可以。
你可以这样做，但最小的构件仍然是一个对象。
我已经有一段时间没有看到他了...
他真的用了不同的网名吗？
不，这不是彼得，这是一种不同的写作风格。
鲜明的企业OOP是Java。在我们的领域中，Du* *opy是代表（洒脱的，以免陷入困境）。如果你想获得对象的美感--冷静地尝试理解并记住他们的API，幸好主题是已知的:-)
但这都是胡说八道...
为了提高你的编程技能，你可能想学习一些令人费解的东西。例如，有Rebol/Red（https://www.red-lang.org/）--相当酷的东西，它不他妈的容易理解，但它很酷。
或经典的Smalltalk（https://pharo.org/）。有人甚至在生产中使用它。
而所有这些 "让我们用不同的风格来写A+B "的说法，说实话，都是小孩子的游戏。
然后，所有关于OOP和FP谁更酷的问题都会自行消失。
你可以，但最起码的构件仍然是设施。
该物体是一个突破。
在OOP更方便的地方，我使用OOP，在我需要节省内存和时间，以及为自己编码的地方，我坚持使用过程式。刚看到一篇文章，我想听听大家的意见，哪里/哪里更好）。结果--我在讲话中听到了很多不同的东西，不是关于编程的）一切如常。
所以没有人会告诉你任何新东西。使用你觉得舒服的东西，就是这样。
为了尽量减少错误，有一整个领域被称为证据性编程（尤其是形式化验证）。
作为提高代码质量的部分措施，你可以建议遵循任何常见的编码风格（如google代码风格），使用断言、约束（const、override、access specifiers），这些约束事实上不影响执行，但如果使用不当会导致编译错误，熟悉一般的设计方法
事实上，除了关键的编程领域外，一般来说，快速推出生产版本比获得代码质量更重要，这很糟糕，但却是事实