SOLID Principles in C#

SOLID is a refactoring guide, not a starting requirement. Write simply first. Extract abstractions when complexity demands it.

Core Principles

• S — Single Responsibility: A class should have one reason to change. One actor, one job.
• O — Open/Closed: Open for extension, closed for modification. Add behavior without editing existing code.
• L — Liskov Substitution: Subtypes must be substitutable for their base types without breaking correctness.
• I — Interface Segregation: Clients should not depend on methods they do not use. Keep interfaces focused.
• D — Dependency Inversion: Depend on abstractions, not concretions. High-level modules define the contract.

When to Use

Principle	Apply When
SRP	A class handles both business logic and infrastructure (e.g., validation + database calls)
OCP	You keep modifying the same switch/if-else chain to add new behavior
LSP	You have a class hierarchy and consumers use the base type polymorphically
ISP	Implementors are forced to throw NotImplementedException for methods they don't need
DIP	You need to test business logic without hitting databases, APIs, or file systems

When NOT to Use

• Startup or prototype phase — get it working first, then refactor toward SOLID when pain emerges
• Simple CRUD with no business logic — a single service class that maps DTOs to entities is fine
• Internal utilities — a helper class used in one place does not need an interface
• Fewer than 50 lines — if the entire class fits on one screen, splitting it adds noise
• One implementation forever — don't create IOrderService if OrderService is the only implementation and you have no testing seam requirement

Patterns

SRP — One MediatR Handler per Request

// GOOD: Each handler has exactly one responsibility
public sealed record CreateOrderCommand(
    string CustomerName,
    List<OrderItemDto> Items) : IRequest<Result<Guid>>;

public sealed class CreateOrderHandler(
    IOrderRepository repository,
    IUnitOfWork unitOfWork,
    TimeProvider timeProvider) : IRequestHandler<CreateOrderCommand, Result<Guid>>
{
    public async Task<Result<Guid>> Handle(
        CreateOrderCommand request,
        CancellationToken ct)
    {
        var order = Order.Create(
            request.CustomerName,
            request.Items,
            timeProvider.GetUtcNow());

        repository.Add(order);
        await unitOfWork.SaveChangesAsync(ct);

        return Result.Success(order.Id);
    }
}

// BAD: One service doing everything — creating, updating, deleting, emailing, reporting
public class OrderService
{
    public Task CreateAsync(...) { /* ... */ }
    public Task UpdateAsync(...) { /* ... */ }
    public Task DeleteAsync(...) { /* ... */ }
    public Task SendConfirmationEmailAsync(...) { /* ... */ }
    public Task GenerateReportAsync(...) { /* ... */ }
}

OCP — Strategy Pattern for Extension Without Modification

// Define the contract
public interface IDiscountStrategy
{
    decimal Calculate(Order order);
}

// Add new strategies without modifying existing ones
public sealed class LoyaltyDiscount : IDiscountStrategy
{
    public decimal Calculate(Order order) =>
        order.Customer.LoyaltyYears >= 3 ? order.Total * 0.10m : 0m;
}

public sealed class BulkDiscount : IDiscountStrategy
{
    public decimal Calculate(Order order) =>
        order.Items.Count >= 10 ? order.Total * 0.05m : 0m;
}

public sealed class SeasonalDiscount : IDiscountStrategy
{
    public decimal Calculate(Order order) =>
        order.CreatedAt.Month is 11 or 12 ? order.Total * 0.15m : 0m;
}

// Consumer is closed for modification — new discounts need zero changes here
public sealed class DiscountCalculator(IEnumerable<IDiscountStrategy> strategies)
{
    public decimal CalculateTotal(Order order) =>
        strategies.Sum(s => s.Calculate(order));
}

// Registration — add new strategies by registering, not by editing
services.AddSingleton<IDiscountStrategy, LoyaltyDiscount>();
services.AddSingleton<IDiscountStrategy, BulkDiscount>();
services.AddSingleton<IDiscountStrategy, SeasonalDiscount>();

LSP — Interface Contract Substitution

// Base contract
public interface INotificationSender
{
    Task SendAsync(Notification notification, CancellationToken ct);
}

// Both implementations are fully substitutable
public sealed class EmailNotificationSender(
    IEmailClient emailClient) : INotificationSender
{
    public async Task SendAsync(Notification notification, CancellationToken ct)
    {
        await emailClient.SendAsync(notification.Recipient, notification.Body, ct);
    }
}

public sealed class SmsNotificationSender(
    ISmsGateway gateway) : INotificationSender
{
    public async Task SendAsync(Notification notification, CancellationToken ct)
    {
        await gateway.SendTextAsync(notification.Recipient, notification.Body, ct);
    }
}

// BAD — violates LSP: subtype changes behavior the caller doesn't expect
public sealed class LogOnlyNotificationSender : INotificationSender
{
    public Task SendAsync(Notification notification, CancellationToken ct)
    {
        // Silently does nothing — caller expects delivery
        Console.WriteLine($"Would send: {notification.Body}");
        return Task.CompletedTask;
    }
}

ISP — Focused Interfaces

// GOOD: Segregated interfaces — clients depend only on what they use
public interface IOrderReader
{
    Task<Order?> GetByIdAsync(Guid id, CancellationToken ct);
    Task<IReadOnlyList<Order>> GetByCustomerAsync(Guid customerId, CancellationToken ct);
}

public interface IOrderWriter
{
    void Add(Order order);
    void Remove(Order order);
}

// Query handlers only need IOrderReader
public sealed class GetOrderHandler(
    IOrderReader reader) : IRequestHandler<GetOrderQuery, OrderDto?>
{
    public async Task<OrderDto?> Handle(GetOrderQuery query, CancellationToken ct)
    {
        var order = await reader.GetByIdAsync(query.Id, ct);
        return order?.ToDto();
    }
}

// Command handlers get IOrderWriter (and IOrderReader if needed)
public sealed class DeleteOrderHandler(
    IOrderReader reader,
    IOrderWriter writer,
    IUnitOfWork unitOfWork) : IRequestHandler<DeleteOrderCommand, Result>
{
    public async Task<Result> Handle(DeleteOrderCommand command, CancellationToken ct)
    {
        var order = await reader.GetByIdAsync(command.Id, ct);
        if (order is null) return Result.NotFound();
        writer.Remove(order);
        await unitOfWork.SaveChangesAsync(ct);
        return Result.Success();
    }
}

// BAD: One bloated interface forces implementors to support everything
public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(Guid id, CancellationToken ct);
    Task<IReadOnlyList<Order>> GetByCustomerAsync(Guid customerId, CancellationToken ct);
    Task<IReadOnlyList<Order>> GetPendingAsync(CancellationToken ct);
    Task<IReadOnlyList<Order>> SearchAsync(string query, CancellationToken ct);
    void Add(Order order);
    void Update(Order order);
    void Remove(Order order);
    Task BulkInsertAsync(IEnumerable<Order> orders, CancellationToken ct);
    Task ArchiveOlderThanAsync(DateTimeOffset cutoff, CancellationToken ct);
    Task<int> CountAsync(CancellationToken ct);
    // ... 10 more methods most consumers never call
}

DIP — Constructor Injection with Interface

// High-level module defines the contract
public interface IPaymentProcessor
{
    Task<PaymentResult> ChargeAsync(decimal amount, string currency, CancellationToken ct);
}

// Low-level module implements it
public sealed class StripePaymentProcessor(
    IOptions<StripeOptions> options,
    HttpClient httpClient) : IPaymentProcessor
{
    public async Task<PaymentResult> ChargeAsync(
        decimal amount, string currency, CancellationToken ct)
    {
        // Stripe-specific implementation
        var response = await httpClient.PostAsJsonAsync(
            "/v1/charges",
            new { amount, currency },
            ct);

        return response.IsSuccessStatusCode
            ? PaymentResult.Success()
            : PaymentResult.Failed("Charge declined");
    }
}

// Business logic depends on abstraction — testable, swappable
public sealed class CheckoutHandler(
    IPaymentProcessor paymentProcessor,
    IOrderWriter orderWriter,
    IUnitOfWork unitOfWork) : IRequestHandler<CheckoutCommand, Result>
{
    public async Task<Result> Handle(CheckoutCommand command, CancellationToken ct)
    {
        var payment = await paymentProcessor.ChargeAsync(
            command.Total, "usd", ct);

        if (!payment.Succeeded)
            return Result.Failure(payment.Error);

        orderWriter.Add(Order.CreatePaid(command));
        await unitOfWork.SaveChangesAsync(ct);
        return Result.Success();
    }
}

When Over-Applying Hurts

Interface Explosion

Don't create an interface for a class that will only ever have one implementation.

// BAD: Interface exists only because "SOLID says so"
public interface IOrderValidator { ... }
public sealed class OrderValidator : IOrderValidator { ... }
// No other implementation. No mock needed (FluentValidation is testable directly).

// GOOD: Just use the concrete class
services.AddScoped<OrderValidator>();

Class Proliferation

Too many tiny files for simple operations add navigation overhead without benefit.

// BAD: 6 files for one simple operation
// CreateOrderCommand.cs, CreateOrderCommandValidator.cs,
// CreateOrderCommandHandler.cs, CreateOrderCommandResponse.cs,
// ICreateOrderService.cs, CreateOrderService.cs

// GOOD: Co-locate command + handler in one file when the handler is short
// CreateOrder.cs — contains the record, validator, and handler

Premature Abstraction

Don't extract an interface before you have a genuine second use case or a testing seam that demands it.

// BAD: Abstracting on day one with one implementation
public interface IDateTimeProvider { DateTimeOffset UtcNow { get; } }
public sealed class DateTimeProvider : IDateTimeProvider { ... }
// .NET 8+ has TimeProvider built in — no custom abstraction needed

// GOOD: Use the built-in TimeProvider abstract class
services.AddSingleton(TimeProvider.System);

Decision Guide

Scenario	Principle	Apply?	Why
Service handles HTTP + business logic + DB	SRP	Yes	Split into handler + repository
Growing switch on OrderType for pricing	OCP	Yes	Strategy pattern eliminates the switch
Internal helper class, 30 lines	SRP	No	It already has one job
Repository used only by commands	ISP	Maybe	Split if query side exists separately
Class with one implementation, no tests	DIP	No	Add interface when you need a seam
Base class where subtypes skip methods	LSP	Yes	Subtypes must honor the full contract
3+ implementations of same behavior	OCP	Yes	Add via registration, not modification
Simple CRUD API, no domain logic	All	No	SOLID adds overhead with no payoff
Shared library consumed by many teams	ISP	Yes	Consumers should not depend on unused methods
Unit testing a class with external deps	DIP	Yes	Interface enables mocking

Anti-Patterns

Problem	Why It Hurts	Correct Approach
One interface per class, always	Doubles file count, adds indirection with no benefit	Create interfaces when you have 2+ implementations or need a test seam
God class with 500+ lines	Impossible to test, understand, or modify safely	Split by responsibility into focused classes
Deep inheritance hierarchies	Fragile base class problem, tight coupling	Prefer composition and interface implementation
Empty interface methods (NotImplementedException)	Violates LSP, callers cannot trust the contract	Segregate interfaces so each implementor uses all methods
Abstracting everything on day one	Premature abstraction slows development and obscures intent	Start concrete, extract when the second use case appears
Injecting 8+ dependencies in constructor	Signals SRP violation — class does too much	Split the class or introduce a facade/mediator
Creating IMapper, ILogger wrappers	Wrapping well-tested libraries adds no value	Use AutoMapper/Mapster and ILogger<T> directly
Refactoring stable, working code "for SOLID"	Risk of introducing bugs in code that works	Apply SOLID when you need to change the code, not before

Detect Existing Patterns

1. Search for large classes: files with 300+ lines may violate SRP
2. Search for switch or long if-else chains that grow with new types (OCP candidate)
3. Search for NotImplementedException — signals ISP or LSP violation
4. Search for classes with 5+ constructor parameters — possible SRP violation
5. Check if interfaces have exactly one implementation (possible interface explosion)

Adding to Existing Project

1. Audit pain points first — don't refactor what isn't causing problems
2. Start with DIP — add interfaces where you need testability
3. Apply SRP — split god classes when you need to modify them
4. Use OCP — extract strategies when you see a third case added to a switch
5. Apply ISP — split interfaces when implementors leave methods empty
6. Check LSP — verify subtypes when you see unexpected behavior in polymorphic code