SOLID in Real .NET Projects — Violations and Fixes

// This single class violates all five SOLID principles
public class PatientManager
{
    private ApplicationDbContext _db = new ApplicationDbContext();

    // SRP: handles CRUD, reporting, notifications, and scheduling — too many responsibilities
    public void SavePatient(Patient p) { _db.Patients.Add(p); _db.SaveChanges(); }

    public byte[] GeneratePatientReport(Patient p)  // report logic in "manager"?
    {
        if (reportType == "PDF")   return GeneratePdf(p);   // OCP: new type = modify this
        else if (reportType == "Excel") return GenerateExcel(p);
        throw new NotSupportedException();
    }

    public void Send(string channel, string message)  // ISP: single method for all channels
    {
        if (channel == "SMS")  { /* SMS */ }
        if (channel == "Fax")  { throw new NotImplementedException(); }  // LSP violation
    }

    // DIP: concrete dependencies, not abstractions
}

// PatientRepository: only persistence
// PatientReportService: only reporting
// PatientAlertService: only notifications
// PatientScheduler: only scheduling

// Each class has one reason to change:
//   PatientRepository: if the database changes
//   PatientReportService: if the report format changes
//   PatientAlertService: if the notification channel changes

// Report formats are extension points — each is a separate class
public interface IReportGenerator { byte[] Generate(Patient patient); }
public sealed class PdfReportGenerator  : IReportGenerator { /* ... */ }
public sealed class ExcelReportGenerator : IReportGenerator { /* ... */ }
// Adding HTML: new class, no existing code changes

// Fax channel either fully implements IAlertChannel or is removed
// If Fax cannot send async alerts, it should not implement IAlertChannel
// Consider: ISyncAlertChannel separate interface for fax

public interface IInstantAlert { Task SendAsync(PatientAlert alert, CancellationToken ct); }
public interface IScheduledAlert { Task ScheduleAsync(PatientAlert alert, DateTime sendAt, CancellationToken ct); }
// SMS implements IInstantAlert only — no ScheduleAsync
// Email implements both

public sealed class PatientAlertService
{
    private readonly IEnumerable<IInstantAlert> _channels;
    private readonly IClock _clock;

    public PatientAlertService(IEnumerable<IInstantAlert> channels, IClock clock)
    {
        _channels = channels;
        _clock    = clock;
    }
}

SOLID benefits:
  ✓ Code is easier to test (DIP + SRP)
  ✓ Features are easier to add (OCP)
  ✓ Interfaces are simpler (ISP)
  ✓ Substitutions work correctly (LSP)

SOLID costs:
  ✗ More files, more interfaces, more indirection
  ✗ Takes time to design correctly upfront
  ✗ Overkill for simple, short-lived scripts
  ✗ Can lead to over-engineering if applied blindly

Apply SOLID where:
  → The code is expected to change (new business rules, new channels, new formats)
  → Tests are written and rely on the design
  → Multiple developers work in the same area

Skip SOLID where:
  → Simple CRUD with no expected variation
  → Throwaway scripts and one-off utilities
  → Early prototyping where requirements are unknown

Before writing a class, ask:
  □ What is this class responsible for? (SRP)
  □ Where will I need to add new behavior later? (OCP)
  □ Does every implementation honor the contract? (LSP)
  □ Does this interface have unused methods in some implementations? (ISP)
  □ Does this class create its own dependencies? (DIP)

Code review signals:
  ✗ Class has >200 lines: likely SRP violation
  ✗ if/switch on type or format: likely OCP violation
  ✗ NotImplementedException in a method: likely LSP + ISP violation
  ✗ Interface has >8 methods: likely ISP violation
  ✗ new ConcreteService() inside a class body: likely DIP violation