Abstract classes represent intangible entities. Object-oriented applications should model the real world, which is full of intangible concepts. For example, a geometric shape is a concept. Have you even seen a geometric shape? No. Rather, you have seen specific shapes, such as triangles, ellipses, rectangles, and lines. Geometric shape is a description of an intangible concept —a kind of shape. Conversely, a rectangle is tangible: a television, a box, and this book are actual rectangles.

The Employee class presented in this section is an abstract class. Why? Employee is not tangible. You do not hire a generic employee. Instead, you hire a specific kind of employee: an hourly, salaried, or commissioned employee. The Employee class represents the generic employee, while HourlyEmployee, SalariedEmployee, and CommissionedEmployee classes represent specific, tangible employees. Abstract classes also are typically incomplete. Because an abstract class is incomplete, you cannot create an instance of that type. For example, the Employee class has no method for paying an employee. It is incomplete and correctly marked as abstract.

The abstract keyword makes a class abstract. Abstract classes exist primarily for inheritance. You cannot create an instance of an abstract class. Nonabstract classes are concrete classes. You can create an instance of a concrete class. Static classes, value types, and interfaces do not support the abstract modifier.

In the next example, Employee is the base class and is abstract. HourlyEmployee is the derived class and is concrete. Since Employee is abstract, you cannot create a new instance. A compiler error will occur if you attempt to create an instance of the Employee class:

public class Starter {
    public static void Main() {
        Employee obj1 = new Employee();              // Not valid
        HourlyEmployee obj2 = new HourlyEmployee();  // Valid
    }
}

public abstract class Employee { // abstract
}

public class HourlyEmployee : Employee {  // concrete
}

Member functions also can be abstract. Methods, properties, indexers, and events can be abstract. A class with one or more abstract members must be abstract as well. An abstract member has a signature but no function body. The virtual keyword is implied with abstract functions because an abstract function member must be overridden and implemented in the derived type. Finally, static members cannot be abstract.

In the real world, a parent can ask a child to do something with or without instructions. The parent can provide instruction to the child to complete the task. Alternatively, the child must complete the task without help—the parent does not provide any directions. In this case, the parent does not care about the details of the implementation. An abstract function is an example of the latter. Abstract methods are a means of assuring that derived types (children) implement required methods. The derived type inherits no implementation (instructions) from the base type (parent). If the derived type is concrete, it must implement all inherited abstract functions. If not, the derived type is incomplete and in error.

In the following code, the Employee class mandates that derived types implement the CalculatePay method. Because the class contains an abstract method, the Employee class also must be abstract:

public abstract class Employee {
    public virtual void Pay() {
    }

    public abstract void CalculatePay();
}

public class HourlyEmployee : Employee {
    public override void Pay() {
        CalculatePay();
    }

    public override void CalculatePay() {
    }
}

Here is an example of an abstract property:

public abstract class ZClass {
    public abstract int PropA {
        get;
        set;
    }
}

public class YClass : ZClass {
    public override int PropA {
        get {
           return 0;
        }
        set {
        }
    }
}