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

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

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

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

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

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

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

绑定是将名称映射到代码单元的过程。

后期绑定意味着我们使用名称，但延迟映射。换言之，我们首先创建/提及名称，然后让后续流程处理代码到该名称的映射。

现在考虑：

与人类相比，机器确实擅长搜索和排序与机器相比，人类确实擅长发明和创新

因此，简单的答案是：virtual是机器（运行时）的后期绑定指令，而abstract是人类（程序员）的后期约束指令

换句话说，虚拟意味着：

亲爱的运行时，通过执行您最擅长的操作将适当的代码绑定到此名称：搜索

抽象意味着：

亲爱的程序员，请尽你所能将适当的代码绑定到这个名字上：发明

为完整起见，重载意味着：

“亲爱的编译器，通过做你最擅长的事情，将适当的代码绑定到这个名称：排序”。

抽象函数不能有主体，必须由子类重写

虚函数将有一个主体，并且可以或不可以被子类重写

抽象函数没有实现，只能在抽象类上声明。这迫使派生类提供实现。

虚拟函数提供默认实现，它可以存在于抽象类或非抽象类上。

例如：

public abstract class myBase
{
    //If you derive from this class you must implement this method. notice we have no method body here either
    public abstract void YouMustImplement();

    //If you derive from this class you can change the behavior but are not required to
    public virtual void YouCanOverride()
    { 
    }
}

public class MyBase
{
   //This will not compile because you cannot have an abstract method in a non-abstract class
    public abstract void YouMustImplement();
}

解释：用类比。希望这对你有帮助。

上下文

我在一栋楼的21层工作。我对火很偏执。时不时地，在世界的某个地方，一场大火正在烧毁一座摩天大楼。但幸运的是，我们在这里有一本指导手册，说明发生火灾时该怎么做：

FireEscape（）

不要收集物品步行至消防通道走出大楼

这基本上是一个名为FireEscape（）的虚拟方法

虚拟方法

这个计划对99%的情况都很好。这是一个可行的基本计划。但有1%的可能性是消防通道被堵塞或损坏，在这种情况下，你会彻底完蛋，除非你采取一些激烈的行动，否则你会被烤焦。使用虚拟方法，您可以做到这一点：您可以使用自己版本的计划覆盖基本的FireEscape（）计划：

运行到窗口跳出窗口降落伞安全到达底部

换句话说，虚拟方法提供了一个基本的计划，如果需要的话可以重写。如果程序员认为合适，子类可以重写父类的虚拟方法。

抽象方法

并非所有组织都训练有素。一些组织不进行消防演习。他们没有全面的逃跑政策。每个人都是为了自己。管理层只对现有的这种政策感兴趣。

换句话说，每个人都被迫开发自己的FireEscape（）方法。一个人会走出消防通道。另一个人会跳伞。另一个人将使用火箭推进技术飞离大楼。另一个人会用绳索离开。管理层不在乎你如何逃跑，只要你有一个基本的FireEscape（）计划——如果他们不这样做，你可以保证OHS会像一吨砖头一样砸在组织身上。这就是抽象方法的含义。

这两者又有什么区别？

抽象方法：子类被迫实现自己的FireEscape方法。使用虚拟方法，你有一个基本的计划等着你，但如果不够好，你可以选择实施自己的计划。

现在这并不难，是吗？

在这里，我写了一些示例代码，希望这可能是一个非常实际的例子，可以从非常基本的层面上看到接口、抽象类和普通类的行为。如果您想将其用作演示，也可以在github中找到此代码作为项目：https://github.com/usavas/JavaAbstractAndInterfaceDemo

public interface ExampleInterface {

//    public void MethodBodyInInterfaceNotPossible(){
//    }
    void MethodInInterface();

}

public abstract class AbstractClass {
    public abstract void AbstractMethod();

    //    public abstract void AbstractMethodWithBodyNotPossible(){
    //
    //    };

    //Standard Method CAN be declared in AbstractClass
    public void StandardMethod(){
        System.out.println("Standard Method in AbstractClass (super) runs");
    }
}

public class ConcreteClass
    extends AbstractClass
    implements ExampleInterface{

    //Abstract Method HAS TO be IMPLEMENTED in child class. Implemented by ConcreteClass
    @Override
    public void AbstractMethod() {
        System.out.println("AbstractMethod overridden runs");
    }

    //Standard Method CAN be OVERRIDDEN.
    @Override
    public void StandardMethod() {
        super.StandardMethod();
        System.out.println("StandardMethod overridden in ConcreteClass runs");
    }

    public void ConcreteMethod(){
        System.out.println("Concrete method runs");
    }

    //A method in interface HAS TO be IMPLEMENTED in implementer class.
    @Override
    public void MethodInInterface() {
        System.out.println("MethodInInterface Implemented by ConcreteClass runs");

    //    Cannot declare abstract method in a concrete class
    //    public abstract void AbstractMethodDeclarationInConcreteClassNotPossible(){
    //
    //    }
    }
}