C# Runtime Polymorphism: Virtual Methods and Interfaces

C# runtime polymorphism is the mechanism that resolves method calls at execution time rather than compile time. When a base class reference or interface reference points to a derived instance, the runtime determines which implementation to invoke based on the actual type of the object. This behavior is central to many object-oriented patterns, including strategy, template method, and plugin architectures.

How Virtual Methods Enable Runtime Dispatch

In C#, a method declared as virtual in a base class can be overridden in a derived class using the override keyword. The compiler emits a call that is resolved at runtime, not statically bound to the base implementation.

public class Shape
{
    public virtual double Area()
    {
        return 0;
    }
}

public class Circle : Shape
{
    private double radius;

    public Circle(double radius)
    {
        this.radius = radius;
    }

    public override double Area()
    {
        return Math.PI * radius * radius;
    }
}

public class Rectangle : Shape
{
    private double width, height;

    public Rectangle(double width, double height)
    {
        this.width = width;
        this.height = height;
    }

    public override double Area()
    {
        return width * height;
    }
}

When you call shape.Area() on a Shape variable, the runtime inspects the actual object type. If it is a Circle, the Circle.Area implementation runs; if it is a Rectangle, the Rectangle version runs. This is the essence of runtime polymorphism: the same call site can behave differently depending on the object it receives.

Interface-Based Polymorphism and Its Dispatch Behavior

Interfaces provide another form of runtime polymorphism. A class can implement one or more interfaces, and a variable typed as the interface can hold any implementing instance. The runtime resolves interface method calls to the concrete implementation.

public interface ILogger
{
    void Log(string message);
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine($"Console: {message}");
    }
}

public class FileLogger : ILogger
{
    public void Log(string message)
    {
        // Write to file
    }
}

public void Process(ILogger logger)
{
    logger.Log("Processing started");
}

Here, Process accepts any ILogger. The actual logger type is determined at runtime, and the appropriate Log method is invoked. This decouples the caller from specific implementations, enabling dependency injection and testability.

What Happens Under the Hood: Virtual Method Tables

The runtime uses a virtual method table (vtable) to resolve virtual and interface calls. Each type that has virtual methods or implements interfaces carries a table of function pointers. When a call is made, the runtime looks up the correct entry in the table for the object's actual type. This indirection adds a small overhead compared to a direct call, but it is usually negligible in application code.

For interface calls, the runtime may use an interface map or a similar structure to locate the implementing method. The exact mechanism depends on the runtime implementation, but the conceptual cost is similar: a lookup before the call.

Runtime Polymorphism vs. Compile-Time Generic Dispatch

Generics provide a form of polymorphism that is resolved at compile time. When you write List<T> or a generic method, the compiler generates specialized code for each value type and a shared implementation for reference types. This avoids the runtime lookup cost and can improve performance in tight loops.

public static T Max<T>(T a, T b) where T : IComparable<T>
{
    return a.CompareTo(b) > 0 ? a : b;
}

The generic constraint where T : IComparable<T> still uses runtime dispatch for the CompareTo call, but the type T itself is known at compile time. If you need to operate on a fixed set of types with compile-time safety, generics are often a better choice than runtime polymorphism.

Performance Considerations of Dynamic Dispatch

The main performance cost of runtime polymorphism is the indirection through the vtable. Each virtual or interface call requires an extra memory read to fetch the function pointer, and the CPU's branch predictor may not handle indirect branches as efficiently as direct calls. In most business applications, this overhead is negligible. However, in high-frequency code paths—such as per-pixel rendering or network packet processing—the cost can become measurable.

The JIT compiler sometimes applies devirtualization optimizations when it can prove the actual type at a call site. For example, if a variable is known to be a sealed class, the JIT may replace the virtual call with a direct call. This is an implementation detail and can change between runtime versions, so you should not rely on it for correctness.

If performance profiling shows that dynamic dispatch is a bottleneck, consider alternatives like generics, switch expressions, or rethinking the design to reduce the number of virtual calls.

Choosing Between Virtual Methods and Interfaces

Both virtual methods and interfaces enable runtime polymorphism, but they serve different design purposes.

Use virtual methods when you have a base class that provides common functionality and you want derived classes to extend or replace specific parts. Use interfaces when you need to define a contract that can be implemented by classes that do not share a common base, such as a logging abstraction or a repository pattern.

Common Pitfalls and Maintainability Concerns

Runtime polymorphism introduces subtle issues if not used carefully. One classic mistake is calling a virtual method from a constructor. When a base class constructor runs, the derived class's fields are not yet initialized. If the virtual method is overridden in the derived class, the override may execute before the derived constructor completes, leading to null references or unexpected state.

public class Base
{
    public Base()
    {
        Initialize(); // virtual call
    }

    protected virtual void Initialize() { }
}

public class Derived : Base
{
    private string data;

    protected override void Initialize()
    {
        data = "initialized";
    }
}

In this example, Derived.Initialize runs before Derived's constructor body, so data is still null when the method executes. This can cause subtle bugs. The general rule is to avoid virtual calls in constructors.

Another concern is that runtime polymorphism makes the flow of control less explicit. When reading a call site, you cannot always know which implementation will run without tracing the runtime type. This complexity can increase maintenance burden, especially in large codebases. Clear naming, good documentation, and leveraging design patterns that make the dispatch explicit can mitigate this.

When to Avoid Runtime Polymorphism

Runtime polymorphism is not always the right tool. If the set of possible types is small and known at compile time, a switch expression or a pattern match can be more readable and faster.

public double Area(Shape shape)
{
    return shape switch
    {
        Circle c => Math.PI * c.Radius * c.Radius,
        Rectangle r => r.Width * r.Height,
        _ => throw new ArgumentException("Unknown shape")
    };
}

This approach avoids vtable lookup and makes all cases explicit. It is a form of compile-time polymorphism, but it sacrifices the extensibility of runtime polymorphism: adding a new shape requires modifying this method. If you expect the type set to grow frequently, runtime polymorphism may be more maintainable.

Testing runtime polymorphism also requires attention. Mocking frameworks rely on interface or virtual method dispatch to create test doubles. If you use a concrete class with non-virtual methods, you cannot easily substitute a fake. Designing for testability often means making methods virtual or extracting interfaces, which is a deliberate tradeoff between encapsulation and flexibility.