OOP & SOLID for Dummies

Imagine a coffee shop. You don't think "step 1: heat water, step 2: grind beans…". You think in things — a Barista, a CoffeeMachine, an Order. Each thing has data (state) and actions (behaviour). That's OOP.

// A "thing" in code is called a CLASS.
// An actual instance of that thing is called an OBJECT.

public class CoffeeMachine
{
    // ── STATE (data the object owns) ─────────────
    public int  WaterLevel  { get; private set; } = 100;
    public bool IsOn        { get; private set; }

    // ── BEHAVIOUR (what the object can do) ───────
    public void TurnOn()  => IsOn = true;
    public void TurnOff() => IsOn = false;

    public void Brew()
    {
        if (!IsOn)            throw new InvalidOperationException("Turn me on first!");
        if (WaterLevel < 10)  throw new InvalidOperationException("Refill me!");
        WaterLevel -= 10;
        Console.WriteLine("☕ Brewing...");
    }
}

// Using it:
var machine = new CoffeeMachine();   // ← that's an OBJECT
machine.TurnOn();
machine.Brew();
Console.WriteLine(machine.WaterLevel);   // 90

A class is the cookie cutter. An object is a cookie made with it. You write the class once; you can create as many objects from it as you want, each with its own data.

// The cookie cutter (class — written once)
public class Dog
{
    public string Name  { get; set; } = "";
    public int    Age   { get; set; }

    public void Bark() => Console.WriteLine($"{Name}: Woof!");
}

// The cookies (objects — made many times)
var rex   = new Dog { Name = "Rex",   Age = 4 };
var luna  = new Dog { Name = "Luna",  Age = 2 };
var buddy = new Dog { Name = "Buddy", Age = 7 };

rex.Bark();    // Rex: Woof!
luna.Bark();   // Luna: Woof!

// Each object has its OWN data — changing rex.Age
// doesn't touch luna or buddy.
rex.Age = 5;
Console.WriteLine(luna.Age);   // still 2

OOP rests on four ideas. Don't worry about memorising them yet — each pillar gets its own card. Here's the one-line version of each:

// 1️⃣  ENCAPSULATION
//    "Hide the messy details, expose a simple button."
//    → A microwave: you press Start. You don't wire the magnetron.

// 2️⃣  INHERITANCE
//    "A Dog IS-A Animal. Reuse what Animal already knows."
//    → A SportsCar IS-A Car. It already has wheels & an engine.

// 3️⃣  POLYMORPHISM
//    "Same call, different behaviour depending on the object."
//    → animal.MakeSound() barks for a Dog, meows for a Cat.

// 4️⃣  ABSTRACTION
//    "Talk to a contract, not a specific implementation."
//    → You use ILogger; you don't care if it's a file or console.

// SOLID is FIVE rules that help you USE these pillars well.
// We'll get there in Section 5.

If anyone can poke your internal data directly, anyone can put your object into an impossible state. Here's the trap:

// ❌ BAD — public fields, no rules
public class BankAccount
{
    public decimal Balance;   // anyone can write whatever they want!
}

var acc = new BankAccount();
acc.Balance = -9999999m;   // 🤦  We just gave the user a million in debt
                           // because nothing stopped them.

Lock the data behind private. Expose only the operations that make sense, and check the rules inside the object — not in every caller.

public class BankAccount
{
    // ── Private state — outsiders can't touch it ─
    private decimal _balance;

    // ── Read-only "window" into the state ────────
    public decimal Balance => _balance;

    public void Deposit(decimal amount)
    {
        if (amount <= 0)
            throw new ArgumentException("Deposit must be positive.");
        _balance += amount;
    }

    public void Withdraw(decimal amount)
    {
        if (amount <= 0)
            throw new ArgumentException("Withdrawal must be positive.");
        if (amount > _balance)
            throw new InvalidOperationException("Not enough funds.");
        _balance -= amount;
    }
}

var acc = new BankAccount();
acc.Deposit(100);
acc.Withdraw(30);
// acc._balance = -1;   // ❌ compile error — _balance is private
Console.WriteLine(acc.Balance);   // 70

A C# property is a field with manners. You get a clean obj.Name syntax but the compiler still calls a hidden getter/setter — so you can add rules later without breaking callers.

public class Person
{
    // Read-write, no validation (auto-property)
    public string Name { get; set; } = "";

    // Read-only from outside, settable from inside the class
    public DateTime CreatedAt { get; private set; } = DateTime.UtcNow;

    // Set ONCE at construction, never again
    public Guid Id { get; init; } = Guid.NewGuid();

    // Custom setter with validation
    private int _age;
    public int Age
    {
        get => _age;
        set
        {
            if (value < 0 || value > 150)
                throw new ArgumentOutOfRangeException(nameof(value));
            _age = value;
        }
    }
}

var p = new Person { Name = "Anna", Age = 30 };
// p.Age = -5;   // throws — encapsulation enforced
// p.Id  = ...;  // compile error — init-only

You write the common stuff once in a base class, then create child classes for the specifics. The child automatically gets everything the parent had.

// Base class — shared bits live here
public class Animal
{
    public string Name { get; set; } = "";

    public void Eat()  => Console.WriteLine($"{Name} is eating.");
    public void Sleep() => Console.WriteLine($"{Name} is sleeping.");
}

// Child class — reuses Eat & Sleep "for free", adds its own
public class Dog : Animal           // ← " : Animal " means "is an Animal"
{
    public void Bark() => Console.WriteLine($"{Name}: Woof!");
}

public class Cat : Animal
{
    public void Purr() => Console.WriteLine($"{Name}: Purr...");
}

var rex = new Dog { Name = "Rex" };
rex.Eat();    // inherited from Animal — Rex is eating.
rex.Bark();   // Dog-specific          — Rex: Woof!

// Rule of thumb: only use inheritance when "child IS-A parent"
// is genuinely true. A Car is NOT an Engine — it HAS-AN engine.

Mark a method virtual in the parent and override it in each child. Now you can call animal.MakeSound() without caring whether animal is actually a Dog or a Cat — each one knows what to do.

public class Animal
{
    public string Name { get; set; } = "";

    // "virtual" = children are ALLOWED to replace this
    public virtual void MakeSound() =>
        Console.WriteLine($"{Name} makes a sound.");
}

public class Dog : Animal
{
    public override void MakeSound() =>
        Console.WriteLine($"{Name}: Woof!");
}

public class Cat : Animal
{
    public override void MakeSound() =>
        Console.WriteLine($"{Name}: Meow!");
}

public class Cow : Animal
{
    public override void MakeSound() =>
        Console.WriteLine($"{Name}: Moo!");
}

// ── The magic moment ─────────────────────────────
Animal[] zoo =
{
    new Dog { Name = "Rex"  },
    new Cat { Name = "Luna" },
    new Cow { Name = "Bess" }
};

foreach (var a in zoo)
    a.MakeSound();   // Rex: Woof!  /  Luna: Meow!  /  Bess: Moo!

// One loop, three different behaviours. THAT is polymorphism.

Inheritance is tempting but easy to overuse. If you find yourself writing Manager : Employee : Person : LivingThing, stop. Prefer composition: an object has other objects that do the work.

// ❌ "is-a" abused — a Car is NOT an Engine
// public class Car : Engine { ... }   // wrong relationship

// ✅ "has-a" — a Car HAS an Engine, HAS Wheels, HAS a Radio
public class Engine { public void Start() => Console.WriteLine("Vroom"); }
public class Wheels { public void Roll()  => Console.WriteLine("Rolling"); }
public class Radio  { public void Play()  => Console.WriteLine("♪♪♪"); }

public class Car
{
    private readonly Engine _engine = new();
    private readonly Wheels _wheels = new();
    private readonly Radio  _radio  = new();

    public void Drive()
    {
        _engine.Start();
        _wheels.Roll();
        _radio.Play();
    }
}

// Why this is better:
//  - Swap any piece (e.g. ElectricEngine) without rewriting Car.
//  - Each piece is testable on its own.
//  - No "fragile base class" problem when Engine changes.

An interface says "anything that implements me must have these methods". It contains no code, only signatures. Then anyone who needs that capability can depend on the interface — not on a specific class.

// The contract — names of methods, no bodies
public interface ILogger
{
    void Info(string message);
    void Error(string message);
}

// Implementation #1 — writes to the console
public class ConsoleLogger : ILogger
{
    public void Info(string m)  => Console.WriteLine($"INFO:  {m}");
    public void Error(string m) => Console.WriteLine($"ERROR: {m}");
}

// Implementation #2 — writes to a file
public class FileLogger : ILogger
{
    private readonly string _path;
    public FileLogger(string path) => _path = path;

    public void Info(string m)  => File.AppendAllText(_path, $"INFO:  {m}\n");
    public void Error(string m) => File.AppendAllText(_path, $"ERROR: {m}\n");
}

// A class that uses ANY logger — it doesn't care which one
public class OrderService
{
    private readonly ILogger _log;
    public OrderService(ILogger log) => _log = log;

    public void Place(int orderId)
    {
        _log.Info($"Placing order {orderId}");
        // ... do work ...
    }
}

// Swap implementations without changing OrderService at all
var svc1 = new OrderService(new ConsoleLogger());
var svc2 = new OrderService(new FileLogger("log.txt"));

An abstract class is like an interface with some code already filled in. You can't instantiate it directly — only its concrete children. Use it when subclasses share state and behaviour, not just a contract.

// Abstract = "you can't 'new' me, you must subclass me"
public abstract class Shape
{
    public string Color { get; set; } = "black";

    // Concrete method — every shape gets this for free
    public void Describe() =>
        Console.WriteLine($"A {Color} shape with area {Area()}.");

    // Abstract method — every child MUST implement this
    public abstract double Area();
}

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

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

// var s = new Shape();           // ❌ compile error — abstract
var c = new Circle    { Radius = 5,         Color = "red"  };
var r = new Rectangle { Width  = 3, Height = 4, Color = "blue" };

c.Describe();   // A red shape with area 78.539...
r.Describe();   // A blue shape with area 12.

// Interface  → "what you can do"        (no state, multiple inheritance)
// Abstract   → "what you can do AND share" (state + base behaviour)

A class should have one reason to change. If your Invoice class calculates totals, writes to the database, and sends emails, three different teams will fight over it. Split it.

// ❌ BAD — three jobs in one class
public class Invoice
{
    public List<decimal> Lines { get; } = [];

    public decimal CalcTotal() => Lines.Sum();

    public void SaveToDb()  { /* SQL... */ }   // 🚩 reason to change #2
    public void EmailPdf()  { /* SMTP... */ }  // 🚩 reason to change #3
}

// ✅ GOOD — one job each
public class Invoice
{
    public List<decimal> Lines { get; } = [];
    public decimal CalcTotal() => Lines.Sum();
}

public class InvoiceRepository
{
    public void Save(Invoice inv) { /* SQL... */ }
}

public class InvoiceEmailer
{
    public void Send(Invoice inv) { /* SMTP... */ }
}

// Why bother?
//  - The DB schema changes → only InvoiceRepository changes.
//  - The email provider changes → only InvoiceEmailer changes.
//  - You can test CalcTotal() without touching DB or SMTP.

Classes should be open for extension, closed for modification. Adding a new feature should mean adding a new class — not editing existing, already-tested ones.

// ❌ BAD — every new shape forces you to edit the if/else
public class AreaCalculator
{
    public double Area(object shape)
    {
        if (shape is Circle c)        return Math.PI * c.R * c.R;
        if (shape is Rectangle r)     return r.W * r.H;
        if (shape is Triangle t)      return 0.5 * t.B * t.H;
        // tomorrow: add Hexagon → edit this method AGAIN
        throw new NotSupportedException();
    }
}

// ✅ GOOD — each shape knows its own area; calculator never changes
public interface IShape { double Area(); }

public class Circle    : IShape { public double R; public double Area() => Math.PI * R * R; }
public class Rectangle : IShape { public double W, H; public double Area() => W * H; }
public class Triangle  : IShape { public double B, H; public double Area() => 0.5 * B * H; }

public class AreaCalculator
{
    public double Total(IEnumerable<IShape> shapes) =>
        shapes.Sum(s => s.Area());
}

// Adding Hexagon tomorrow? Just write:
//    public class Hexagon : IShape { public double Area() => ... }
// AreaCalculator stays UNTOUCHED.

Anywhere you can use the parent class, you should be able to swap in a child class without breaking anything. If the child surprises the caller, you've broken Liskov.

// ❌ BAD — the classic "Square IS-A Rectangle" trap
public class Rectangle
{
    public virtual int Width  { get; set; }
    public virtual int Height { get; set; }
}

public class Square : Rectangle
{
    // A square forces width == height — breaks Rectangle's contract
    public override int Width  { set { base.Width = base.Height = value; } }
    public override int Height { set { base.Width = base.Height = value; } }
}

void Resize(Rectangle r) { r.Width = 5; r.Height = 4; /* expect area 20 */ }

Resize(new Rectangle());  // area = 20 ✅
Resize(new Square());     // area = 16 ❌  — Square broke the promise!

// ✅ GOOD — they're two different things; don't fake the IS-A
public interface IShape { int Area(); }
public class Rectangle : IShape { public int W, H; public int Area() => W * H; }
public class Square    : IShape { public int Side; public int Area() => Side * Side; }

// Lesson: "looks like" ≠ "behaves like". If subclassing forces you
// to break an expected behaviour, it's NOT an IS-A relationship.

Don't force a class to implement methods it doesn't need. Prefer many small interfaces over one giant one — callers should depend only on the methods they actually use.

// ❌ BAD — a "fat" interface that forces everyone to implement everything
public interface IMultiFunctionDevice
{
    void Print(string doc);
    void Scan(string doc);
    void Fax(string doc);
}

// A cheap printer that can't fax... must still implement Fax 🤦
public class CheapPrinter : IMultiFunctionDevice
{
    public void Print(string d) => Console.WriteLine($"Printing {d}");
    public void Scan(string d)  => throw new NotSupportedException();   // 💥
    public void Fax(string d)   => throw new NotSupportedException();   // 💥
}

// ✅ GOOD — split the contract by capability
public interface IPrinter { void Print(string doc); }
public interface IScanner { void Scan(string doc); }
public interface IFax     { void Fax(string doc); }

public class CheapPrinter : IPrinter
{
    public void Print(string d) => Console.WriteLine($"Printing {d}");
}

public class OfficeMachine : IPrinter, IScanner, IFax
{
    public void Print(string d) => Console.WriteLine($"Printing {d}");
    public void Scan(string d)  => Console.WriteLine($"Scanning {d}");
    public void Fax(string d)   => Console.WriteLine($"Faxing {d}");
}

// Callers depend only on what they need:
void Backup(IScanner s, string doc) => s.Scan(doc);

High-level code (business rules) should not depend on low-level code (file I/O, HTTP, DB). Both should depend on abstractions. In practice: take dependencies as interface parameters instead of new-ing them inside.

// ❌ BAD — OrderService is glued to SmtpEmailSender forever
public class SmtpEmailSender
{
    public void Send(string to, string body) { /* SMTP... */ }
}

public class OrderService
{
    private readonly SmtpEmailSender _email = new();   // 🚩 hard dependency

    public void Place(Order o)
    {
        // ... save order ...
        _email.Send(o.CustomerEmail, "Thanks!");
    }
}

// Problems:
//  - Can't unit-test without actually sending mail.
//  - Switching to SendGrid means editing OrderService.

// ✅ GOOD — depend on an INTERFACE, inject the concrete from outside
public interface IEmailSender
{
    void Send(string to, string body);
}

public class SmtpEmailSender    : IEmailSender { public void Send(string t, string b) { /* SMTP */ } }
public class SendGridSender     : IEmailSender { public void Send(string t, string b) { /* HTTP */ } }
public class FakeEmailForTests  : IEmailSender { public List<string> Sent = []; public void Send(string t, string b) => Sent.Add(t); }

public class OrderService
{
    private readonly IEmailSender _email;

    // The dependency is "injected" via the constructor (DI)
    public OrderService(IEmailSender email) => _email = email;

    public void Place(Order o)
    {
        // ... save order ...
        _email.Send(o.CustomerEmail, "Thanks!");
    }
}

// In production:
var svc  = new OrderService(new SmtpEmailSender());
// In tests:
var fake = new FakeEmailForTests();
var test = new OrderService(fake);
// Now you can assert on `fake.Sent` without any real email being sent.

A checkout that supports Card, PayPal, and Crypto payments. Adding a new method tomorrow means writing one new class — nothing else changes.

// ── Abstraction (DIP + OCP + ISP) ────────────
public interface IPaymentMethod
{
    bool Pay(decimal amount);
}

// ── Each concrete payment is a separate class (SRP) ──
public class CardPayment : IPaymentMethod
{
    public bool Pay(decimal amount)
    {
        Console.WriteLine($"💳 Charged €{amount} to card.");
        return true;
    }
}

public class PayPalPayment : IPaymentMethod
{
    public bool Pay(decimal amount)
    {
        Console.WriteLine($"🅿️ Sent €{amount} via PayPal.");
        return true;
    }
}

public class CryptoPayment : IPaymentMethod
{
    public bool Pay(decimal amount)
    {
        Console.WriteLine($"₿ Transferred €{amount} in crypto.");
        return true;
    }
}

// ── Checkout depends on the contract, NOT on a specific method (DIP) ──
public class Checkout
{
    private readonly IPaymentMethod _payment;
    public Checkout(IPaymentMethod payment) => _payment = payment;

    public void Complete(decimal amount)
    {
        if (amount <= 0) throw new ArgumentException("Amount must be positive."); // encapsulated rule
        if (_payment.Pay(amount))                                                   // polymorphism!
            Console.WriteLine("✅ Order complete.");
    }
}

// ── Usage ────────────────────────────────────
new Checkout(new CardPayment()).Complete(49.90m);
new Checkout(new PayPalPayment()).Complete(120m);
new Checkout(new CryptoPayment()).Complete(0.0021m);

// Tomorrow: ApplePay? Write one new class. Checkout stays untouched.
// → S: each class has one job.
// → O: extend by adding, not editing.
// → L: any IPaymentMethod can stand in for another.
// → I: IPaymentMethod is small & focused.
// → D: Checkout depends on the abstraction.

Keep this open in a tab. When in doubt, ask: "which letter am I violating right now?" — that question alone catches most design mistakes.

// ── OOP pillars ──────────────────────────────
//  Encapsulation  → Hide data, expose safe operations.
//  Inheritance    → Reuse via "IS-A"; prefer composition when in doubt.
//  Polymorphism   → Same call, behaviour decided by the object.
//  Abstraction    → Talk to a contract, not an implementation.

// ── SOLID ────────────────────────────────────
//  S — Single Responsibility    "One reason to change."
//  O — Open / Closed            "Extend by adding, not editing."
//  L — Liskov Substitution      "Children must keep parent's promises."
//  I — Interface Segregation    "Many small contracts > one fat one."
//  D — Dependency Inversion     "Depend on abstractions, inject concretes."

// ── Quick smell-test ─────────────────────────
//  → "I'm afraid to touch this class."          → probably SRP / OCP
//  → "This subclass throws NotImplemented."     → ISP / LSP
//  → "I can't unit-test this without a DB."     → DIP
//  → "Adding a feature means editing 5 files."  → OCP