Open/Closed Principle

Robert C. Martin reinterpreted OCP in his 1996 article "The Open-Closed Principle" (published in The C++ ReportA technical magazine for C++ developers published from 1989 to 2002. Martin's column "Engineering Notebook" introduced many of the SOLID principles to a wider audience.). Martin shifted the focus from inheritance to abstraction and polymorphism: depend on interfaces, not concrete classes.

// Martin's OCP: extend via INTERFACES + POLYMORPHISM
public interface IShape
{
    double Area();
}

public class Circle(double radius) : IShape
{
    public double Area() => Math.PI * radius * radius;
}

public class Triangle(double @base, double height) : IShape
{
    public double Area() => 0.5 * @base * height;
}

// Consumer is CLOSED for modification
public class AreaCalculator(IEnumerable<IShape> shapes)
{
    public double TotalArea() => shapes.Sum(s => s.Area());
    // Adding Hexagon? Create new class, implements IShape.
    // AreaCalculator NEVER changes.
}

In Agile Software Development (2003) and Clean Architecture (2017), Martin formalized OCP as part of SOLID and connected it to the Dependency Inversion PrincipleHigh-level modules should not depend on low-level modules. Both should depend on abstractions. DIP is OCP's enforcement mechanism — by depending on interfaces, you can add new implementations without changing consumers.: "If component A should be protected from changes in component B, then component B should depend on component A."

// Clean Architecture: OCP at the ARCHITECTURAL level
// Domain layer (innermost) — CLOSED for modification
public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(int id);
    Task SaveAsync(Order order);
}

// Infrastructure layer (outermost) — OPEN for extension
public class SqlOrderRepository(AppDbContext db) : IOrderRepository { /* ... */ }
public class CosmosOrderRepository(CosmosClient client) : IOrderRepository { /* ... */ }
public class InMemoryOrderRepository : IOrderRepository { /* for tests */ }

// Swapping from SQL to Cosmos = change DI registration.
// Domain layer, application layer, controllers — ALL untouched.

ASP.NET Core's entire architecture is built on OCP. The middleware pipelineASP.NET Core processes HTTP requests through a chain of middleware components. Each middleware is independent — adding rate limiting doesn't affect authentication, adding CORS doesn't change compression. Pure OCP., DI containerASP.NET Core's built-in IoC container supports interface-based registration, making OCP the default. You register IFoo → Foo, and consumers get Foo without knowing its type. Swapping to FooV2 is a one-line DI change., MediatRA popular .NET library where each feature is a separate handler class. Adding a new feature = adding a new handler file. No existing handler is modified. The mediator routes by convention., and minimal APIsLightweight ASP.NET Core endpoints defined as lambdas or method groups. Each endpoint is independently defined — adding a new endpoint doesn't touch existing ones. all embody OCP. C# features like pattern matchingC# switch expressions with pattern matching (is, switch, when). While powerful, pattern matching on types can VIOLATE OCP if used as a dispatch mechanism — prefer polymorphism for extensible behavior. can help or hurt OCP depending on how they're used.

// Modern .NET: OCP everywhere

// 1. Middleware pipeline — add without modifying
app.UseAuthentication();   // Existing
app.UseRateLimiting();     // NEW — doesn't touch auth
app.UseResponseCaching();  // NEW — doesn't touch rate limiting

// 2. Endpoint routing — add without modifying
app.MapGet("/orders", GetOrders);       // Existing
app.MapGet("/invoices", GetInvoices);   // NEW — doesn't touch orders

// 3. DI multi-registration
builder.Services.AddScoped<IValidator<Order>, PriceValidator>();     // Existing
builder.Services.AddScoped<IValidator<Order>, StockValidator>();     // NEW — no edits

// 4. MediatR — new feature = new handler file
public record GetInvoiceQuery(int Id) : IRequest<Invoice>;  // NEW file
public class GetInvoiceHandler : IRequestHandler<GetInvoiceQuery, Invoice> { /* ... */ }
// Zero changes to any existing handler

ASP.NET Core's DI container supports multi-registrationRegistering multiple implementations of the same interface. When you inject IEnumerable<IFoo>, you get ALL registered IFoo implementations. This is the backbone of OCP in .NET — add implementations without touching consumers. — register multiple implementations of the same interface, then inject IEnumerable<T> to get all of them. This is OCP's killer feature in .NET.

// Register multiple validators for the same type
builder.Services.AddScoped<IValidator<Order>, PriceValidator>();
builder.Services.AddScoped<IValidator<Order>, StockValidator>();
builder.Services.AddScoped<IValidator<Order>, FraudValidator>();  // NEW — no edits above

// Consumer gets ALL validators automatically
public class OrderService(IEnumerable<IValidator<Order>> validators)
{
    public async Task<Result> PlaceOrderAsync(Order order)
    {
        // Runs every registered validator — doesn't know which or how many
        var errors = validators
            .SelectMany(v => v.Validate(order).Errors)
            .ToList();

        if (errors.Count > 0)
            return Result.Fail(errors);

        // ... process order ...
        return Result.Ok();
    }
}
// Adding WeightValidator: register in DI + create class. OrderService? Untouched.

FluentValidationA popular .NET library for building strongly-typed validation rules. Each validator class handles one DTO/model. New validators are discovered automatically via assembly scanning — pure OCP. follows OCP perfectly. Each model gets its own validator class. Adding validation for a new DTO = new file. The validation pipeline discovers validators by convention — zero modification needed.

// Each validator is a separate class — adding one doesn't touch others
public class CreateOrderValidator : AbstractValidator<CreateOrderDto>
{
    public CreateOrderValidator()
    {
        RuleFor(x => x.CustomerId).NotEmpty();
        RuleFor(x => x.Items).NotEmpty().WithMessage("Order must have items");
        RuleFor(x => x.Items).Must(items => items.All(i => i.Quantity > 0));
    }
}

// NEW: Adding validation for UpdateOrderDto = new file, zero changes above
public class UpdateOrderValidator : AbstractValidator<UpdateOrderDto>
{
    public UpdateOrderValidator()
    {
        RuleFor(x => x.OrderId).GreaterThan(0);
        RuleFor(x => x.Status).IsInEnum();
    }
}

// Auto-discovery: validators registered by assembly scanning
builder.Services.AddValidatorsFromAssemblyContaining<Program>();
// New validators are picked up automatically — zero DI registration needed

MediatRA mediator pattern library for .NET. Requests are dispatched to handlers by type matching. Pipeline behaviors intercept ALL requests (like middleware for business logic). Both handlers and behaviors are pure OCP — new ones don't affect existing ones.'s pipeline behaviors are OCP at the application logic level. Add cross-cutting concerns (validation, logging, caching) without modifying any handler.

// Validation behavior — wraps ALL commands without modifying them
public class ValidationBehavior<TReq, TRes>(IEnumerable<IValidator<TReq>> validators)
    : IPipelineBehavior<TReq, TRes>A MediatR interface that intercepts every command/query before it reaches its handler. Think of it as middleware for business logic. Register it once, and it applies to ALL requests — zero modification to individual handlers. where TReq : IRequest<TRes>
{
    public async Task<TRes> Handle(
        TReq request, RequestHandlerDelegate<TRes> next, CancellationToken ct)
    {
        var failures = validators
            .Select(v => v.Validate(request))
            .SelectMany(r => r.Errors)
            .Where(f => f is not null)
            .ToList();

        if (failures.Count > 0)
            throw new ValidationException(failures);

        return await next(); // Call next behavior or handler
    }
}

// NEW: Add caching behavior — no existing behavior or handler changes
public class CachingBehavior<TReq, TRes>(IMemoryCache cache)
    : IPipelineBehavior<TReq, TRes> where TReq : IRequest<TRes>, ICacheable
{
    public async Task<TRes> Handle(
        TReq request, RequestHandlerDelegate<TRes> next, CancellationToken ct)
    {
        var key = request.CacheKey;
        if (cache.TryGetValue(key, out TRes? cached)) return cached!;
        var result = await next();
        cache.Set(key, result, TimeSpan.FromMinutes(5));
        return result;
    }
}

// Registration — behaviors apply to ALL requests automatically
builder.Services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehavior<,>));
builder.Services.AddTransient(typeof(IPipelineBehavior<,>), typeof(CachingBehavior<,>));

ASP.NET Core's Options patternA pattern using IOptions<T>, IOptionsSnapshot<T>, and IOptionsMonitor<T> to bind configuration sections to strongly-typed classes. Adding a new configuration section doesn't affect existing option bindings. lets you add new configuration sections without modifying existing ones. Each options class is independent — adding CacheOptions doesn't touch SmtpOptions.

// Each options class is independent — adding new ones doesn't touch existing
builder.Services.Configure<SmtpOptions>(builder.Configuration.GetSection("Smtp"));
builder.Services.Configure<StripeOptions>(builder.Configuration.GetSection("Stripe"));

// NEW: add cache configuration — no existing code changes
builder.Services.Configure<CacheOptions>(builder.Configuration.GetSection("Cache"));

// Post-configure: modify options after binding, without touching the options class
builder.Services.PostConfigure<SmtpOptions>(opts =>
{
    if (string.IsNullOrEmpty(opts.FromAddress))
        opts.FromAddress = "noreply@company.com";
});

The Decorator patternWrap an object with another that adds behavior. In .NET DI, register a decorator that wraps the real implementation. The consumer only sees the interface — it doesn't know it's getting a decorated version. is OCP's best friend. Add caching, logging, or retry behavior to any service without modifying the original. The ScrutorA .NET library that adds assembly scanning and decoration support to Microsoft's DI container. Its .Decorate<TService, TDecorator>() method wraps existing registrations — perfect for OCP-compliant cross-cutting concerns. library makes this one line of code.

// Original service — NEVER modified
public class OrderRepository(AppDbContext db) : IOrderRepository
{
    public async Task<Order?> GetByIdAsync(int id) => await db.Orders.FindAsync(id);
    public async Task SaveAsync(Order order) { db.Orders.Update(order); await db.SaveChangesAsync(); }
}

// Decorator: adds caching WITHOUT modifying OrderRepository
public class CachedOrderRepository(IOrderRepository inner, IMemoryCache cache) : IOrderRepository
{
    public async Task<Order?> GetByIdAsync(int id) =>
        await cache.GetOrCreateAsync($"order:{id}", async entry =>
        {
            entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5);
            return await inner.GetByIdAsync(id);
        });
    public async Task SaveAsync(Order order) { cache.Remove($"order:{order.Id}"); await inner.SaveAsync(order); }
}

// DI: wrap the original with the decorator
builder.Services.AddScoped<OrderRepository>();
builder.Services.AddScoped<IOrderRepository>(sp =>
    new CachedOrderRepository(
        sp.GetRequiredService<OrderRepository>(),
        sp.GetRequiredService<IMemoryCache>()));

// With Scrutor (one line):
// builder.Services.Decorate<IOrderRepository, CachedOrderRepository>();

Picture a busy kitchen where every chef shares the same recipe book. Chef A is writing a new sushi recipe and accidentally smudges the pasta recipe on the page above. That's exactly what happened here -- one developer's new code accidentally changed someone else's working code, because everything lived in the same method.

The team had a single PaymentProcessor class with a switch statement that handled every payment method: Stripe, PayPal, and now crypto. When the developer added the crypto case, they copied the PayPal line as a starting point and changed "USD" to "BTC". But they forgot to undo the change on the PayPal line itself. The result? Every PayPal transaction now sent "BTC" as the currency code -- and PayPal's API immediately rejected it.

The scariest part: nobody noticed during code review. The PR had 40+ lines of changes across one big method, and the accidental edit was buried three lines above the intentional changes. Reviewers focused on the new crypto logic and glossed over the PayPal line, assuming it hadn't changed.

Customers started seeing "Payment Failed" errors on checkout. The support team assumed it was a PayPal outage. It took 4 hours before someone ran the old test suite against production and traced the failure to the wrong currency code.

Time to Diagnose

4 hours -- the test suiteA collection of automated tests that verify software behavior. When tests only cover individual components in isolation but miss integration scenarios (like shared method modifications), bugs slip through to production. only tested each payment method in isolation with mocked gateways that accepted any currency. The bug only manifested against the real PayPal API in production.

public class PaymentProcessor
{
    public async Task<PaymentResult> Process(Order order, string method)
    {
        return method switch
        {
            "stripe" => await ChargeStripe(order, "USD"),
            "paypal" => await ChargePayPal(order, "BTC"), // Was "USD" -- copy-paste error!
            "crypto" => await ChargeCrypto(order, "BTC"), // NEW -- dev copied from here
            _ => throw new NotSupportedException($"Unknown: {method}")
        };
    }
    // Each new payment method = edit this class = risk breaking others
    // The PayPal line was 3 lines away from the new code -- easy to mis-edit
}

public interface IPaymentHandler
{
    string Method { get; }
    Task<PaymentResult> ProcessAsync(Order order);
}

public class StripeHandler : IPaymentHandler { /* self-contained */ }
public class PayPalHandler : IPaymentHandler { /* self-contained */ }
public class CryptoHandler : IPaymentHandler { /* NEW -- no existing code touched */ }

public class PaymentProcessor(IEnumerable<IPaymentHandler> handlers)
{
    public async Task<PaymentResult> ProcessAsync(Order order, string method)
    {
        var handler = handlers.FirstOrDefault(h => h.Method == method)
            ?? throw new NotSupportedException($"No handler for: {method}");
        return await handler.ProcessAsync(order);
    }
    // PaymentProcessor is CLOSED -- adding crypto didn't touch this class
}

Think of a filing cabinet where every department's rules are stored in the same drawer. The marketing intern opens the drawer to add a new loyalty program flyer, and while shuffling papers around, accidentally bends the corner of the corporate pricing sheet, covering up the "or equal to" part of "$10,000 or more." Now corporate clients at exactly $10,000 don't qualify anymore -- and nobody notices because the intern was only supposed to be adding a new page, not changing existing ones.

That's what happened in code. The DiscountCalculator class had one massive method with if blocks for every discount type: student, corporate, employee, seasonal. When the developer scrolled through this 200-line method to add the loyalty tier logic at the bottom, their cursor accidentally landed on the corporate line and changed >= to >. It's the kind of typo that happens when you're navigating a long file -- one accidental keystroke while your cursor is on the wrong line.

The change was invisible in the PR diff. The reviewer saw 40+ changed lines and focused on the new loyalty logic at the bottom. The corporate line looked "normal" -- it still had an if check with 10_000. The difference between >= and > is a single character, and it was buried among lines the developer wasn't supposed to touch.

Enterprise clients who spent exactly $10,000 per year -- the boundary case -- suddenly lost their 15% discount. These were the platform's biggest accounts. The first angry call came within 2 hours. It took 6 more hours to trace the problem because everyone assumed "we only added a loyalty discount, we didn't change corporate pricing."

Time to Diagnose

6 hours -- because the change was buried in a 200-line method with 8 nested if blocks. The PR reviewerA team member who reviews pull requests before merging. When a PR modifies existing code (vs adding new code), reviewers must verify no existing behavior was broken -- a much harder task than reviewing pure additions. missed it because the diff showed 40+ changed lines for "just adding a loyalty discount."

public class DiscountCalculator
{
    public decimal Calculate(Order order, Customer customer)
    {
        decimal discount = 0;

        // Student discount
        if (customer.Type == "student" && order.Total > 50)
            discount = order.Total * 0.10m;

        // Corporate -- someone changed >= to > while adding loyalty tier
        if (customer.Type == "corporate" && customer.AnnualSpend > 10_000)
            discount = order.Total * 0.15m;

        // Employee discount
        if (customer.IsEmployee)
            discount = order.Total * 0.25m;

        // Seasonal
        if (DateTime.Now.Month == 12)
            discount += order.Total * 0.05m;

        // NEW: Loyalty tier -- this addition caused the bug above
        if (customer.LoyaltyYears >= 3)
            discount += order.Total * 0.03m;

        return discount;
    }
}

public interface IDiscountRule
{
    bool Applies(Order order, Customer customer);
    decimal Calculate(Order order, Customer customer);
}

public class CorporateDiscount : IDiscountRule
{
    public bool Applies(Order o, Customer c) =>
        c.Type == "corporate" && c.AnnualSpend >= 10_000; // Safe in its own file
    public decimal Calculate(Order o, Customer c) => o.Total * 0.15m;
}

// NEW: adding this class doesn't touch CorporateDiscount
public class LoyaltyDiscount : IDiscountRule
{
    public bool Applies(Order o, Customer c) => c.LoyaltyYears >= 3;
    public decimal Calculate(Order o, Customer c) => o.Total * 0.03m;
}

public class DiscountEngine(IEnumerable<IDiscountRule> rules)
{
    public decimal Calculate(Order order, Customer customer) =>
        rules.Where(r => r.Applies(order, customer))
             .Sum(r => r.Calculate(order, customer));
}

Imagine a security checkpoint at an airport. There's one guard who checks everyone. The guard has a checklist: "If the person looks like a tourist, check their passport. If they look like a business traveler, check their passport AND their business visa." The problem? Every business traveler also looks like a tourist -- so the guard matches them to "tourist" first and waves them through without checking the business visa. That's exactly what happened with this type-checking bug.

The RequestValidator class had a single method that used if/else if chains to check what type of request it was dealing with. The PaymentRequest check came first. Then TransferRequest -- but here's the problem: TransferRequest inherits from PaymentRequest. In C#, when you write if (request is PaymentRequest), it matches any object that IS a PaymentRequest or any of its children. Since TransferRequest is a child of PaymentRequest, every transfer got caught by the payment check first, and the transfer-specific validation (checking for a recipient) never ran.

The result was terrifying: money transfers were being approved without verifying who the money was going to. The recipient field was empty on some transfers, meaning the system processed payments to nowhere. The bug was "intermittent" from the team's perspective because transfers that happened to have a valid amount passed the parent's simple amount check -- they looked fine. But the crucial RecipientId check was silently skipped.

Unit tests didn't catch it because they tested each request type directly: new TransferRequest() passed through its own test validator. Nobody tested the scenario where a TransferRequest was passed to the shared Validate(object request) method, which is exactly how it worked in production.

Time to Diagnose

2 days -- the bug was intermittent because it only affected TransferRequest instances that happened to pass the parent PaymentRequest validation. Unit tests passed because they tested each type independently, not through the shared validator.

public class RequestValidator
{
    public ValidationResult Validate(object request)
    {
        // PaymentRequest check matches BEFORE TransferRequest
        if (request is PaymentRequest payment)
        {
            if (payment.Amount <= 0) return Fail("Invalid amount");
            return Success();
        }
        // TransferRequest inherits PaymentRequest -- this never executes!
        else if (request is TransferRequest transfer)
        {
            if (string.IsNullOrEmpty(transfer.RecipientId))
                return Fail("Recipient required"); // Never reached
            return Success();
        }
        // ... 10 more type checks
    }
}

// Each request type gets its OWN validator -- no type-check ordering issues
public class PaymentRequestValidator : AbstractValidator<PaymentRequest>
{
    public PaymentRequestValidator()
    {
        RuleFor(x => x.Amount).GreaterThan(0);
    }
}

public class TransferRequestValidator : AbstractValidator<TransferRequest>
{
    public TransferRequestValidator()
    {
        Include(new PaymentRequestValidator()); // Inherits parent rules
        RuleFor(x => x.RecipientId).NotEmpty(); // Adds own rules
    }
}

// DI: auto-discover ALL validators in the assembly
builder.Services.AddValidatorsFromAssemblyContaining<Program>();
// New request type? Add a validator class. No existing validators touched.

Think of a mail carrier who delivers letters, packages, and newspapers. One day the post office adds a new service: urgent telegrams. The rule says "deliver the telegram first, then continue your route." But someone wrote the instruction as "deliver the telegram, then go home." So the carrier delivers the telegram and heads back to the office, leaving all the letters and packages undelivered. Nobody notices until customers start calling about missing mail.

That's what return does in a loop. The NotificationSender had a foreach loop that iterated through the user's preferred channels (push, email, SMS). Each case in the switch sent the notification and then called return -- meaning the method exited completely after the first channel. The original developer probably intended break (exit the switch, continue the loop) but wrote return (exit the entire method).

When the system only had email and SMS, this bug technically existed but was hidden. Most users had only one preference, so the early return after the first channel didn't matter. But when push notifications were added as the first preference for many users, the return after SendPush() killed the loop before email and SMS could fire.

The deceptive part: push notifications worked perfectly. Everyone got their push alerts. The team celebrated the successful launch. It took 8 hours before a customer called about a missing email receipt -- and another 2 hours to realize it wasn't an email server issue but a code flow problem. The push feature had silently disabled email and SMS for every user who had push as their first preference.

Time to Diagnose

8 hours -- the push notifications worked perfectly, masking the fact that email/SMS stopped. Only noticed when a customer complained about missing email receipts.

public class NotificationSender
{
    public async Task SendAsync(Notification notification)
    {
        // All channels in one method -- order matters!
        foreach (var pref in notification.User.Preferences)
        {
            switch (pref)
            {
                case "push":
                    await SendPush(notification);
                    return; // BUG: early return skips remaining channels!
                case "email":
                    await SendEmail(notification);
                    return;
                case "sms":
                    await SendSms(notification);
                    return;
            }
        }
    }
}

public interface INotificationChannel
{
    string ChannelType { get; }
    Task SendAsync(Notification notification);
}

public class EmailChannel : INotificationChannel { /* self-contained */ }
public class SmsChannel : INotificationChannel { /* self-contained */ }
public class PushChannel : INotificationChannel { /* NEW -- no existing code changed */ }

public class NotificationDispatcher(IEnumerable<INotificationChannel> channels)
{
    public async Task DispatchAsync(Notification notification)
    {
        var userPrefs = notification.User.Preferences;
        var tasks = channels
            .Where(c => userPrefs.Contains(c.ChannelType))
            .Select(c => c.SendAsync(notification));
        await Task.WhenAll(tasks); // All matching channels fire in parallel
    }
}

Imagine a translation office where all translators share the same dictionary. The French translator adds a note next to "chat" -- "in French, this means cat." Now the Spanish translator looks up "chat" and gets confused, because in Spanish it means something else entirely. The shared dictionary worked fine when only one person used it, but the moment a second language needed different rules for the same word, the shared resource became a liability.

That's exactly what happened with the FormatValue() helper. CSV files and JSON files both deal with quotes in text, but they handle them completely differently. In CSV, you escape a quote by doubling it: " becomes "". In JSON, you escape it with a backslash: " becomes \". The developer needed JSON escaping, so they changed the shared FormatValue() method to use backslash escaping. But that same method was also called by the CSV export code.

The result: CSV files with customer addresses like 123 "Main" St now contained 123 \"Main\" St -- backslash-escaped quotes that broke every CSV parser trying to import the data. Excel showed garbage. Accounting tools rejected the files. Customer data imports failed silently, with addresses being split across wrong columns.

The bug went unnoticed for 3 days because CSV exports happened on a nightly batch schedule. By the time the accounting team noticed the corrupted files on Monday morning, three days of reports were bad. Nobody connected "we launched JSON export on Friday" with "CSV reports are broken on Monday" because they seemed like completely unrelated features. The detective work took hours of git blame before someone found the shared helper method.

Time to Diagnose

3 days -- CSV exports had been working for 2 years. Nobody suspected the JSON feature caused CSV corruption because they were "unrelated features." But they shared a helper method.

public class ReportExporter
{
    public byte[] Export(ReportData data, string format)
    {
        return format switch
        {
            "csv" => ExportCsv(data),
            "pdf" => ExportPdf(data),
            "excel" => ExportExcel(data),
            "json" => ExportJson(data),  // NEW
            _ => throw new NotSupportedException(format)
        };
    }

    // Shared helper -- modified for JSON, broke CSV
    private string FormatValue(object value)
    {
        var str = value?.ToString() ?? "";
        str = str.Replace("\"", "\\\""); // Added for JSON, corrupts CSV!
        return str;
    }
    // All export methods call FormatValue -- change affects ALL formats
}

public interface IReportExporter
{
    string Format { get; }
    byte[] Export(ReportData data);
}

public class CsvExporter : IReportExporter
{
    public string Format => "csv";
    public byte[] Export(ReportData data)
    {
        // Own FormatValue -- CSV-specific escaping (double-quote wrapping)
        string FormatValue(object val) => $"\"{val?.ToString()?.Replace("\"", "\"\"")}\"";
        // ... CSV generation with its own formatting logic
    }
}

public class JsonExporter : IReportExporter
{
    public string Format => "json";
    public byte[] Export(ReportData data)
    {
        // Own formatting -- JSON-specific escaping (backslash)
        return JsonSerializer.SerializeToUtf8Bytes(data);
    }
}
// Adding JsonExporter can't break CsvExporter -- different classes, different files

Think of a building with security checkpoints. The plan is: first, show your ID badge (authentication), then pass the rate-limiting turnstile that allows 10 entries per person per hour. But someone installed the turnstile BEFORE the ID check. Now the turnstile doesn't know who you are, so it counts by appearance -- everyone entering through the same door (same IP address) shares the same counter. Ten employees from the same office building hit the limit, while a stranger who walks in through a different door gets unlimited access.

In ASP.NET Core, middleware runs in the order you register it in Program.cs. The developer added app.UseRateLimiting() at the top of the pipeline -- before app.UseAuthentication(). At that point in the pipeline, the request hasn't been authenticated yet. The HttpContext.User is empty. So the rate limiter falls back to tracking by IP address instead of by user identity.

This created a double problem. First, legitimate corporate users behind a shared proxy IP got rate-limited after just 10 requests combined -- one person's API calls ate into everyone else's quota. Second, attackers who used unique IPs (botnets, cloud functions) each got their own fresh quota of 10 requests, effectively bypassing the rate limiter entirely. The security feature was protecting against good users and letting bad actors through.

The team spent a full day debugging. Corporate customers reported "429 Too Many Requests" errors. The security team saw their rate limiter was active and working -- it was blocking requests. But it was blocking the wrong requests. The mismatch between "rate limiter is working" and "wrong people are being limited" made this incredibly confusing to diagnose.

Time to Diagnose

1 day -- corporate customers reported "429 Too Many Requests" errors while the security team didn't understand why their rate limiter wasn't stopping abuse.

var app = builder.Build();

app.UseRateLimiting();    // Rate limits by IP -- auth hasn't run yet
app.UseAuthentication();  // Too late -- rate limit already applied
app.UseAuthorization();
app.MapControllers();

// Result: corporate proxy users (same IP) get rate-limited
// while attackers from unique IPs get unlimited access

var app = builder.Build();

app.UseAuthentication();  // Auth runs FIRST -- establishes user identity
app.UseAuthorization();   // Authz validates permissions
app.UseRateLimiting();    // Rate limits by authenticated user ID, not IP
app.MapControllers();

// Rate limiter can use HttpContext.User.Identity -- per-user limits
// Unauthenticated requests rejected before reaching rate limiter

With OCP, each implementation is a standalone class. Test it independently — no need to test through the orchestrator.

[Fact]
public void CorporateDiscount_AtExactThreshold_ReturnsDiscount()
{
    var rule = new CorporateDiscount();
    var customer = new Customer { Type = "corporate", AnnualSpend = 10_000 };
    var order = new Order { Total = 100m };

    Assert.True(rule.Applies(order, customer));
    Assert.Equal(15m, rule.Calculate(order, customer));
}

[Fact]
public void CorporateDiscount_BelowThreshold_DoesNotApply()
{
    var rule = new CorporateDiscount();
    var customer = new Customer { Type = "corporate", AnnualSpend = 9_999 };

    Assert.False(rule.Applies(new Order(), customer));
}
// Each discount rule tested in its own test class — zero mocking needed

The orchestrator (e.g., DiscountEngine) should be tested with fake implementations to verify composition logic, not individual rules.

[Fact]
public void DiscountEngine_SumsAllApplicableRules()
{
    var rules = new IDiscountRule[]
    {
        new FakeRule(applies: true, discount: 10m),
        new FakeRule(applies: false, discount: 50m), // Should be skipped
        new FakeRule(applies: true, discount: 5m),
    };
    var engine = new DiscountEngine(rules);

    var total = engine.Calculate(new Order { Total = 100m }, new Customer());

    Assert.Equal(15m, total); // 10 + 5 (skipped the false one)
}

private class FakeRule(bool applies, decimal discount) : IDiscountRule
{
    public bool Applies(Order o, Customer c) => applies;
    public decimal Calculate(Order o, Customer c) => discount;
}

When you have multiple implementations of the same interface, write a contract testA test that verifies all implementations of an interface obey the same behavioral contract. You write the test once and run it against every implementation using xUnit's Theory/MemberData or NUnit's TestCaseSource. that all implementations must pass.

public class PaymentHandlerContractTests
{
    // Every IPaymentHandler must pass these tests
    public static IEnumerable<object[]> Handlers => new[]
    {
        new object[] { new StripeHandler() },
        new object[] { new PayPalHandler() },
        new object[] { new CryptoHandler() },
    };

    [Theory, MemberData(nameof(Handlers))]
    public async Task AllHandlers_ReturnSuccessForValidOrder(IPaymentHandler handler)
    {
        var order = new Order { Total = 50m, Currency = "USD" };
        var result = await handler.ProcessAsync(order);
        Assert.True(result.IsSuccess);
        Assert.NotNull(result.TransactionId);
    }

    [Theory, MemberData(nameof(Handlers))]
    public async Task AllHandlers_RejectZeroAmount(IPaymentHandler handler)
    {
        var order = new Order { Total = 0m };
        var result = await handler.ProcessAsync(order);
        Assert.False(result.IsSuccess);
    }
}
// When you add a new handler, add it to Handlers — the contract tests run automatically

Use NetArchTestA .NET library for writing architecture tests that run as unit tests. It uses reflection to verify architectural rules — like "all classes in the Services namespace must implement an interface" or "no class should depend directly on a concrete repository." to ensure no new code violates OCP patterns.

[Fact]
public void Services_ShouldNotDependOnConcreteRepositories()
{
    var result = Types.InAssembly(typeof(Program).Assembly)
        .That().ResideInNamespace("MyApp.Services")
        .ShouldNot().HaveDependencyOn("MyApp.Infrastructure.Repositories")
        .GetResult();
    Assert.True(result.IsSuccessful, "Services must depend on interfaces, not concrete repos");
}

[Fact]
public void AllDiscountRules_MustImplementIDiscountRule()
{
    var result = Types.InAssembly(typeof(Program).Assembly)
        .That().HaveNameEndingWith("Discount")
        .Should().ImplementInterface(typeof(IDiscountRule))
        .GetResult();
    Assert.True(result.IsSuccessful);
}

Find all OCP violations in this code. What would you change?

public class TaxCalculator
{
    public decimal Calculate(string country, decimal amount)
    {
        return country switch
        {
            "US" => amount * 0.07m,
            "UK" => amount * 0.20m,
            "DE" => amount * 0.19m,
            "JP" => amount * 0.10m,
            // TODO: Add India, Brazil, Canada...
            _ => throw new NotSupportedException($"Country: {country}")
        };
    }
}

public interface ITaxRule
{
    string CountryCode { get; }
    decimal Calculate(decimal amount);
}

public class UsTax : ITaxRule { public string CountryCode => "US"; public decimal Calculate(decimal amount) => amount * 0.07m; }
public class UkTax : ITaxRule { public string CountryCode => "UK"; public decimal Calculate(decimal amount) => amount * 0.20m; }
// Add new countries as new classes — TaxCalculator never changes

public class TaxCalculator(IEnumerable<ITaxRule> rules)
{
    public decimal Calculate(string country, decimal amount) =>
        rules.First(r => r.CountryCode == country).Calculate(amount);
}

Refactor this class to follow OCP. Requirements:

• Support adding new report formats without modifying existing code
• Each format should handle its own serialization
• The caller should be able to request a specific format by name

public class ReportService
{
    public byte[] Generate(ReportData data, string format)
    {
        if (format == "pdf")
        {
            // 40 lines of PDF generation
            return PdfLibrary.Create(data);
        }
        else if (format == "csv")
        {
            var sb = new StringBuilder();
            sb.AppendLine(string.Join(",", data.Headers));
            foreach (var row in data.Rows)
                sb.AppendLine(string.Join(",", row));
            return Encoding.UTF8.GetBytes(sb.ToString());
        }
        else if (format == "excel")
        {
            // 30 lines of Excel generation
            return ExcelPackage.Create(data);
        }
        throw new NotSupportedException(format);
    }
}

public interface IReportFormatter
{
    string Format { get; }
    byte[] Generate(ReportData data);
}

public class PdfFormatter : IReportFormatter
{
    public string Format => "pdf";
    public byte[] Generate(ReportData data) => PdfLibrary.Create(data);
}

public class CsvFormatter : IReportFormatter
{
    public string Format => "csv";
    public byte[] Generate(ReportData data)
    {
        var sb = new StringBuilder();
        sb.AppendLine(string.Join(",", data.Headers));
        foreach (var row in data.Rows)
            sb.AppendLine(string.Join(",", row));
        return Encoding.UTF8.GetBytes(sb.ToString());
    }
}

public class ExcelFormatter : IReportFormatter
{
    public string Format => "excel";
    public byte[] Generate(ReportData data) => ExcelPackage.Create(data);
}

// Closed for modification — new formats don't touch this class
public class ReportService(IEnumerable<IReportFormatter> formatters)
{
    public byte[] Generate(ReportData data, string format) =>
        formatters.FirstOrDefault(f => f.Format == format)
            ?.Generate(data)
            ?? throw new NotSupportedException($"No formatter for: {format}");
}

// DI registration:
builder.Services.AddScoped<IReportFormatter, PdfFormatter>();
builder.Services.AddScoped<IReportFormatter, CsvFormatter>();
builder.Services.AddScoped<IReportFormatter, ExcelFormatter>();

Write NetArchTest rules that verify:

• All classes in MyApp.Discounts namespace implement IDiscountRule
• The DiscountEngine class doesn't reference any concrete discount class
• No class in MyApp.Services has a dependency on concrete repositories

using NetArchTest.Rules;

[Fact]
public void AllDiscounts_MustImplementIDiscountRule()
{
    var result = Types.InAssembly(typeof(Program).Assembly)
        .That().ResideInNamespace("MyApp.Discounts")
        .And().AreNotInterfaces()
        .Should().ImplementInterface(typeof(IDiscountRule))
        .GetResult();

    Assert.True(result.IsSuccessful,
        $"These classes don't implement IDiscountRule: {string.Join(", ", result.FailingTypeNames ?? [])}");
}

[Fact]
public void DiscountEngine_ShouldNotReferenceConcreteDiscounts()
{
    var concreteDiscounts = Types.InAssembly(typeof(Program).Assembly)
        .That().ResideInNamespace("MyApp.Discounts")
        .And().ImplementInterface(typeof(IDiscountRule))
        .GetTypes().Select(t => t.FullName!).ToArray();

    var result = Types.InAssembly(typeof(Program).Assembly)
        .That().HaveName("DiscountEngine")
        .ShouldNot().HaveDependencyOnAny(concreteDiscounts)
        .GetResult();

    Assert.True(result.IsSuccessful, "DiscountEngine references concrete discounts!");
}

[Fact]
public void Services_ShouldNotDependOnConcreteRepositories()
{
    var result = Types.InAssembly(typeof(Program).Assembly)
        .That().ResideInNamespace("MyApp.Services")
        .ShouldNot().HaveDependencyOn("MyApp.Infrastructure.Repositories")
        .GetResult();

    Assert.True(result.IsSuccessful);
}

Design a pricing engine that supports:

• Multiple discount types (percentage, fixed, buy-one-get-one)
• Discount stacking rules (some discounts combine, some don't)
• Priority ordering (employee discount before seasonal)
• Adding new discount types without modifying existing code

Constraints: Max 2 dependencies per class. All discount rules must be independently testable. The engine must log which rules were applied.

public interface IDiscountRule
{
    int Priority { get; }           // Lower = runs first
    bool IsStackable { get; }       // Can combine with other discounts?
    bool Applies(OrderContext ctx);
    DiscountResult Calculate(OrderContext ctx);
}

public record DiscountResult(decimal Amount, string RuleName, string Reason);
public record OrderContext(Order Order, Customer Customer, DateTime Now);

public class PricingEngine(
    IEnumerable<IDiscountRule> rules,
    ILogger<PricingEngine> logger)
{
    public PricingResult Calculate(OrderContext ctx)
    {
        var applicable = rules
            .Where(r => r.Applies(ctx))
            .OrderBy(r => r.Priority)
            .ToList();

        var results = new List<DiscountResult>();
        var hasNonStackable = false;

        foreach (var rule in applicable)
        {
            if (hasNonStackable)
                break; // Non-stackable discount was applied — stop processing

            var result = rule.Calculate(ctx);
            results.Add(result);
            logger.LogInformation("Applied {Rule}: {Amount}", result.RuleName, result.Amount);

            if (!rule.IsStackable)
                hasNonStackable = true;
        }

        return new PricingResult(ctx.Order.Total, results.Sum(r => r.Amount), results);
    }
}

// Example rules — each is its own class, independently testable
public class PercentageDiscount : IDiscountRule
{
    public int Priority => 10;
    public bool IsStackable => true;
    public bool Applies(OrderContext ctx) => ctx.Customer.LoyaltyYears >= 1;
    public DiscountResult Calculate(OrderContext ctx) =>
        new(ctx.Order.Total * 0.05m, "Loyalty 5%", "1+ year customer");
}

public class EmployeeDiscount : IDiscountRule
{
    public int Priority => 1; // Highest priority
    public bool IsStackable => false; // Can't combine with others
    public bool Applies(OrderContext ctx) => ctx.Customer.IsEmployee;
    public DiscountResult Calculate(OrderContext ctx) =>
        new(ctx.Order.Total * 0.30m, "Employee 30%", "Internal employee");
}

Keyed servicesA .NET 8 DI feature that lets you register multiple implementations of the same interface with different string or enum keys. You resolve a specific one using [FromKeyedServices("key")] — useful when you need a specific strategy rather than all strategies. (new in .NET 8) solve a common OCP pain point: resolving a specific implementation from a multi-registration. Before keyed services, you needed a factory or IEnumerable<T> with a LINQ lookup.

// Registration — each implementation has a key
builder.Services.AddKeyedScoped<IPaymentHandler, StripeHandler>("stripe");
builder.Services.AddKeyedScoped<IPaymentHandler, PayPalHandler>("paypal");
builder.Services.AddKeyedScoped<IPaymentHandler, CryptoHandler>("crypto");

// Resolution — request a specific implementation by key
public class CheckoutEndpoint
{
    public static async Task<IResult> Process(
        [FromBody] CheckoutRequest req,
        [FromKeyedServices("stripe")] IPaymentHandler handler) // ← specific handler
    {
        var result = await handler.ProcessAsync(req.Order);
        return Results.Ok(result);
    }
}

// Dynamic resolution via IServiceProvider
public class PaymentService(IServiceProvider sp)
{
    public async Task<PaymentResult> ProcessAsync(Order order, string method)
    {
        var handler = sp.GetRequiredKeyedService<IPaymentHandler>(method);
        return await handler.ProcessAsync(order);
    }
}

Keyed services maintain OCP: adding a new handler is a new class + one DI registration. The PaymentService orchestrator never changes — it resolves by key dynamically.

MediatR's IPipelineBehavior<TRequest, TResponse> is a textbook OCP implementation for cross-cutting concerns. Each behavior wraps the handler — adding validation, logging, or caching without modifying handlers.

// Validation behavior — runs BEFORE every handler, automatically
public class ValidationBehavior<TReq, TRes>(
    IEnumerable<IValidator<TReq>> validators) : IPipelineBehavior<TReq, TRes>
    where TReq : IRequest<TRes>
{
    public async Task<TRes> Handle(
        TReq request,
        RequestHandlerDelegate<TRes> next,
        CancellationToken ct)
    {
        var failures = validators
            .Select(v => v.Validate(request))
            .SelectMany(r => r.Errors)
            .Where(f => f != null)
            .ToList();

        if (failures.Count != 0)
            throw new ValidationException(failures);

        return await next(); // ✓ Handler is untouched — validation is layered on
    }
}

// Logging behavior — runs AROUND every handler
public class LoggingBehavior<TReq, TRes>(
    ILogger<LoggingBehavior<TReq, TRes>> log) : IPipelineBehavior<TReq, TRes>
    where TReq : IRequest<TRes>
{
    public async Task<TRes> Handle(
        TReq request,
        RequestHandlerDelegate<TRes> next,
        CancellationToken ct)
    {
        log.LogInformation("Handling {Request}", typeof(TReq).Name);
        var sw = Stopwatch.StartNew();
        var response = await next();
        log.LogInformation("Handled {Request} in {Ms}ms", typeof(TReq).Name, sw.ElapsedMilliseconds);
        return response;
    }
}

// DI registration — add behaviors without changing handlers
builder.Services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehavior<,>));
builder.Services.AddTransient(typeof(IPipelineBehavior<,>), typeof(LoggingBehavior<,>));

Adding a new behavior (caching, authorization, metrics) is adding a new class. Existing handlers and existing behaviors remain untouched. This is Decorator + Chain of Responsibility enabling OCP.

The Specification patternA pattern where business rules are encapsulated in specification objects that can be combined using AND, OR, NOT operators. Each specification answers "does this entity match?" — and they compose without modifying each other. achieves OCP for complex query logic. Each business rule is a specification that can be combined without modification.

public abstract class Specification<T>
{
    public abstract Expression<Func<T, bool>> ToExpression();

    // Combinators — AndSpec/OrSpec/NotSpec combine Expression trees
    public Specification<T> And(Specification<T> other) => new AndSpecification<T>(this, other);
    public Specification<T> Or(Specification<T> other) => new OrSpecification<T>(this, other);
    public Specification<T> Not() => new NotSpecification<T>(this);
}

// Combinator implementations (combine expressions using Expression.AndAlso, etc.)
internal class AndSpecification<T>(Specification<T> left, Specification<T> right) : Specification<T>
{
    public override Expression<Func<T, bool>> ToExpression()
    {
        var leftExpr = left.ToExpression();
        var rightExpr = right.ToExpression();
        var param = Expression.Parameter(typeof(T));
        var body = Expression.AndAlso(
            Expression.Invoke(leftExpr, param),
            Expression.Invoke(rightExpr, param));
        return Expression.Lambda<Func<T, bool>>(body, param);
    }
}
// OrSpecification and NotSpecification follow the same pattern

// Each business rule is a separate specification — independently testable
public class ActiveCustomerSpec : Specification<Customer>
{
    public override Expression<Func<Customer, bool>> ToExpression()
        => c => c.IsActive && c.LastOrderDate > DateTime.UtcNow.AddMonths(-6);
}

public class HighValueCustomerSpec : Specification<Customer>
{
    public override Expression<Func<Customer, bool>> ToExpression()
        => c => c.TotalSpend > 10_000;
}

// Compose specifications — neither original is modified
var targetCustomers = new ActiveCustomerSpec().And(new HighValueCustomerSpec());

// Use with EF Core — translates to SQL WHERE clause
var customers = await db.Customers
    .Where(targetCustomers.ToExpression())
    .ToListAsync();

New business rules are new specification classes. Existing specifications are never modified. Composition (And, Or, Not) creates new behavior from existing pieces. This is OCP at the query level.

Use git log to find files that change frequently for the same reason ("add new X type").

# Find files changed most often with "add" in the commit message
git log --oneline --all --name-only | grep -E "\.cs$" | sort | uniq -c | sort -rn | head -20

# If PaymentProcessor.cs appears in 15+ commits, it's a magnet
# Look at the commit messages:
git log --oneline -- src/Services/PaymentProcessor.cs
# "Add Stripe support", "Add PayPal support", "Add crypto support" → OCP needed!

Extract the first case from the switch into its own class implementing a new interface. Keep the switch as a fallback.

// NEW: Interface based on the varying behavior
public interface IPaymentHandler
{
    string Method { get; }
    Task<PaymentResult> ProcessAsync(Order order);
}

// NEW: First implementation extracted from the switch
public class StripeHandler : IPaymentHandler
{
    public string Method => "stripe";
    public async Task<PaymentResult> ProcessAsync(Order order) { /* moved from switch */ }
}

// MODIFIED: PaymentProcessor uses new handler OR falls back to switch
public class PaymentProcessor(IEnumerable<IPaymentHandler> handlers)
{
    public async Task<PaymentResult> ProcessAsync(Order order, string method)
    {
        var handler = handlers.FirstOrDefault(h => h.Method == method);
        if (handler != null) return await handler.ProcessAsync(order);

        // Fallback: remaining cases still in switch (temporary)
        return method switch
        {
            "paypal" => await ChargePayPal(order),
            "crypto" => await ChargeCrypto(order),
            _ => throw new NotSupportedException(method)
        };
    }
}

Over subsequent PRs, extract each remaining case into its own handler. When the switch is empty, delete it.

// Final state: switch is gone. PaymentProcessor is CLOSED.
public class PaymentProcessor(IEnumerable<IPaymentHandler> handlers)
{
    public async Task<PaymentResult> ProcessAsync(Order order, string method)
    {
        var handler = handlers.FirstOrDefault(h => h.Method == method)
            ?? throw new NotSupportedException($"No handler for: {method}");
        return await handler.ProcessAsync(order);
    }
}

// DI: all handlers registered
builder.Services.AddScoped<IPaymentHandler, StripeHandler>();
builder.Services.AddScoped<IPaymentHandler, PayPalHandler>();
builder.Services.AddScoped<IPaymentHandler, CryptoHandler>();

// ✓ Next quarter: adding Apple Pay is ONE new class + ONE DI line

• ☐ Does the PR add a new case to an existing switch/if-else? If yes, should this be an OCP extraction?
• ☐ Is there a new ConcreteClass() inside business logic? Should this be injected via DI?
• ☐ Does the interface have too many members? Would smaller, role-specific interfaces (ISP) be better?
• ☐ Is the interface designed around the first implementation? Check for leaky abstractions (Stripe-specific types in a generic payment interface).
• ☐ Is this a premature abstraction? Does the interface have only one implementation with no concrete plans for more?
• ☐ Are implementations sealed? If they won't be subclassed, sealing enables JIT optimization.
• ☐ Does the orchestrator only depend on abstractions? It should never reference concrete implementation types.
• ☐ Are there contract tests? All implementations of the same interface should pass the same behavioral tests.