Abstract Classes in C# Explained — When, Why and How to Use Them

using System;

// Abstract class — cannot be instantiated directly.
// Models the shared skeleton of every payment processor.
abstract class PaymentProcessor
{
    // Concrete field — shared state every processor needs.
    protected string processorName;

    // Constructor — abstract classes CAN have constructors.
    // Subclasses call this via : base(...) to initialise shared state.
    protected PaymentProcessor(string name)
    {
        processorName = name;
    }

    // ABSTRACT method — no body here. Every subclass MUST override this.
    // The compiler enforces it — you literally cannot ship without implementing it.
    public abstract void ProcessPayment(decimal amount);

    // CONCRETE method — shared logic every processor reuses as-is.
    // Subclasses inherit this for free without writing a single line.
    public void PrintReceipt(decimal amount)
    {
        Console.WriteLine($"[{processorName}] Receipt: ${amount:F2} processed successfully.");
    }
}

// Concrete class — must implement every abstract member or the build breaks.
class CreditCardProcessor : PaymentProcessor
{
    public CreditCardProcessor() : base("Credit Card") { }

    // Fulfilling the abstract contract with credit-card-specific logic.
    public override void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Charging ${amount:F2} to credit card via Stripe gateway...");
        PrintReceipt(amount); // Reusing the concrete method from the base class.
    }
}

class PayPalProcessor : PaymentProcessor
{
    public PayPalProcessor() : base("PayPal") { }

    public override void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Redirecting ${amount:F2} payment to PayPal checkout...");
        PrintReceipt(amount);
    }
}

class Program
{
    static void Main()
    {
        // PaymentProcessor processor = new PaymentProcessor(); // COMPILE ERROR — cannot instantiate abstract class.

        // Polymorphism in action — same variable type, different behaviour.
        PaymentProcessor[] processors = {
            new CreditCardProcessor(),
            new PayPalProcessor()
        };

        foreach (PaymentProcessor processor in processors)
        {
            processor.ProcessPayment(49.99m);
            Console.WriteLine();
        }
    }
}

using System;

// Abstract base — owns the ALGORITHM (the pipeline order).
// Subclasses own the STEPS (the individual implementations).
abstract class ReportGenerator
{
    // Abstract property — forces each subclass to declare its own report title.
    // No body here; the subclass decides how this value is produced.
    public abstract string ReportTitle { get; }

    // TEMPLATE METHOD — this is the algorithm skeleton.
    // It's non-virtual and non-abstract on purpose: the sequence must never change.
    public void GenerateReport()
    {
        Console.WriteLine($"=== Generating: {ReportTitle} ===");
        FetchData();      // Step 1 — subclass-specific
        FormatData();     // Step 2 — subclass-specific
        RenderOutput();   // Step 3 — subclass-specific
        Console.WriteLine($"=== {ReportTitle} Complete ===\n");
    }

    // Abstract steps — each subclass must provide its own version.
    protected abstract void FetchData();
    protected abstract void FormatData();
    protected abstract void RenderOutput();
}

class SalesReport : ReportGenerator
{
    // Computed property — no backing field needed, title is hardcoded for this type.
    public override string ReportTitle => "Monthly Sales Report";

    protected override void FetchData()
        => Console.WriteLine("  [Sales] Querying orders table from SQL Server...");

    protected override void FormatData()
        => Console.WriteLine("  [Sales] Aggregating totals by region and product...");

    protected override void RenderOutput()
        => Console.WriteLine("  [Sales] Exporting formatted data to Excel spreadsheet.");
}

class AuditReport : ReportGenerator
{
    public override string ReportTitle => "Security Audit Log";

    protected override void FetchData()
        => Console.WriteLine("  [Audit] Reading from distributed event log stream...");

    protected override void FormatData()
        => Console.WriteLine("  [Audit] Filtering by severity: WARN and ERROR only...");

    protected override void RenderOutput()
        => Console.WriteLine("  [Audit] Sending formatted report to compliance@company.com.");
}

class Program
{
    static void Main()
    {
        ReportGenerator[] scheduledReports = {
            new SalesReport(),
            new AuditReport()
        };

        // The same GenerateReport() call drives completely different behaviour.
        // The algorithm order (Fetch → Format → Render) never changes.
        foreach (ReportGenerator report in scheduledReports)
        {
            report.GenerateReport();
        }
    }
}

using System;

// INTERFACE — defines a capability. Any type can be 'taxable', regardless of family.
// No shared state, no shared implementation. Pure contract.
interface ITaxable
{
    decimal CalculateTax(decimal baseAmount);
}

// ABSTRACT CLASS — defines a family. All products share a name, price, and description.
// Shared concrete logic lives here. Unique logic is left abstract.
abstract class Product : ITaxable
{
    public string ProductName { get; }
    public decimal BasePrice { get; }

    protected Product(string name, decimal price)
    {
        ProductName = name;
        BasePrice = price;
    }

    // Abstract — every product type calculates its own category-specific discount.
    public abstract decimal GetDiscount();

    // Concrete — the final price formula is the same for every product.
    // We don't want subclasses changing this formula accidentally.
    public decimal GetFinalPrice()
    {
        decimal discountedPrice = BasePrice - GetDiscount();
        decimal tax = CalculateTax(discountedPrice);
        return discountedPrice + tax;
    }

    // Concrete implementation of the ITaxable interface — shared by all products.
    public decimal CalculateTax(decimal baseAmount) => baseAmount * 0.20m; // 20% VAT

    public override string ToString()
        => $"{ProductName}: Base ${BasePrice:F2} | Discount -${GetDiscount():F2} | Tax ${CalculateTax(BasePrice - GetDiscount()):F2} | Final ${GetFinalPrice():F2}";
}

class ElectronicProduct : Product
{
    public ElectronicProduct(string name, decimal price) : base(name, price) { }

    // Electronics get a flat 10% loyalty discount.
    public override decimal GetDiscount() => BasePrice * 0.10m;
}

class GroceryProduct : Product
{
    public GroceryProduct(string name, decimal price) : base(name, price) { }

    // Groceries get a fixed $2 off — a simple promotional discount.
    public override decimal GetDiscount() => 2.00m;
}

class Program
{
    static void Main()
    {
        Product[] inventory = {
            new ElectronicProduct("Wireless Headphones", 120.00m),
            new GroceryProduct("Organic Coffee Beans", 18.50m)
        };

        Console.WriteLine("--- Product Pricing Summary ---");
        foreach (Product item in inventory)
        {
            Console.WriteLine(item);
        }

        // ITaxable reference still works — abstract class satisfies the interface.
        ITaxable taxableItem = new ElectronicProduct("Smart Watch", 250.00m);
        Console.WriteLine($"\nTax on Smart Watch base: ${taxableItem.CalculateTax(250.00m):F2}");
    }
}