在C#中使用抽象类 [英] use of abstract class in c#

问题描述

我知道什么是抽象类，但是这次我想知道如何使用抽象类.请给我一些例子或文章.我想上这堂课...请指导我.....

I know what is Abstract class but this time i want to know how i can use abstract class. please give me some examples or articles . i want to work on this class ...please guide me.....

推荐答案

为什么不尝试

Why not you try Google Search.


Hope this help!

public abstract class Duck//Abstract class
{
    public Duck()//Constructor
    {
    }
    
     public abstract void display();//abstract method
}

抽象类将具有将成为抽象方法的方法.这意味着将从"Duck"继承的子类将具有称为"Display"的相同抽象方法.

An abstract class will have a method that will be an abstract method. This means a child class that will inherit from "Duck" will have the same abstract method called "Display"

public class Mallack:Duck
{
    public Mallack()//Constructor
    {
    }
     
    public override void display()
    {
        //Place the code that changes every time HERE
    }
}

Mallack是从Duck继承的子类.请记住，将从Duck继承的所有clase都将使用"display"方法




希望对您有帮助...

The Mallack is a child class that inherits from Duck. Remember all clases that will inherit from Duck will have the method "display"




Hope it helps...

显然，如果您知道那是什么，就知道您无法实例化此类.您还应该知道，如果只有一个抽象方法或属性(始终是虚拟的且没有实现)，则语法将强制您将整个类声明为abstract.

现在，让我们逻辑地推测.如果无法创建类实例，该怎么办?您可以创建此抽象类的一些派生类.一些派生类可以是抽象的，但是最终您将需要创建一些非抽象的并且可以实例化的终端类，否则整个活动可能就没有用了.

因此，您的抽象类将成为所有层次结构的抽象基础.层次结构中的非抽象类应覆盖所有抽象方法/属性，否则您将无法使它们成为非抽象类.这些方法将通过虚拟方法表机制动态调度，这是 late绑定的本质.

现在，您应该了解运行时类型和编译时类型之间的区别.您可以声明任何类型的变量，包括抽象类.实例化变量时，其运行时类型不能为抽象类(请记住，无法实例化)，因此其运行时类型应不同于编译时类型，并且应为派生类之一，并且只有一个非抽象的.当您调用抽象方法(从编译时的角度来看)时，动态分派的运行时方法将始终是在派生类中实现的方法，始终是非抽象的方法.为什么?因为1)您不能在非抽象类中使用抽象方法，所以2)您不能实例化非抽象类.通话将始终得到正确解决.

使用 polymorphous 集也会发生相同的情况.编译时类型可以是抽象类(例如，System.Collections.Generic.List的实际通用参数)，但是实际上已添加到此容器中的对象的所有运行时类型……是的，如上一段所述. />
因此，一切都适用于后期绑定和polymorphism.现在的问题是:我们从未使用过抽象类是否可以奏效?是的，它会以完全相同的方式工作.只有我们需要使用关键字virtual来实现所有否则将是抽象的方法.例如，这样的方法将具有空的主体(如果我们希望它们不是抽象的，那么无论如何我们都将需要一些主体).通常，此类方法称为伪抽象.怎么了?

答案是:不过没什么错–声明抽象类将作为一种防呆的功能.伪抽象方法只有在它们仍然可以参与正常功能的情况下才是好的.例如，伪抽象方法ShowMessage可能默认"不显示任何内容，但是可以在派生类中对其进行自定义.但是，在更多情况下，如果没有某些特定的实现，而没有一种或多种方法的确定行为会真正破坏功能.因此，意外实例化和使用此类对象可能会破坏系统的功能.

没有抽象类，该怎么办? (以前的OOP语言确实没有它们.)我们可以解释说，这个和这个类(例如System.IO.Stream)绝不能实例化，并且只能用作以下类的基础……以及用户定义的类，以及列出它们-在文档中.但是，仅通过语法防止此类意外滥用会更好.

您可以在.NET随附的库中找到许多抽象类的示例，这些类位于GAC中.试着考虑它们的用途；您将清楚地了解它.

—SA

Apparently, if you know what is that, you know that you cannot instantiate such class. You also should know, that if you have a single abstract method or property (which is always virtual and without implementation), the syntax will force you to declare the whole class as abstract.

Now, let''s speculate logically. If you cannot create the class instance, what you can do? You can create some derived classes of this abstract class. Some derived classes can be abstract, but ultimately you will need to create some terminal classes which are not abstract and can be instantiated, otherwise the whole activity could be useless.

So, you abstract class would be the abstract base for all the hierarchy. And the non-abstract classes from the hierarchy should override all abstract methods/properties, otherwise you would not be able to make them non abstract. The methods will be dynamically dispatched through the mechanism of virtual method table, which is the essence of late binding.

Now, you should understand the difference between run-time and compile-time types. You can declare a variable of any type, including the abstract class. When you instantiate the variable, its run-time type could not be of the abstract class (remember, it cannot be instantiated), so its run-time type should be different from compile-time type, and should be one of the derived classes, and only of a non-abstract one. When you call an abstract method (from the standpoint of the compile-time), the dynamically dispatched run-time method will always be the one implemented in the derived class, always non-abstract one. Why? Because 1) you cannot have an abstract method in a non-abstract class, 2) you cannot instantiate a non-abstract class. The call will always be properly resolved.

Same thing will happens with a polymorphous set. The compile-time type can be an abstract class (for example, the actual generic parameter of System.Collections.Generic.List), but all run-time types of the objects actually added to this container… yes, as described in the previous paragraph.

So, everything works for late binding and polymorphism. Now, the question is: could it work of we never used abstract class. Yes, it would work in the exact same way. Only we would need to implement all the methods which would otherwise be abstract using the keyword virtual instead. For example, such methods would have empty bodies (we would need some bodies anyway, if we want them non-abstract). Usually such methods are called pseudo-abstract. What would be wrong with that?

The answer is: nothing wrong but — declaring abstract class would work as a fool-proof feature. A pseudo-abstract methods are only good if they still could participate in normal functionality. For example, a pseudo-abstract method ShowMessage could show nothing "by default", but this could be customized in derived classes. But there are more cases where having no certain definitive behavior of one or more method would really screw up the functionality without some specific implementation. Hence, an accidental instantiation and use of such object could screw up the functionality of the system.

Without abstract classes, what could be done? (Yearly OOP languages really did not have them.) We could explain that this and this class (such as System.IO.Stream) should never be instantiated and is only used as a base of the following classes… and also user-defined classes, and list them — in documentation. But preventing such accidental misuse just by syntax is much better.

You can find many examples of abstract classes in the libraries which come with .NET and placed in GAC. Try to think about their use; and you will clearly understand it.

—SA

这篇关于在C#中使用抽象类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！