初学OOP问题

Question

我只想问两个关于OOP的快速问题。

首先，OOP语言编译器实际生成的代码是否与过程语言编译器有什么不同？我的意思是，OOP只是关于你如何编写代码，还是实际编译的代码与程序不同？像C这样的更精确的过程语言基本上会产生类似于ASM编写的代码。但是OOP代码有什么不同吗？

第二，如果OOP代码在其机器代码形式中使用不同的方法，它是否比程序更慢或更快？感谢。

Answer 1

首先，没有。对于编译为本机机器代码的语言，这当然是正确的。毕竟，装配和机器代码没有对象的概念。

对于在Java或C＃等虚拟机中运行的语言，这部分属实。在这里，VM可能支持某些特定于对象的功能。

可以用非面向对象的语言编写OOP，反之亦然。 OOP主要用于程序员，它所强加的限制（例如，你不能从另一个类访问私有方法）由编译器检查，但不在输出中传递。

其次，OOP或程序没有性能差异。只是代码和数据位于代码中的不同位置。

Answer 2

这在很大程度上取决于您尝试实现的实际算法，以及编译器（过去几年中已经非常聪明的算法）。编译后的代码绝对不会逐字节相同，甚至可能完全不同（再次，取决于您正在实现的算法）。实际上，没关系。

在大多数情况下，程序的速度差异可以忽略不计 - 除非你在一种形式或另一种形式上做一些非常低效的事情（这很可能与你的业务逻辑和你将使用的算法有关）实现它，而不是编程范式），这不会是一个问题。

另一个经常被忽视但又至关重要的速度差异在于可维护性：在大多数情况下，计算机时间便宜;程序员时间很贵。 （这并不是说“写臃肿软件”，而是“不要浪费一个星期来确定它是如何工作的，当其他人需要更新逻辑时，三年后”）

Answer 3

所有语言都生成相同的代码，例如ASM（机器代码）， 除了产生字节码（例如：Java）或解释语言（例如：Python，PHP）的语言

Answer 4

我不完全确定程序代码和面向对象代码之间的实际性能差异，尽管我坚信它不应该在一天结束时产生很大的差异。

但是，任何理解不同OO原则的程序员都可以更轻松地阅读和理解OO代码，因为它可以轻松抽象出不同的复杂性。

基本上，我的观点如下：拥有更容易读取，重复使用和维护的代码可以轻松证明性能损失很小（如果有的话），时间。

Answer 5

所有代码最终归结为机器代码。只有某些方法可以在内存中表示数据。我想，ASM代码完全取决于编译器，如果你正在执行优化。对于字节码编译语言，源被编译为字节码，然后通过解释器运行。甚至可能有一个JIT（Just-In-Time）编译器将该字节码编译成本机机器码。

您必须意识到OOP是一种抽象或范例，使程序员可以轻松解决问题。因此，它对效率没有任何实际影响。汇编代码通常有一个处理描述或分配数据的部分，另一部分用于程序代码。所以所有编译的代码都会以这种状态结束。

如果您真的关心生成的代码的效率，那么您应该查看编译器本身并阅读它们生成的代码类型。大多数现代编译器都执行各种优化（您甚至可以告诉他们您想要的优化级别）。当然，当您在嵌入式环境中进行编程时，这通常会发挥作用。

范式主要与效率无关，但当然，某些语言在某些环境中更有效。例如，C在嵌入式环境中表现很好。最终目标是为工作选择合适的工具。例如，我确信你可以使用brainf ck编写嵌入代码，但是brainf ck不是一种非常方便的语言。使用C可能会更好。如果你想进行嵌入式编程，但想要使用OOP范例，你可以尝试使用嵌入式C ++甚至是嵌入式Java。

Answer 6

从根本上说，所有计算机程序都是程序性的，因为它们在CPU上执行一系列步骤。由编译器为过程语言生成的机器代码和用于面向对象语言的机器代码可以非常相似。 OOP只是一种替代抽象 - 一种使代码更易于维护且易于编写的工具。

OOP通常不比程序更快/更慢。考虑到通过选择有效的算法而不是优化单个指令来获得最大的速度增益，这无论如何都无关紧要。基准测试往往太有争议，没有价值。

Answer 7

在效率和可维护性之间总是存在一些妥协。

尽管程序可以更快地执行（虽然不一定显着，并且这都是相对的......），但是您无法使用过程代码实现可扩展项目。 OOP并不是为了优化应用程序的性能，而是帮助开发人员使用编程语言解决实际问题。由于应用程序需要越来越复杂的用户界面，业务模型并且往往具有更长的生命周期，因此OOP是一种非常适合当今每个项目的解决方案。

最后，OOP与否，本机编译器将生成ASM代码或VM将生成字节码（对于JIT编译器）。重要的是不要将OOP范例与编译代码混合在一起;计算机不关心代码是如何组织的，并且将执行它。当然，程序代码与编译后的OOP不同。但是，我不会说OOP只是“关于你如何编写代码”，只是因为程序应用程序的性能总是随着项目的扩展而下降得比OOP更快。

Answer 8

实际上，通常Objected Oriented代码会导致（非常）慢一些。这样做的原因是对象和类有开销 - 即使实际代码变得程序化，在后台仍然有“东西”。可以在这里找到C和C ++的一个很好的比较：

http://unthought.net/c++/c_vs_c++.html（看看页面的大约一半，或者对文字进行搜索“相差很大！567％”，如果你想直接看到令人惊讶的一点）。

它有点旧但仍然非常有效。但在大多数情况下，速度提升并不值得花费额外的时间来编写代码 - 这是一个非常极端的例子，并且记住C是一种非常低级的语言;事实上，我不知道在任何其他语言中如何全面地通过直接速度测试击败C ++。

另请注意，写得不好的程序代码几乎总是比编写良好的OO代码慢（我想有人已经提到过这一点）。