程序效率
我想知道与任何编程语言（特别是 C++）中的结构化编程方法相比，采用面向对象的方法来解决问题是否会对程序效率产生影响。
I want to know whether there is an effect on program efficiency by adopting object oriented approach to a problem as compared to the structured programming approach in any programming language but specially in c++.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
或许。也许不是。
您可以编写高效的面向对象代码。您可能会编写低效的结构化代码。
这取决于应用程序、代码编写得如何以及代码的优化程度。一般来说，您应该编写代码，使其具有良好、干净、模块化的架构并且设计良好，然后，如果您遇到性能问题，请优化导致性能问题的热点。
在有意义的地方使用面向对象编程，在有意义的地方使用结构化编程。您不必在其中之一中进行选择：您可以同时使用两者。
Maybe. Maybe not.
You can write efficient object-oriented code. You can write inefficient structured code.
It depends on the application, how well the code is written, and how heavily the code is optimized. In general, you should write code so that it has a good, clean, modular architecture and is well designed, then if you have problems with performance optimize the hot spots that are causing performance issues.
Use object oriented programming where it makes sense to use it and use structured programming where it makes sense to use it. You don't have to choose between one and the other: you can use both.
我记得早在 1990 年代初，当 C++ 还很年轻时，就有过相关研究。如果我没记错的话，那些采用（编写良好的）C++ 程序并用 C 重新编码的人的速度提高了大约 15%。那些采用 C 程序并用 C++ 重新编码，并将 C 的命令式风格修改为 C++ 的 OO 风格（但算法相同）的人获得了相同或更好的性能。这种明显的矛盾可以通过以下观察来解释：C 程序在转换为面向对象的风格后，组织变得更好。您在 C 中所做的事情，因为代码太多且难以做得更好，而在 C++ 中可以更轻松地正确完成。
回想起来，我对这个结论有些好奇。第二次编写程序总会产生更好的程序，因此不一定非要采用 OO 风格才能产生差异。当今的计算机体系结构的设计具有对 OO 程序执行的常见操作的硬件支持，并且编译器在使用指令方面已经变得更好，因此我认为无论 1992 年虚拟函数调用的开销如何，今天都可能要小得多。
I remember back in the early 1990's when C++ was young there were studies done about this. If I remember correctly, the guys who took (well written) C++ programs and recoded them in C got around a 15% increase in speed. The guys who took C programs and recoded them in C++, and modified the imperative style of C to an OO style (but same algorithms) for C++ got the same or better performance. The apparent contradiction was explained by the observation that the C programs, in being translated to an object oriented style, became better organized. Things that you did in C because it was too much code and trouble to do better could more easily be done properly in C++.
Thinking back about this I wonder about the conclusion some. Writing a program a second time will always result in a better program, so it didn't have to be imperative to OO style that made the difference. Todays computer architectures are designed with hardware support for common operations done by OO programs, and compilers have gotten better at using the instructions, so I think that it is likely that whatever overhead a virtual function call had in 1992 it is far smaller today.
如果您非常小心地避免它，则不一定有。如果您只是采用最直接的方法，使用动态分配、虚函数和（尤其是）按值传递对象，那么是的，效率会很低。
There doesn't have to be, if you are very careful to avoid it. If you just take the most straightforward approach, using dynamic allocation, virtual functions, and (especially) passing objects by value, then yes there will be inefficiency.
不一定是这样。算法就是一切。我同意封装会减慢你的速度，但是编译器可以进行优化。
It doesn't have to be. Algorithm is all matters. I agree encapsulation will slow you down little bit, but compilers are there to optimize.
如果这是计算机科学论文中的问题，你会说不。
然而，在真实的开发环境中，如果正确使用 OOP 范式，这往往是正确的。原因是，在实际的开发过程中，我们通常需要维护我们的代码库，此时OOP范式可以帮助我们。与 C 等结构化编程相比，OOP 的一大优点是 OOP 更容易使代码易于维护。当代码更易于维护时，这意味着错误更少，修复错误的时间更少，实现新功能所需的时间也更少。最重要的是，我们将有更多时间关注应用程序的效率。
You would say no if this is the question in computer science paper.
However in the real development environment this tends to be true if the OOP paradigm is used correctly. The reason is that in real development process, we generally need to maintain our code base and that the time when OOP paradigm could help us. One strong point of OOP over structured programming like C is that in OOP it is easier to make the code maintainable. When the code is more maintainable, it means less bug and less time to fix bug and less time needed for implementing new features. The bottom line is then we will have more time to focus on the efficiency of the application.
问题不是技术性的，而是心理性的。它通过让事情变得简单来鼓励你去做。
打个通俗的比喻，它就像一张信用卡。它比写支票或使用现金更有效率。如果是这样的话，为什么人们在信用卡方面会遇到这么多麻烦呢？因为它们太容易使用了，以至于他们滥用它们。不过度使用好东西需要严格的纪律。
OO 被滥用的方式是
创建太多的“抽象层”
创建太多的冗余数据结构
最好尽量减少数据结构，如果一定要冗余，能够容忍暂时的不一致。
额外：
作为 OO 鼓励的事情的例证，以下是我有时在性能调优中看到的情况：有人设置了
SomeProperty = true;。这听起来很无辜，对吧？嗯，这可能会波及到包含该对象的对象，通常是通过难以追踪的多态性。这可能意味着某个地方的某个列表或字典需要添加或删除内容。这可能意味着某些树或列表控件需要添加、删除或重新排列控件。这可能意味着正在创建或销毁窗口。它还可能意味着需要更改数据库中的某些内容，这些内容可能不是本地的，因此需要执行一些 I/O 或互斥锁定。它真的会变得疯狂。但谁在乎呢？它是抽象。
The problem is not technical, it is psychological. It is in what it encourages you to do by making it easy.
To make a mundane analogy, it is like a credit card. It is much more efficient than writing checks or using cash. If that is so, why do people get in so much trouble with credit cards? Because they are so easy to use that they abuse them. It takes great discipline not to over-use a good thing.
The way OO gets abused is by
Creating too many "layers of abstraction"
Creating too much redundant data structure
Encouraging the use of notification-style code, attempting to maintain consistency within redundant data structures.
It is better to minimize data structure, and if it must be redundant, be able to tolerate temporary inconsistency.
ADDED:
As an illustration of the kind of thing that OO encourages, here's what I see sometimes in performance tuning: Somebody sets
SomeProperty = true;. That sounds innocent enough, right? Well that can ripple to objects that contain that object, often through polymorphism that's hard to trace. That can mean that some list or dictionary somewhere needs to have things added to it or removed from it. That can mean that some tree or list control needs controls added or removed or shuffled. That can mean windows are being created or destroyed. It can also mean some things need to be changed in a database, which might not be local so there's some I/O or mutex locking to be done.It can really get crazy. But who cares? It's abstract.
可能是这样：面向对象的方法往往更接近于解耦的方法，其中不同的模块不会互相干扰。它们仅限于公共接口，并且这始终存在潜在的成本。例如，调用 getter 而不是直接检查变量；或者默认调用虚函数，因为对象的类型对于直接调用来说不够明显。
也就是说，有几个因素削弱了这一观察的有用性。
一个编写良好的结构化程序应该具有相同的模块化（即隐藏实现），因此会产生相同的间接成本。在 C 中调用函数指针的成本可能与在 C++ 中调用虚函数的成本非常相似。
现代 JIT，甚至在 C++ 中使用内联方法，都可以消除间接成本。
成本本身可能相对较小（通常每个指令调用只需一些额外的简单操作）。这对于实际工作是在紧密循环中完成的程序来说是微不足道的。
最后，更加模块化的风格可以让程序员自由地处理更复杂但希望不那么复杂的算法，而不会出现低级错误的危险。
There could be: the OO approach tends to be closer to a decoupled approach where different modules don't go poking around inside each other. They are restricted to public interfaces, and there is always a potential cost in that. For example, calling a getter instead of just directly examining a variable; or calling a virtual function by default because the type of an object isn't sufficiently obvious for a direct call.
That said, there are several factors that diminish this as a useful observation.
A well written structured program should have the same modularity (i.e. hiding implementations), and therefore incur the same costs of indirection. The cost of calling a function pointer in C is probably going to be very similar to the cost of calling a virtual function in C++.
Modern JITs, and even the use of inline methods in C++, can remove the indirection cost.
The costs themselves are probably relatively small (typically just a few extra simple operations per instruction call). This will be insignificant in a program where the real work is done in tight loops.
Finally, a more modular style frees the programmer to tackle more complicated, but hopefully less complex algorithms without the peril of low level bugs.