当您希望继承者根据需要扩展功能时，基本上可以使用虚拟方法。

当您希望继承者实现功能时，可以使用抽象方法（在这种情况下，他们别无选择）

答案已经提供了很多次，但关于何时使用每一个的问题是设计时的决定。我认为，尝试将通用方法定义捆绑到不同的接口中，并将它们拉到适当抽象级别的类中是一种很好的做法。当最好定义一个实现一组简洁接口的非抽象类时，将一组通用的抽象和虚拟方法定义转储到一个类中会使该类不可实例化。一如既往，这取决于什么最适合您的应用程序特定需求。

抽象方法总是虚拟的。它们无法实现。

这是主要的区别。

基本上，如果您有一个虚拟方法的“默认”实现，并且希望允许后代更改其行为，那么您将使用该方法。

使用抽象方法，可以强制后代提供实现。

抽象函数“只是”签名，没有实现。它在接口中用于声明如何使用类。它必须在其中一个派生类中实现。

虚函数（实际上是方法）也是您声明的函数，应该在继承层次结构类之一中实现。

此类类的继承实例也继承实现，除非您在较低层次结构类中实现它。

抽象方法没有实现。它在父类中声明。子类负责实现该方法。

虚拟方法应该在父类中有一个实现，它有助于子类选择是使用父类的该实现，还是为子类中的该方法自己有一个新的实现。

图.-命题的传统三重分类。

在道义逻辑（义务和许可的研究）中，每个命题都是强制性的（“必须”运算符）、可选的（“可能”运算符）或不允许的（“不得”运算符），任何命题都不属于这三类中的一类。

此外，允许（“可能”运算符）命题是强制性或可选的命题，不允许（“未必”运算符）的命题是不允许或可选的，非可选（“必须或不得”运算符）是强制性或不允许的命题。

特别是，强制性命题是允许的，而不允许的命题是不允许的。

将这些运算符应用于命题“方法被覆盖”会产生以下命题：

抽象（纯）/具体方法：该方法必须被重写/不能被重写；virtual/real（final）方法：该方法可以被重写/不能被重写。

特别是，抽象方法是虚拟的，而真实方法是具体的。