Если вы никогда не слышали про Алана Кэя, то как минимум слышали его знаменитые цитаты. Например, это высказывание 1971 года: The best way to predict the future is to invent it. Лучший способ предсказать будущее это изобрести его. У Алана очень яркая карьера в информатике. Он получил Премию Киото и Премию Тьюринга за работу над парадигмой...
如果两个具有相同经验和智力的程序员在竞争，创造类似的大型项目。但前者只使用函数，而后者使用函数和类。肯定的是，胜利将属于第二个人。但是，我再说一遍，如果是一个庞大的项目，后者会使它更快，因为会有更少的错误和更多的秩序。而第二个产品将更具有可读性、可维护性，更容易更新和补充。这甚至不是我的看法，这只是一个事实的陈述。用铲子挖洞比用镘刀挖洞更容易。如果你不仅在函数上而且在类上实现你的机制，它将变得更有效率。现在这是我的看法。
让我们从大型机制的实施中对类的需求问题开始。一个类是一些功能集合的外壳，而 "大机制 "是实现一组任务的代码块。在我的实施中，"大机制 "几乎总是一个非常大的功能和一组为其服务的小功能。所谓的 "引擎"。如果你把它和服务功能塞进一个类里，什么都不会改变，如果你把它塞进不同的类里，它们之间的访问会变得更加复杂，机制效率也会降低。
如果机制的规模扩大了，你必须优化其代码或将功能分成文件。这还不够吗？此外，定期优化 一个区块的代码 会带来效率的奇迹。它不断被压缩，需要越来越多的功能来实现。也就是说，函数的数量相反地减少了。它们被概括为一个区块，其代码不断被改进。这是 一条直接通往效率的道路 。
此外，如果我们使重要的变量成为全局变量，它们将在机制中随处可见，并且很容易处理它们，如果我们为它们定义作用域，从机制效率的角度看，这将产生多余的任务。再次，访问的复杂性。创建类对象，等等......将机制分割成大量功能的趋势不仅破坏了效率，也破坏了代码块的通用性。事实证明，每个具体的任务都需要一个单独的函数，而代码块的通用性根本没有得到改善。调用和传递的参数数量也在增长。这无助于机制的效率，但这种倾向实际上是由OOP推动的。
当一个项目由一个程序员团队处理时，OOP的效率更高。在这种情况下，你不能没有它。虽然，如果你考虑一下，你也可以在这里找到一个没有它的方法......
但当然，这些都是文字。在实践中，我会很快证明我在说什么。
Nikolai Semko:
还有，彼得，我快速看了一下你的代码，发现你完全使用了canvas（不是CCanvas类，但谁在乎呢）。那么为什么有这么多关于画布的问题，为什么我在这里要解释这些事情？:)).
))))，你对kanvas的绘画原理的解释让我有点吃惊。我以前告诉过你，也给你看过，我的kanvas中的所有东西都是画出来的。)(好吧，几乎所有的东西。 :)
开始这个话题是因为我不明白为什么到目前为止没有人画出和我一样的按钮。毕竟，用你的话说，这很容易。
))，你对画布上的绘画原理的解释也让我有点吃惊，因为我以前就告诉过你，也给你看过，一切都在画中。）(好吧，几乎所有的东西。 :)
开始这个话题是因为我不明白为什么 到目前为止 没有人画出 和我 一样的按钮。毕竟，用你的话说，这很容易。
如果你没有看到，这并不意味着除了你之外没有人能够做到。它只是太微不足道了，你甚至不需要发布它--太微不足道的事件--创造一个按钮而已--发布它的代码，而不是因为你是最好的;)
你们都在竞争，而且是正确的竞争，安纳托利--与风车竞争。
如果你没有见过，这并不是说除了你之外没有人能够做到。它只是太微不足道了，没有必要发布它--太微不足道的事件--只是创建一个按钮--发布它的代码，而不是因为你是最好的；)
你们都在竞争，而且是正确的竞争，安纳托利--与风车竞争。
冷静点，Artem。我已经意识到，你不喜欢我。显然，这个资源上的许多其他人也是如此。也许这是有道理的，但在讨论技术问题时突然改变自己的个性，这太过分了。
我很平静，你为什么不这么认为？
喜欢/不喜欢一个人--这不是一个技术论坛来讨论。你对我来说是中立的--仅此而已。同样，在我看来，对于我们其他人来说，也是如此。
但要想让你被提到不是 "啊--啊--啊......，是那个唐吉诃德......，我记得，我记得...... "的风格，你至少需要做一些有用的事情。
你可以做也可以不做你想做的事--你的权利，没有人对此有异议。这里没有人需要你的话--你首先应该把它交给自己；)
气氛非常友好--人们告诉你在某些情况下使用OOP 是多么的好，一个人在你面前钉钉子，试图在某些方面帮助你，为你编码给你看，让你更容易理解。但事实证明--从你自己的话来看--你根本不需要--你只是不知道还能和谁竞争，并试图 "弱弱地 "挑战别人。
在我看来--你不是因为你决定不写作，不研究OOP，你已经权衡了一切，明白了你，使用程序化编程，写出了更好的和优化的代码（正如你在这里向大家介绍的那样），而只是因为你不明白那里的一切，发明了一个借口，你向大家宣布，用语言和挑战来支持它 "只相信击败我的人"。
还记得那个关于 "Elusive Joe "的笑话吗？
...
还记得那个关于 "Elusive Joe "的笑话吗？
完全同意。
难以捉摸的抒情诗人/哲学家... :-) 与 "乔 "一样的废话，只是在 "另一只手"...:-)
让我们从大型机制的实施中对类的需求问题开始。一个类是一组函数的外壳，而 "大机制 "是实现一组任务的代码块。在我的实现中，一个 "大机器 "几乎总是一个非常大的功能和一组为其服务的小功能。所谓的 "引擎"。如果你把它和服务功能塞进一个类中，什么都不会改变，如果你把它塞进不同的类中，它们之间的访问会变得更加复杂，机制效率也会降低。
如果机制的规模扩大了，你必须优化其代码或将功能分成文件。这还不够吗？此外，定期优化 一个区块的代码 会带来效率的奇迹。它不断被压缩，需要越来越多的功能来实现。也就是说，函数的数量相反地减少了。它们被概括为一个区块，其代码不断被改进。这是 一条直接通往效率的道路 。
此外，如果我们使重要的变量成为全局变量，它们将在机制中随处可见，并且很容易处理它们，如果我们为它们定义作用域，从机制效率的角度看，这将产生多余的任务。再次，访问的复杂性。创建类对象，等等......将机制分割成大量功能的趋势不仅破坏了效率，也破坏了代码块的通用性。事实证明，每个具体的任务都需要一个单独的函数，而代码块的通用性根本没有得到改善。调用和传递的参数数量也在增长。这无助于机制的效率，但这种倾向实际上是由OOP推动的。
当一个项目由一个程序员团队处理时，OOP的效率更高。在这种情况下，你不能没有它。虽然，如果你想一想，你也可以在这里找到一种方法来避免......
但当然，这些都是文字。在实践中，我会很快证明我在说什么。
Peter，只是我以前只用函数编程，推理方式几乎和你现在一样，后来我几乎是通过强迫（因为习惯的力量是不可思议的）开始用类编程。现在我可以比较这两种状态，而你，没有尝试过应用类的人，不能。无意冒犯。这只是让我想起了另一种情况。我已经吃了很多年的素了。令人羡慕的是，有些人从来没有吃过素，并试图向我讲述蛋白质、必需氨基酸等。我告诉他们：我们的条件不一样，我以前是吃肉的，现在是吃素的，所以我可以在实践方面比较这两种条件。你不是，你的知识只是理论上的，与实践毫无关系。
不要浪费你的时间--掌握OOP。
你在这个论坛上被完全禁止了，我的朋友。:))包括我。:( 不要绝望--没有杀死我们的东西使我们更强大。 我相信你！ :)
不要浪费你的时间--掌握OOP。
你在这个论坛上被完全禁止了，我的朋友。:))我也是。:( 不要绝望--杀不死我们的东西使我们更强大。 我相信你！！ :)
让我们从大型机制的实施中对类的需求问题开始。一个类是一组函数的外壳，而 "大机制 "是实现一组任务的代码块。在我的实现中，一个 "大机器 "几乎总是一个非常大的功能和一组为其服务的小功能。所谓的 "引擎"。如果你把它和服务功能塞进一个类中，什么都不会改变，如果你把它塞进不同的类中，它们之间的访问会变得更加复杂，机制效率也会降低。
如果机制的规模扩大，就有必要优化其代码或将功能分成文件。这还不够吗？此外，定期优化 一个区块的代码 会带来效率的奇迹。它不断被压缩，需要越来越多的功能来实现。也就是说，函数的数量相反地减少了。它们被概括为一个区块，其代码不断被改进。这是 一条直接通往效率的道路 。
此外，如果我们使重要的变量成为全局变量，它们将在机制中随处可见，并且很容易处理它们，如果我们为它们定义作用域，从机制效率的角度看，这将产生多余的任务。再次，访问的复杂性。创建类对象，等等......将机制分割成大量功能的趋势不仅破坏了效率，也破坏了代码块的通用性。事实证明，每个具体的任务都需要一个单独的函数，而代码块的通用性根本没有得到改善。调用和传递的参数数量也在增长。这并不能使机制更有效率，但这种趋势实际上是由OOP推动的。
当一个项目由一个程序员团队处理时，OOP的效率更高。在这种情况下，你不能没有它。虽然，如果你想一想，你也可以在这里找到一种方法来避免......
但当然，这些都是文字。在实践中，我会很快证明我在说什么。
而这是有道理的。OOP的创造者Alan Kay， 实际上他的想法与今天的OOP的含义非常不同。这与你的设想更加相似。我有一个想法，要创建一个有一个核心的项目，并为一些功能调用它的服务。而各元素之间的交流将只通过事件--信息发生。只要你发送一个带有数据的事件请求，你就会收到带有结果的事件回复。不存在继承、多态性或包容。
顺便说一下，用这种方法实现多线程比较容易，因为根据定义，所有的元素都是相互独立工作的。
这里面有一些东西。OOP的创造者Alan Kay， 他的想法与今天的OOP含义不同。这与你的设想更加相似。我有一个想法，要创建一个有一个核心的项目，并为一些功能调用它的服务。而各元素之间的交流将只通过事件--信息发生。只要你发送一个带有数据的事件请求，你就会收到带有结果的事件回复。不存在继承、多态性或包容。
顺便说一下，用这种方法，多线程更容易组织，因为根据定义，所有元素都是相互独立工作的。