SOLID Principles

In simple words#

Learning objectives#

• Name and explain all five SOLID principles
• Spot violations in real code
• Refactor a class to follow SRP and DIP
• Explain how SOLID relates to dependency injection and testing

Explanation#

S — Single Responsibility: a class should have one reason to change. An InvoiceService that also formats PDFs and sends emails has three.

O — Open/Closed: code should be open for extension but closed for modification. Add new behaviour by adding classes (polymorphism), not by editing a growing switch statement.

L — Liskov Substitution: a subclass must be usable anywhere its base class is expected, without surprises. If Square breaks code written for Rectangle, the hierarchy is wrong.

I — Interface Segregation: prefer several small interfaces over one large one, so classes are not forced to implement methods they do not use.

D — Dependency Inversion: high-level code should depend on abstractions, not on concrete low-level classes. Dependency injection is the usual way to achieve it.

Code example: Refactoring towards SRP and DIP#

1// ✗ Before: one class, three reasons to change, hard-wired dependencies
2public class InvoiceServiceBefore
3{
4    public void Process(Invoice invoice)
5    {
6        var total = invoice.Lines.Sum(l => l.Price * l.Qty);          // pricing rules
7        var pdf = 
quot;INVOICE {invoice.Id}: {total}";                    // formatting
8        new SmtpClient("smtp.example.com").Send("billing@x.com",        // delivery
9            invoice.CustomerEmail, "Invoice", pdf);
10    }
11}
12

13// ✓ After: each responsibility behind its own abstraction
14public interface IInvoiceCalculator { decimal Total(Invoice invoice); }
15public interface IInvoiceFormatter  { string Format(Invoice invoice, decimal total); }
16public interface IEmailSender       { Task SendAsync(string to, string subject, string body); }
17

18public class InvoiceService(IInvoiceCalculator calc, IInvoiceFormatter formatter, IEmailSender email)
19{
20    public async Task ProcessAsync(Invoice invoice)
21    {
22        var total = calc.Total(invoice);
23        var body = formatter.Format(invoice, total);
24        await email.SendAsync(invoice.CustomerEmail, 
quot;Invoice {invoice.Id}", body);
25    }
26}
27

28// Program.cs — wire up concrete implementations once
29// builder.Services.AddScoped<IInvoiceCalculator, StandardCalculator>();
30// builder.Services.AddScoped<IInvoiceFormatter, PdfFormatter>();
31// builder.Services.AddScoped<IEmailSender, SmtpEmailSender>();
32// builder.Services.AddScoped<InvoiceService>();

Behaviour is unchanged, but pricing, formatting and email delivery can now each change — or be faked in a unit test — independently.

This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.

Step-by-step explanation#

1. The “before” class calculates, formats and sends: three reasons to change (SRP violation).
2. It also creates SmtpClient itself, so it cannot be tested without a real mail server (DIP violation).
3. The refactor extracts each responsibility behind a small interface (ISP).
4. InvoiceService now depends only on abstractions supplied through its constructor (DIP).
5. Adding a GST-aware calculator means writing a new IInvoiceCalculator class — no edits to InvoiceService (OCP).

Real-world use case#

Common mistakes#

Best practices#

• Ask “how many reasons does this class have to change?”
• Inject dependencies through constructors
• Keep interfaces small and role-based
• Use SOLID as a guide when code becomes hard to change, not as up-front ceremony

Remember this#

Practice exercise#

11. Open/Closed — add new payment types as classes implementing IPayment instead of editing the switch.
22. Interface Segregation — split into IWorkable and IFeedable.
33. Dependency Inversion — depend on an IReportRepository injected through the constructor.

Mini quiz#

Want more? Practise all OOP Concepts MCQs · OOP Concepts interview questions

Related topics#

My notes#

Saved in this browser.