抽象方法和虚拟方法有什么区别?在哪些情况下,建议使用抽象方法或虚拟方法?哪一种是最好的方法?


当前回答

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

这是主要的区别。

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

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

其他回答

如果一个类从这个抽象类派生,那么它将被强制重写抽象成员。这与虚修饰符不同,虚修饰符指定可以可选地重写成员。

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

上下文

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

FireEscape()

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

这基本上是一个名为FireEscape()的虚拟方法

虚拟方法

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

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

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

抽象方法

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

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

这两者又有什么区别?

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

现在这并不难,是吗?

我通过对以下课程(从其他答案)进行一些改进,使这一点更简单:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TestOO
{
    class Program
    {
        static void Main(string[] args)
        {
            BaseClass _base = new BaseClass();
            Console.WriteLine("Calling virtual method directly");
            _base.SayHello();
            Console.WriteLine("Calling single method directly");
            _base.SayGoodbye();

            DerivedClass _derived = new DerivedClass();
            Console.WriteLine("Calling new method from derived class");
            _derived.SayHello();
            Console.WriteLine("Calling overrided method from derived class");
            _derived.SayGoodbye();

            DerivedClass2 _derived2 = new DerivedClass2();
            Console.WriteLine("Calling new method from derived2 class");
            _derived2.SayHello();
            Console.WriteLine("Calling overrided method from derived2 class");
            _derived2.SayGoodbye();
            Console.ReadLine();
        }
    }


    public class BaseClass
    {
        public void SayHello()
        {
            Console.WriteLine("Hello\n");
        }
        public virtual void SayGoodbye()
        {
            Console.WriteLine("Goodbye\n");
        }

        public void HelloGoodbye()
        {
            this.SayHello();
            this.SayGoodbye();
        }
    }


    public abstract class AbstractClass
    {
        public void SayHello()
        {
            Console.WriteLine("Hello\n");
        }


        //public virtual void SayGoodbye()
        //{
        //    Console.WriteLine("Goodbye\n");
        //}
        public abstract void SayGoodbye();
    }


    public class DerivedClass : BaseClass
    {
        public new void SayHello()
        {
            Console.WriteLine("Hi There");
        }

        public override void SayGoodbye()
        {
            Console.WriteLine("See you later");
        }
    }

    public class DerivedClass2 : AbstractClass
    {
        public new void SayHello()
        {
            Console.WriteLine("Hi There");
        }
        // We should use the override keyword with abstract types
        //public new void SayGoodbye()
        //{
        //    Console.WriteLine("See you later2");
        //}
        public override void SayGoodbye()
        {
            Console.WriteLine("See you later");
        }
    }
}

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

这是主要的区别。

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

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

上面的大多数示例都使用代码,而且非常好。我不需要补充他们所说的内容,但以下是一个简单的解释,使用了类比而不是代码/技术术语。

简单解释-使用类比进行解释

抽象方法

想想乔治·W·布什。他对士兵们说:“去伊拉克打仗吧”。就这样,他所说的就是必须战斗。他没有具体说明这将如何发生。但我的意思是,你不能只是出去“战斗”:那到底意味着什么?我是用B-52还是我的人字架?这些具体细节留给其他人。这是一种抽象方法。

虚拟方法

大卫·彼得雷乌斯在军队中地位很高。他定义了战斗的含义:

找到敌人中和他。之后喝杯啤酒

问题是这是一种非常通用的方法。这是一个有效的好方法,但有时不够具体。对彼得雷乌斯来说,好事是他的命令有回旋余地和范围——他允许其他人根据他们的特殊要求改变他对“战斗”的定义。

私人职业博客阅读彼得雷乌斯的命令,并根据他的特殊要求获得了实施自己版本的战斗的许可:

找到敌人。朝他的头部开枪。回家吧喝啤酒。

努里·马利基也收到彼得雷乌斯的同样命令。他也要战斗。但他是一名政治家,而不是一名步兵。显然,他不能四处射击他的政治敌人的头部。因为彼得雷乌斯给了他一种虚拟的方法,所以马利基可以根据自己的具体情况,实施自己的战斗方法:

找到敌人。让他以一些捏造的罪名被捕。回家吧喝啤酒。

换言之,虚拟方法提供了样板指令——但这些是一般指令,可以由军队继承人根据他们的具体情况做出更具体的说明。

两者之间的区别

乔治·布什没有证明任何实施细节。这必须由其他人提供。这是一种抽象方法。另一方面,彼得雷乌斯确实提供了实施细节,但他已经允许他的下属,如果他们能想出更好的办法,可以用自己的版本推翻他的命令。

希望这会有所帮助。