C# Polymorphism for Beginners: virtual and override

Polymorphism lets you treat objects of different types through a common interface — the foundation of flexible, extensible code.

Imagine you have a drawing application. You want to calculate the area of any shape — circles, rectangles, triangles. You could write a method for each shape, but then every time you add a new shape, you'd have to update the area‑calculation code. That's messy and error‑prone. Instead, you define a common Shape base with an Area() method. Each shape provides its own implementation. Then you can write a single method that takes a Shape and calls Area() — and it works for any shape, past, present, or future. That's polymorphism: the ability to treat objects of different types uniformly, while their specific behavior is determined at runtime.

In this lesson, you'll learn what polymorphism is, how it works in C#, the difference between compile‑time and runtime polymorphism, and how to use it to build flexible, maintainable systems.

What Is It?

The Simple Explanation

Polymorphism (Greek for "many forms") means that a single operation can behave differently on different types of objects. In C#, this usually means you can call a method on a base class (or interface) reference, and the actual implementation is chosen at runtime based on the object's real type.

The Technical Definition

Polymorphism in C# comes in two flavors:

• Compile‑time (static) polymorphism — achieved via method overloading and operator overloading. The method to call is determined at compile time based on the number and types of arguments.
• Runtime (dynamic) polymorphism — achieved via virtual/override members and interface implementations. The method to call is determined at runtime based on the actual type of the object.

Runtime polymorphism is the more powerful and commonly referenced form. It relies on the inheritance hierarchy and the virtual method table (vtable) to dispatch calls.

Why Does It Exist?

The Problem

Without polymorphism, you'd be forced to write separate logic for every type you handle. Adding a new type requires modifying existing code (violating the Open/Closed Principle). Code becomes rigid, repetitive, and difficult to extend. You also cannot store different types in a single collection or pass them to a common method that works with all of them.

The Solution

Polymorphism solves this by:

• Unifying interfaces — you write code against a base type (or interface), and the runtime dispatches to the correct implementation.
• Extensibility — you can add new types without changing existing code (as long as they adhere to the contract).
• Code reuse — you write generic algorithms that work on any subtype.
• Maintainability — changes to one class don't affect others as long as the contract is respected.

Big Picture

Polymorphism is at the heart of object‑oriented programming. Here's how it fits into a typical application:

How It Works

Step 1 — Define a base with virtual members

public class Animal
{
    public virtual void Speak() => Console.WriteLine("Animal sound");
}

Step 2 — Override in derived classes

public class Dog : Animal
{
    public override void Speak() => Console.WriteLine("Woof!");
}
public class Cat : Animal
{
    public override void Speak() => Console.WriteLine("Meow!");
}

Step 3 — Use polymorphism

Animal myAnimal = new Dog();
myAnimal.Speak(); // Output: "Woof!"

// In a list
List animals = new() { new Dog(), new Cat(), new Dog() };
foreach (var a in animals) a.Speak();
// Output: Woof! Meow! Woof!

Step 4 — Interface polymorphism

interface IDrawable { void Draw(); }
class Circle : IDrawable { public void Draw() => Console.WriteLine("Drawing Circle"); }
class Square : IDrawable { public void Draw() => Console.WriteLine("Drawing Square"); }

List drawables = new() { new Circle(), new Square() };
foreach (var d in drawables) d.Draw();

Interfaces provide polymorphism without inheritance, allowing unrelated classes to be treated uniformly.

Simple Example

public abstract class Shape
{
    public abstract double Area();
}

public class Circle : Shape
{
    public double Radius { get; set; }
    public override double Area() => Math.PI * Radius * Radius;
}

public class Rectangle : Shape
{
    public double Width { get; set; }
    public double Height { get; set; }
    public override double Area() => Width * Height;
}

// Polymorphic usage
var shapes = new List
{
    new Circle { Radius = 5 },
    new Rectangle { Width = 4, Height = 6 }
};

double total = 0;
foreach (var shape in shapes)
    total += shape.Area(); // Each shape computes its own area

Console.WriteLine($"Total area: {total:F2}"); // Total area: 102.54

Code → Meaning → Result

• Shape is abstract — it defines a contract.
• Circle and Rectangle provide their own Area().
• The loop works with any Shape; no if statements needed.

Real-World Example

Consider a payment processing system that supports multiple payment providers (e.g., Credit Card, PayPal, Crypto). Each provider has its own implementation details, but they all conform to a common interface.

public interface IPaymentProcessor
{
    bool ProcessPayment(decimal amount);
    string GetProviderName();
}

public class CreditCardProcessor : IPaymentProcessor
{
    public bool ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing ${amount} via Credit Card");
        return true; // pretend success
    }
    public string GetProviderName() => "Credit Card";
}

public class PayPalProcessor : IPaymentProcessor
{
    public bool ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing ${amount} via PayPal");
        return true;
    }
    public string GetProviderName() => "PayPal";
}

public class CryptoProcessor : IPaymentProcessor
{
    public bool ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing ${amount} via Crypto");
        return true;
    }
    public string GetProviderName() => "Crypto";
}

// Payment service that uses polymorphism
public class PaymentService
{
    private readonly List<IPaymentProcessor> _processors;

    public PaymentService(IEnumerable<IPaymentProcessor> processors)
        => _processors = processors.ToList();

    public void ProcessAll(decimal amount)
    {
        foreach (var processor in _processors)
        {
            bool success = processor.ProcessPayment(amount);
            Console.WriteLine($"{processor.GetProviderName()}: {(success ? "Success" : "Failed")}");
        }
    }
}

// Usage
var processors = new IPaymentProcessor[]
{
    new CreditCardProcessor(),
    new PayPalProcessor(),
    new CryptoProcessor()
};

var service = new PaymentService(processors);
service.ProcessAll(99.99m);
// Output:
// Processing $99.99 via Credit Card
// Credit Card: Success
// Processing $99.99 via PayPal
// PayPal: Success
// Processing $99.99 via Crypto
// Crypto: Success

Why this is realistic:

• The PaymentService doesn't care about the concrete processor type — it works with any IPaymentProcessor.
• Adding a new processor (e.g., BankTransferProcessor) doesn't require changing the PaymentService — it just needs to implement the interface.
• This is a classic example of the Strategy pattern, enabled by polymorphism.

Analogy

Under the Hood

How does the runtime know which method to call? It uses a virtual method table (vtable).

Animal vtable: Speak → Animal.Speak()
Dog vtable:    Speak → Dog.Speak()   (overridden)

Common Confusion

1. Overloading vs Overriding

• Overloading — same method name, different parameters. Resolved at compile time (static polymorphism).
• Overriding — redefining a virtual/abstract method in a derived class. Resolved at runtime (dynamic polymorphism).

2. Virtual vs Abstract vs Interface

• virtual — provides a default implementation that can be overridden.
• abstract — no implementation; must be overridden in a derived class (only in abstract classes).
• interface — a contract with no implementation; classes must implement all members.

3. Polymorphism only works with virtual methods

Non‑virtual methods are resolved at compile time based on the reference type, not the object type. If you call a non‑virtual method on a base reference, the base implementation is used, even if the derived class defines a method with the same name (this is hiding, not overriding).

Common Mistakes

Mistake 1 — Forgetting override keyword

If you omit override, you're hiding the base method, not overriding it. This can lead to unexpected behavior when using polymorphism.

class Base { public virtual void M() => Console.WriteLine("Base"); }
class Derived : Base { public void M() => Console.WriteLine("Derived"); } //  hiding

Base obj = new Derived();
obj.M(); // Output: "Base" (not "Derived")

Correct: Use public override void M().

Mistake 2 — Not calling base when needed

In an overridden method, you may need to call the base implementation to preserve essential behavior (e.g., initialization, base logic). Forgetting this can break functionality.

public override void Save()
{
    // if base.Save() is essential (e.g., logging), call it
    base.Save();
    // additional logic
}

Mistake 3 — Using new to hide base members unintentionally

The new keyword is used to hide a base member intentionally. However, it's rarely needed and can confuse readers. If you're not sure, use override instead (if the base is virtual).

Mistake 4 — Overusing is and as to check types in polymorphic code

If you find yourself using is or as to branch on the concrete type, you're likely bypassing polymorphism. Instead, add a virtual method to the base class to handle the behavior.

When Should I Use It?

Use polymorphism when:

• You have a family of related types that should be handled uniformly.
• You want to write code that is extensible and adheres to the Open/Closed Principle (open for extension, closed for modification).
• You need to pass collections of objects and invoke behavior without knowing their concrete types.
• You are designing a framework or library where users can implement their own plugins.

Avoid polymorphism when:

• The types are not truly related; use composition or separate methods instead.
• You need high performance in the hottest paths and want to avoid virtual dispatch (though the impact is usually negligible).
• The behavior is fixed and won't change — simple non‑virtual code may be clearer.

Mental Model

Key Takeaway

Check Your Understanding

You've learned about polymorphism and how it enables flexible designs. Let's see if you can apply these concepts correctly.

class A { public virtual void M() => Console.Write("A"); }
class B : A { public override void M() => Console.Write("B"); }

A obj = new B();
obj.M();

You now have a deep understanding of polymorphism — from virtual dispatch to interface‑based design!