Advanced OOP Concepts in C# with Code Examples

September 17, 2025

0

Advanced Concepts of OOP in C# with Coding Examples

Object-Oriented Programming (OOP) in C# goes far beyond basic classes and methods. Modern C# equips you with powerful features that help you build maintainable, testable, and scalable applications. In this long-form guide, we will explore advanced OOP concepts in C# such as deep encapsulation, abstraction via interfaces and abstract classes, composition over inheritance, generics and variance, delegates and events, SOLID principles, essential design patterns, dependency injection, immutability with records, reflection and attributes, and pattern matching. Each section includes practical C# code examples to ground the theory in real-world scenarios.

Revisiting the OOP Pillars at an Advanced Level

Before diving into advanced features, let’s revisit the OOP pillars with a nuanced lens. C# supports sophisticated idioms that help you implement the pillars without falling into common traps such as deep inheritance hierarchies or brittle coupling.

Encapsulation and Access Control

Encapsulation is about controlling visibility and safeguarding invariants. In C#, prefer private fields with public or internal read-only properties, leverage init-only setters for immutability, and use readonly where possible to prevent accidental mutation.

public class BankAccount
{
    private decimal _balance;

public string AccountNumber { get; } public decimal Balance => _balance;

public BankAccount(string accountNumber, decimal initialBalance) { AccountNumber = accountNumber; Deposit(initialBalance); }

public void Deposit(decimal amount) { if (amount <= 0) throw new ArgumentOutOfRangeException(nameof(amount)); _balance += amount; }

public bool TryWithdraw(decimal amount) { if (amount <= 0 || amount > _balance) return false; _balance -= amount; return true; } }

This class exposes a stable surface area and defends its invariant: you can’t set arbitrary balances from the outside. Such encapsulation improves correctness and maintainability.

Inheritance and Polymorphism, Used Carefully

Inheritance enables code reuse but can couple types tightly. Use it judiciously, favoring virtual and override for extensibility, and sealed to lock down classes and overrides when necessary.

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

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

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

public class ColoredRectangle : Rectangle { public string Color { get; } public ColoredRectangle(double w, double h, string color) : base(w, h) => Color = color; public sealed override double Area() => base.Area(); // sealed to prevent further override surprises }

Prefer sealing overrides in leaf types. Also avoid method hiding with new unless absolutely necessary; it can confuse consumers at call sites.

Abstract Classes vs. Interfaces

Both abstract classes and interfaces model abstraction, but they serve different purposes:

• Abstract classes can hold state, constructors, and protected helpers. Use them when you need a shared implementation baseline.
• Interfaces describe capabilities. A class can implement multiple interfaces to combine behaviors without deep inheritance.

Default Interface Methods (C# 8+)

Interfaces can include default method implementations, which is useful for adding functionality without breaking implementers. Use carefully to avoid surprising implementations.

public interface ILoggable
{
    void Log(string message);

// Default method (C# 8+) void LogInfo(string message) => Log($"INFO: {message}"); }

public class ConsoleLogger : ILoggable { public void Log(string message) => Console.WriteLine(message); }

public class FileLogger : ILoggable { private readonly string _path; public FileLogger(string path) => _path = path; public void Log(string message) => File.AppendAllText(_path, message + Environment.NewLine); }

With default methods, both loggers automatically gain LogInfo, preserving compatibility while enabling evolution.

Composition Over Inheritance

Composition reduces coupling and improves testability. Instead of inheriting behavior, compose it via interfaces or small objects that collaborate.

public interface IFlyBehavior { string Fly(); }
public interface IQuackBehavior { string Quack(); }

public class FlyWithWings : IFlyBehavior { public string Fly() => "Flapping wings"; } public class FlyNoWay : IFlyBehavior { public string Fly() => "Cannot fly"; } public class LoudQuack : IQuackBehavior { public string Quack() => "QUACK!"; } public class MuteQuack : IQuackBehavior { public string Quack() => "..."; }

public class Duck { private IFlyBehavior _fly; private IQuackBehavior _quack;

public Duck(IFlyBehavior fly, IQuackBehavior quack) { _fly = fly; _quack = quack; }

public string PerformFly() => _fly.Fly(); public string PerformQuack() => _quack.Quack();

public void SetFlyBehavior(IFlyBehavior fly) => _fly = fly; public void SetQuackBehavior(IQuackBehavior quack) => _quack = quack; }

Here, behavior is easily swapped at runtime without subclassing. This pattern backs the Strategy design pattern and maximizes flexibility.

Generics Deep Dive: Constraints and Variance

Generics let you define type-safe abstractions without sacrificing performance. Advanced usage includes constraints and variance.

Constraints

Constraints govern the types that can be used as generic arguments. Common constraints include class, struct, new(), and interface or base class constraints.

public interface IEntity { Guid Id { get; } }

public interface IRepository<T> where T : class, IEntity, new() { T GetById(Guid id); void Add(T entity); }

public class InMemoryRepository<T> : IRepository<T> where T : class, IEntity, new() { private readonly Dictionary<Guid, T> _store = new();

public T GetById(Guid id) => _store.TryGetValue(id, out var e) ? e : new T(); public void Add(T entity) => _store[entity.Id] = entity; }

Constraints help the compiler verify usage and allow constructors or interface methods to be invoked safely.

Variance (in/out)

Variance affects how generic interfaces and delegates relate across inheritance hierarchies:

• Covariance (out): enables using a more derived type than originally specified (e.g., IEnumerable<Animal> can refer to IEnumerable<Dog>).
• Contravariance (in): enables using a more base type than originally specified (e.g., IComparer<Dog> can be an IComparer<Animal>).

public interface IProducer<out T> { T Produce(); }
public interface IConsumer<in T> { void Consume(T item); }

public class Dog { public string Name { get; init; } = "Doggo"; } public class Animal { public string Species { get; init; } = "Animal"; }

public class DogProducer : IProducer<Dog> { public Dog Produce() => new Dog { Name = "Rex" }; }

public class AnimalConsumer : IConsumer<Animal> { public void Consume(Animal a) => Console.WriteLine($"Consuming {a.Species}"); }

void VarianceDemo() { IProducer<Dog> dogProducer = new DogProducer(); IProducer<Animal> animalProducer = dogProducer; // Covariance

IConsumer<Animal> animalConsumer = new AnimalConsumer(); IConsumer<Dog> dogConsumer = animalConsumer; // Contravariance

var dog = animalProducer.Produce(); dogConsumer.Consume(dog); }

Declare out for return-only type parameters and in for input-only parameters to safely enable variance.

Delegates, Events, and the Observer Pattern

Delegates represent method references, and events provide a safe pub-sub mechanism. Together they implement the Observer pattern idiomatically in C#.

public class TemperatureChangedEventArgs : EventArgs
{
    public double Celsius { get; }
    public TemperatureChangedEventArgs(double celsius) => Celsius = celsius;
}

public class TemperatureSensor { private double _celsius; public event EventHandler<TemperatureChangedEventArgs>? TemperatureChanged;

public double Celsius { get => _celsius; set { if (Math.Abs(_celsius - value) >= 0.001) { _celsius = value; TemperatureChanged?.Invoke(this, new TemperatureChangedEventArgs(_celsius)); } } } }

public class Display { public void OnTemperatureChanged(object? sender, TemperatureChangedEventArgs e) => Console.WriteLine($"Temp: {e.Celsius:F1}°C"); }

void WireUp() { var sensor = new TemperatureSensor(); var display = new Display(); sensor.TemperatureChanged += display.OnTemperatureChanged; sensor.Celsius = 21.5; }

Events provide encapsulation: only the publisher can raise the event, while subscribers can safely add or remove handlers.

SOLID Principles in Practice

SOLID embodies time-tested guidelines. Here’s how each maps to practical C# OOP.

Single Responsibility Principle (SRP)

Each class should have one reason to change. Split responsibilities into cohesive units.

public interface IOrderValidator { bool Validate(Order order); }
public interface IPricingService { decimal CalculateTotal(Order order); }
public interface IOrderRepository { void Save(Order order); }

public class OrderProcessor { private readonly IOrderValidator _validator; private readonly IPricingService _pricing; private readonly IOrderRepository _repo;

public OrderProcessor(IOrderValidator validator, IPricingService pricing, IOrderRepository repo) => (_validator, _pricing, _repo) = (validator, pricing, repo);

public void Process(Order order) { if (!_validator.Validate(order)) throw new InvalidOperationException("Invalid order"); var total = _pricing.CalculateTotal(order); order.Total = total; _repo.Save(order); } }

Open/Closed Principle (OCP)

Extend behavior without modifying existing code. Strategy and composition help.

public interface ITaxStrategy { decimal ApplyTax(decimal amount); }
public class UsTax : ITaxStrategy { public decimal ApplyTax(decimal amount) => amount * 1.07m; }
public class EuTax : ITaxStrategy { public decimal ApplyTax(decimal amount) => amount * 1.20m; }

public class Checkout { private readonly ITaxStrategy _tax; public Checkout(ITaxStrategy tax) => _tax = tax; public decimal TotalWithTax(decimal subtotal) => _tax.ApplyTax(subtotal); }

Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types without altering desirable properties. Avoid "surprising" overrides that break expectations.

public interface IReadOnlyRectangle
{
    double Width { get; }
    double Height { get; }
}

public class Rect : IReadOnlyRectangle { public double Width { get; } public double Height { get; } public Rect(double w, double h) => (Width, Height) = (w, h); }

// Avoid making Square inherit from Rectangle if it must keep sides equal. public class Square : IReadOnlyRectangle { public double Side { get; } public double Width => Side; public double Height => Side; public Square(double side) => Side = side; }

By modeling shared capabilities via interfaces rather than forcing inheritance, we preserve substitutability.

Interface Segregation Principle (ISP)

Prefer small, focused interfaces over "fat" ones.

public interface IReadable { string Read(); }
public interface IWritable { void Write(string data); }

public class LogFile : IReadable, IWritable { public string Read() => File.ReadAllText("log.txt"); public void Write(string data) => File.AppendAllText("log.txt", data); }

Dependency Inversion Principle (DIP)

Depend on abstractions, not concretions. Inject dependencies via constructors.

public interface IEmailSender { Task SendAsync(string to, string subject, string body); }
public class SmtpEmailSender : IEmailSender
{
    public Task SendAsync(string to, string subject, string body)
    {
        // Simulated SMTP call
        Console.WriteLine($"Email to {to}: {subject}");
        return Task.CompletedTask;
    }
}

public class NotificationService { private readonly IEmailSender _email; public NotificationService(IEmailSender email) => _email = email; public Task NotifyAsync(string to, string msg) => _email.SendAsync(to, "Notification", msg); }

Design Patterns with C# OOP

Strategy Pattern

We decoupled behavior earlier with Duck. Here’s a different example for discounts:

public interface IDiscountStrategy { decimal Apply(decimal subtotal); }
public class NoDiscount : IDiscountStrategy { public decimal Apply(decimal s) => s; }
public class PercentageDiscount : IDiscountStrategy
{
    private readonly decimal _percent;
    public PercentageDiscount(decimal percent) => _percent = percent;
    public decimal Apply(decimal s) => s * (1 - _percent);
}

public class Cart { private IDiscountStrategy _strategy; public Cart(IDiscountStrategy strategy) => _strategy = strategy; public void SetStrategy(IDiscountStrategy s) => _strategy = s; public decimal Total(decimal subtotal) => _strategy.Apply(subtotal); }

Factory Method / Abstract Factory

Factories centralize object creation, removing knowledge of concrete types from consumers.

public abstract class Dialog
{
    public void Render()
    {
        var button = CreateButton();
        button.OnClick(() => Console.WriteLine("Dialog closed"));
        button.Render();
    }
    protected abstract IButton CreateButton();
}

public interface IButton { void Render(); void OnClick(Action handler); }

public class WindowsButton : IButton { private Action? _handler; public void Render() => Console.WriteLine("Render Windows Button"); public void OnClick(Action handler) => _handler = handler; }

public class WebButton : IButton { private Action? _handler; public void Render() => Console.WriteLine("<button>Click</button>"); public void OnClick(Action handler) => _handler = handler; }

public class WindowsDialog : Dialog { protected override IButton CreateButton() => new WindowsButton(); }

public class WebDialog : Dialog { protected override IButton CreateButton() => new WebButton(); }

The client calls Render() without caring whether it’s a web or Windows dialog.

Decorator Pattern

Decorator adds behavior without modifying the original type.

public interface ICoffee { decimal Cost(); string Description(); }

public class Espresso : ICoffee { public decimal Cost() => 2.00m; public string Description() => "Espresso"; }

public abstract class CoffeeDecorator : ICoffee { protected readonly ICoffee Inner; protected CoffeeDecorator(ICoffee inner) => Inner = inner; public virtual decimal Cost() => Inner.Cost(); public virtual string Description() => Inner.Description(); }

public class Milk : CoffeeDecorator { public Milk(ICoffee inner) : base(inner) {} public override decimal Cost() => base.Cost() + 0.50m; public override string Description() => base.Description() + " + Milk"; }

public class Mocha : CoffeeDecorator { public Mocha(ICoffee inner) : base(inner) {} public override decimal Cost() => base.Cost() + 0.70m; public override string Description() => base.Description() + " + Mocha"; }

void CoffeeDemo() { ICoffee order = new Mocha(new Milk(new Espresso())); Console.WriteLine(order.Description()); Console.WriteLine(order.Cost()); }

Decorators compose to add features dynamically at runtime while preserving the original interface.

Dependency Injection and IoC Containers

Dependency Injection (DI) in C# is commonly implemented with Microsoft.Extensions.DependencyInjection. The container manages lifetimes and wiring.

using Microsoft.Extensions.DependencyInjection;

public interface IPaymentGateway { Task ChargeAsync(decimal amount); } public class StripeGateway : IPaymentGateway { public Task ChargeAsync(decimal amount) { Console.WriteLine($"Charging ${amount:F2} via Stripe"); return Task.CompletedTask; } }

public class BillingService { private readonly IPaymentGateway _gateway; public BillingService(IPaymentGateway gateway) => _gateway = gateway; public Task BillAsync(decimal amount) => _gateway.ChargeAsync(amount); }

void ConfigureAndRun() { var services = new ServiceCollection() .AddSingleton<IPaymentGateway, StripeGateway>() .AddTransient<BillingService>() .BuildServiceProvider();

var billing = services.GetRequiredService<BillingService>(); billing.BillAsync(49.99m).Wait(); }

Constructor injection maintains clarity and testability. For tests, you substitute IPaymentGateway with a fake or mock.

Immutability and Records

Immutability reduces side effects. C# records (C# 9+) offer concise, value-based types ideal for domain models that don’t require mutation.

public record Customer(string Id, string Name, string Email);

var alice = new Customer("C-1", "Alice", "alice@example.com"); var updated = alice with { Email = "alice@newmail.com" };

Console.WriteLine(alice == updated); // False, value-based equality Console.WriteLine(alice.Email); // original preserved

Records support value equality, non-destructive mutation via with, and can be declared as positional or nominative records. You can also define record class or record struct depending on semantics.

Inheritance with Records

public abstract record Payment(string Id, decimal Amount);
public record CardPayment(string Id, decimal Amount, string Last4) : Payment(Id, Amount);
public record CashPayment(string Id, decimal Amount) : Payment(Id, Amount);

Payment p = new CardPayment("P-1", 100m, "4242"); Console.WriteLine(p is Payment); // True

Records can participate in polymorphism while retaining value semantics, making them ideal for modeling immutable hierarchies such as events or commands.

Reflection and Attributes

Reflection lets you inspect types and members at runtime. Attributes annotate code with metadata. Together, they enable cross-cutting features such as validation, mapping, or instrumentation. Use sparingly due to performance costs and complexity.

[AttributeUsage(AttributeTargets.Method)]
public sealed class AuditAttribute : Attribute
{
    public string Action { get; }
    public AuditAttribute(string action) => Action = action;
}

public class PaymentService { [Audit("Charge")] public void Charge(string id, decimal amount) { Console.WriteLine($"Charging {id} for {amount}"); } }

public static class Auditor { public static void InvokeWithAudit(object target, string methodName, params object[] args) { var method = target.GetType().GetMethod(methodName); if (method == null) throw new MissingMethodException(methodName);

var audit = method.GetCustomAttributes(typeof(AuditAttribute), inherit: true) .Cast<AuditAttribute>() .FirstOrDefault(); if (audit != null) { Console.WriteLine($"AUDIT: {audit.Action} called at {DateTime.UtcNow:o}"); } method.Invoke(target, args); } }

void ReflectionDemo() { var svc = new PaymentService(); Auditor.InvokeWithAudit(svc, "Charge", "P-123", 29.99m); }

Favor compile-time approaches where possible; use reflection when you need dynamic behaviors such as discovery of plugins or attribute-driven mapping.

Pattern Matching to Complement Polymorphism

Modern C# pattern matching enables expressive, safe handling of variants without deep hierarchies. It works well with records and discriminated unions-like designs.

public abstract record Shape2D;
public record Circle2D(double Radius) : Shape2D;
public record Rectangle2D(double Width, double Height) : Shape2D;
public record Triangle2D(double A, double B, double C) : Shape2D;

public static double Perimeter(Shape2D shape) => shape switch { Circle2D c => 2 * Math.PI * c.Radius, Rectangle2D r => 2 * (r.Width + r.Height), Triangle2D t => t.A + t.B + t.C, _ => throw new NotSupportedException() };

public static string DescribeShape(Shape2D s) => s switch { Circle2D { Radius: <= 1 } => "Small circle", Circle2D { Radius: > 1 and <= 10 } => "Medium circle", Circle2D => "Large circle", Rectangle2D { Width: var w, Height: var h } when w == h => "Square", Rectangle2D => "Rectangle", _ => "Unknown" };

Pattern matching keeps logic local and readable. It’s a powerful complement to traditional virtual dispatch, especially when modeling data-centric variants.

Best Practices for Advanced OOP in C#

• Favor composition over inheritance; keep inheritance shallow and purposeful.
• Seal classes by default; unseal only when you explicitly support subclassing.
• Keep interfaces small and focused; use multiple interfaces to compose capabilities.
• Prefer immutable types for domain data; use records and init setters.
• Use generics with constraints for type safety; declare variance (in/out) thoughtfully.
• Publish events using EventHandler<T> and follow .NET naming conventions.
• Inject dependencies; avoid service locators inside domain classes.
• Write unit tests against interfaces and abstract contracts; mock external concerns.
• Document invariants and behaviors; enforce them via encapsulation.
• Avoid premature optimization; measure before introducing complexity.

Common Pitfalls and How to Avoid Them

• Leaky abstractions: If consumers need to know implementation details, refactor to tighten encapsulation.
• Deep inheritance trees: Replace with composition or patterns like Strategy and Decorator.
• Overusing reflection: It can hurt performance and safety. Prefer generics and compile-time techniques.
• Fat interfaces: Split into smaller interfaces to adhere to ISP and ease mocking.
• Hidden side effects: Favor pure functions and immutable data for predictability.
• Event memory leaks: Unsubscribe from events or use weak events when subscribers have shorter lifetimes.
• Violation of LSP: Don’t inherit just to reuse code; ensure behavioral compatibility.
• Global singletons: Prefer DI-managed lifetimes and clear ownership.

Performance Considerations in OOP Designs

Advanced OOP should balance readability with performance. Consider:

• Virtual call overhead: Minor but measurable. Seal classes/methods when polymorphism is not needed.
• Allocation costs: Reduce transient allocations in hot paths; consider structs for tiny, immutable value types.
• Boxing: Avoid boxing by using generics and avoiding object-based collections.
• Reflection: Cache results (e.g., MethodInfo) if you must use reflection in hot paths.
• Asynchronous boundaries: Use async/await properly; avoid synchronous blocking on async calls.

Bringing It Together: A Mini Case Study

Imagine a simplified e-commerce checkout flow using the concepts above. We’ll define abstractions, compose behaviors, and wire up with DI.

// Domain
public interface IPricer { decimal Price(IEnumerable<OrderLine> lines); }
public interface IDiscountPolicy { decimal Apply(decimal subtotal); }
public interface ITaxPolicy { decimal Apply(decimal amount); }

public record OrderLine(string Sku, int Qty, decimal UnitPrice);

public class BasicPricer : IPricer { public decimal Price(IEnumerable<OrderLine> lines) => lines.Sum(l => l.Qty * l.UnitPrice); }

public class SeasonalDiscount : IDiscountPolicy { private readonly decimal _percent; public SeasonalDiscount(decimal percent) => _percent = percent; public decimal Apply(decimal subtotal) => subtotal * (1 - _percent); }

public class RegionTax : ITaxPolicy { private readonly decimal _rate; public RegionTax(decimal rate) => _rate = rate; public decimal Apply(decimal amount) => amount * (1 + _rate); }

public interface IPaymentService { Task PayAsync(decimal amount); } public class NullPayment : IPaymentService { public Task PayAsync(decimal a) => Task.CompletedTask; }

public class CheckoutService { private readonly IPricer _pricer; private readonly IDiscountPolicy _discount; private readonly ITaxPolicy _tax; private readonly IPaymentService _payment;

public CheckoutService(IPricer pricer, IDiscountPolicy discount, ITaxPolicy tax, IPaymentService payment) => (_pricer, _discount, _tax, _payment) = (pricer, discount, tax, payment);

public async Task<decimal> CheckoutAsync(IEnumerable<OrderLine> lines) { var subtotal = _pricer.Price(lines); var discounted = _discount.Apply(subtotal); var total = _tax.Apply(discounted); await _payment.PayAsync(total); return total; } }

// Composition/DI using Microsoft.Extensions.DependencyInjection;

void RunCaseStudy() { var services = new ServiceCollection() .AddSingleton<IPricer, BasicPricer>() .AddSingleton<IDiscountPolicy>(new SeasonalDiscount(0.10m)) .AddSingleton<ITaxPolicy>(new RegionTax(0.07m)) .AddSingleton<IPaymentService, NullPayment>() .AddTransient<CheckoutService>() .BuildServiceProvider();

var checkout = services.GetRequiredService<CheckoutService>(); var lines = new[] { new OrderLine("ABC", 2, 10m), new OrderLine("XYZ", 1, 20m) }; var total = checkout.CheckoutAsync(lines).Result; Console.WriteLine($"Total: {total:F2}"); }

This small design demonstrates abstractions, composition, DI, and testability. You can swap the discount or tax policy without touching CheckoutService, adhering to OCP and DIP.

Conclusion

Advanced OOP in C# is about crafting robust abstractions, managing complexity, and enabling change. By favoring composition, leveraging interfaces and generics with the right constraints, embracing delegates and events for decoupled communication, applying SOLID principles, employing proven design patterns, adopting immutability with records, using reflection and attributes judiciously, and complementing polymorphism with pattern matching, you lay a foundation for code that scales with your product and team.

Start small: refactor a class to use an interface and inject it, replace inheritance with a strategy, or convert a mutable DTO to a record. Over time, these practices will compound into a clean, evolvable codebase that is easier to test, reason about, and extend.

Comments0

Please write your comment.

Please login to comment.