计划效率

Question

我想知道，与任何编程语言中的结构化编程方法相比，采用面向对象的方法来解决问题是否会对程序效率产生影响，特别是在c ++中。

Answer 1

也许。 也许不吧。

您可以编写有效的面向对象代码。 您可以编写效率低下的结构化代码。

这取决于应用程序，代码编写的程度以及代码的优化程度。 通常，您应该编写代码，使其具有良好，干净，模块化的体系结构并且设计良好，然后如果您遇到性能问题，则优化导致性能问题的热点。

使用面向对象的编程，使用它是有意义的，并使用结构化编程，使用它是有意义的。 您不必在一个和另一个之间进行选择：您可以同时使用两者。

Answer 2

我记得在20世纪90年代早期，当C ++年轻的时候，有关于此的研究。 如果我没记错的话，那些接受（编写好的）C ++程序并用C语言重新编写它们的人的速度提高了大约15％。 那些接受C程序并用C ++重新编码的人，并将C的命令式样式修改为OO风格（但相同的算法），C ++获得了相同或更好的性能。 观察到C语言被转化为面向对象的风格变得更加有条理，这就解释了明显的矛盾。 你在C中所做的事情是因为代码太多而且做得更好也很容易在C ++中正确完成。

回想一下，我对这个结论感到疑惑。 第二次编写程序总会产生一个更好的程序，所以它不一定是OO风格的必要条件。 今天的计算机体系结构设计有对OO程序完成的常见操作的硬件支持，并且编译器在使用指令方面已经变得更好，所以我认为在1992年虚拟函数调用的任何开销都可能远远小于今天。

Answer 3

没有必要，如果你非常小心避免它。 如果你只是采用最简单的方法，使用动态分配，虚函数和（特别是）按值传递对象，那么肯定会有效率低下。

Answer 4

它不一定是。 算法是最重要的。 我同意封装将减慢你的速度，但编译器会在那里进行优化。

Answer 5

如果这是计算机科学论文中的问题，你会说不。

然而，在真实的开发环境中，如果正确使用OOP范例，这往往是正确的。 原因是在实际开发过程中，我们通常需要维护我们的代码库，以及OOP范例可以帮助我们的时间。 与C类结构化编程相比，OOP的一个优点是在OOP中更容易使代码可维护。 当代码更易于维护时，它意味着更少的bug，更少的时间来修复错误，减少实现新功能所需的时间。 最重要的是，我们将有更多时间专注于应用程序的效率。

Answer 6

问题不是技术问题，而是心理问题。 它是通过简化它来鼓励你做的事情。

为了做一个世俗的比喻，它就像一张信用卡。 它比写支票或使用现金更有效率。 如果是这样，为什么人们会用信用卡遇到这么多麻烦？ 因为它们很容易使用，所以它们会滥用它们 。 不要过度使用好东西需要很大的纪律。

OO滥用的方式是

• 创建太多“抽象层”

• 创建过多的冗余数据结构

• 鼓励使用通知式代码，尝试在冗余数据结构中保持一致性。

最好是最小化数据结构，如果它必须是冗余的，则能够容忍暂时的不一致。

补充：作为OO鼓励的事情的例证，这是我在性能调整中有时看到的：有人设置SomeProperty = true; 。 这听起来很无辜，对吧？ 好吧，它可以波及包含该对象的对象，通常是通过难以追踪的多态性。 这可能意味着某些列表或字典需要添加到其中或从中删除。 这可能意味着某些树或列表控件需要添加或删除或改组控件。 这可能意味着正在创建或销毁窗口。 它也可能意味着需要在数据库中更改某些内容，这可能不是本地的，因此需要执行一些I / O或互斥锁定。

它真的会变得疯狂。 但谁在乎？ 这是抽象的 。

Answer 7

可能有：OO方法往往更接近于解耦方法，其中不同的模块不会在彼此内部进行探索。 它们仅限于公共接口，并且总是存在潜在的成本。 例如，调用getter而不是直接检查变量; 或者默认调用虚函数，因为对象的类型对于直接调用来说不够明显。

也就是说，有几个因素可以减少这一点作为有用的观察结果。

1. 编写良好的结构化程序应具有相同的模块性（即隐藏实现），因此产生相同的间接成本。 在C中调用函数指针的成本可能与在C ++中调用虚函数的成本非常相似。

2. 现代JIT，甚至在C ++中使用内联方法，都可以消除间接成本。

3. 成本本身可能相对较小（通常每个指令调用只需几个简单的操作）。 这对于在紧密循环中完成实际工作的程序来说是微不足道的。

4. 最后，更加模块化的风格使程序员可以解决更复杂但更有希望的复杂算法，而不会产生低级错误。