“作为经验法则，使所有的方法虚拟”在C ++ - 声音建议？ [英] "As a rule of thumb, make all your methods virtual" in C++ - sound advice?

问题描述

我刚刚发生在标题的声明。完整的报价是：

I just happened upon the statement in the title. The full quote is:

作为一个经验法则，将所有的方法都虚拟化（包括
析构函数， ），以避免与
关联的与虚拟关键字相关的问题。

As a rule of thumb, make all your methods virtual (including the destructor, but not constructors) to avoid problems associated with omission of the virtual keyword.

我在Wrox book C ++ 。 您可以将其google检查。

I found this in the Wrox book Professional C++. You can google it to check.

有什么吗？我本以为你只提供选择扩展点，而不是默认的可扩展性。例如， Herb Sutter的2001年文章如此说。从那时起，任何事情发生了巨大变化，使相反的执政规范？ （注意，我是一个C ++ noob，所以我没有在过去十年的讨论。）

Is there anything to it? I would have thought that you'd only provide select extension points, not by-default extensibility. For instance, a 2001 article by Herb Sutter says so. Has anything changed dramatically since then to make the opposite the ruling norm? (Note that I'm a C++ noob so I haven't been following the discussion for the last decade.)

推荐答案

有什么吗？

Is there anything to it?

建议是 BAD 问题。

你看，virtual关键字表示你可以或应该重写这个方法 - 它是设计的为了这。

You see, virtual keyword indicates "you can or should override this method - it was designed for this".

对于任何非平凡的任务，我不能想象一个合理的类系统，允许用户（即其他程序员）覆盖每个派生类中的每一个单一的方法。基本抽象类只有虚方法是正常的。但是，一旦你开始创建派生类，没有理由将虚拟放在一切上 - 有些方法不需要是可扩展的。

For any non-trivial task, I cannot imagine a reasonable system of classes that would allow user (i.e. other programmer) to override every single single method in every derived class. It is normal to have base abstract class with only virtual methods. However, once you start making derived classes, there's no reason for slapping "virtual" onto everything - some methods don't need to be extensible.

在任何一点的代码，无论调用哪个方法，你永远不能确定该类将做你想要的，因为有人可以覆盖你的方法，在过程中打破它（根据墨菲的定律，它会发生）。这将使你的代码不可靠，很难维护。另一个非常有趣的事情是虚拟方法在构造函数中调用的方式。基本上，通过遵循这个建议，你牺牲代码可读性/可靠性换取不做一个相当不寻常的错字。

Making everything virtual means that at any point of code, no matter which method is called, you can never be sure that the class will do what you want, because somebody could have overriden your method, breaking it in the process (According to Murphy's Law it will happen). This will make your code unreliable, and hard to maintain. Another very interesting thing is the way virtual methods are called in constructors. Basically, by following this advice you sacrifice code readability/reliability in exchange for not doing a quite uncommon typo. In my opinion, it is not worth it.

相比之下，非虚拟方法保证不管发生什么，代码，代码将始终如你所期望的工作（不计算你还没有发现的错误）。也就是说其他人不会替换你的方法破碎的替代。

In comparison, non-virtual method guarantees that no matter what happens, at this point of code, the code will always work as you expect (not counting the bugs you haven't discovered yet). I.e. somebody else won't replace your method with broken alternative.

这个建议提醒我一些新手程序员倾向于做的一个常见错误：而不是开发解决问题的简单解决方案，他们会分心，并试图使代码通用，可扩展。因此，项目需要更长的时间完成或永远不会完成 - 因为每个可能情况的通用解决方案比本地化解决方案需要更多的努力/开发时间，只限于当前的问题。

The advice reminds me a common error some newbie programmers tend to do: instead of developing simple solution that will fix the problem, they get distracted and attempt to make code universal and extensible. As a result, project takes longer to finish or never becomes complete - because universal solution for every possible scenario takes more effort/development time than a localized solution limited only to current problem at hand.

我建议不要遵循这个虚拟建议，而是坚持使用墨菲定律和< a href =http://en.wikipedia.org/wiki/KISS_principle> KISS原则。他们我工作得很好。但是，它们不能保证对其他人都很好。

Instead of following this "virtual" advice, I'd recommend to stick with Murphy's Law and KISS principle. They worked well for me. However, they are not guaranteed to work well for everybody else.

这篇关于“作为经验法则，使所有的方法虚拟”在C ++ - 声音建议？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！