Understand the problem each principle solves, the cost of applying it, and the situations where breaking it leads to better software with practical C# examples and architectural insights.

Five principles, one acronym, and roughly a thousand posts explaining them with shapes and animals. The definitions are easy to find and easy to recite. What is harder to find is the part that matters: what each principle costs, which mistake it exists to prevent, and when applying it makes your code worse.

That is what this post is for. Each principle gets a definition, a diagram, working C# you can paste, and an honest note on where the idea breaks down.

The principles come from Robert C. Martin's paper Design Principles and Design Patterns. Michael Feathers later noticed the five could be rearranged into a word, and SOLID stuck. Worth keeping in mind that the acronym was spotted afterwards rather than designed. People treat the letters as a checklist and then wonder why they have forty interfaces and no behaviour.

Single Responsibility Principle

A class should have one and only one reason to change.

The usual gloss is "a class should do one thing", which sounds obvious and is almost useless, because "one thing" has no fixed size. Is "handle payments" one thing? Is "validate a card number"? Both, depending on where you stand.

The version that actually helps is Martin's later phrasing: a module should be responsible to one, and only one, actor. Not one thing. One source of change requests. If the finance team can make you edit this class, and so can the UI team, then it has two reasons to change and both will eventually arrive in the same week.

The mistake that looks like the fix

Start with a calculator that reads two numbers, adds them, and prints the result. Everyone writes this first:

double first = double.Parse(Console.ReadLine());
double second = double.Parse(Console.ReadLine());
double sum = first + second;
Console.WriteLine(sum);

Three responsibilities: take input, process it, display output. So you extract three methods and put them in a class:

// This looks like SRP. It is not.
public class Calculator
{
    public void TakeInput() { /* ... */ }
    public double Add(double first, double second) { /* ... */ }
    public void Display(double sum) { /* ... */ }
}

Ask the question the principle actually asks. How many reasons does Calculator have to change?

• The console becomes a GUI. TakeInput changes.
• Output must go to a file. Display changes.
• Addition must round to two decimals. Add changes.

Three reasons, one class. Nothing has been fixed.

Methods are not responsibilities. Extracting a method organises code inside a class. It does not change what the class is responsible to. This is the most common misunderstanding of SRP I run into when reviewing designs, and it is convincing precisely because the result looks tidier than what you started with.

Separating by actor

// Changes when the maths changes. Knows nothing about screens or files.
public class Calculator
{
    public double Add(double first, double second) => first + second;
}

// Changes when the input mechanism changes.
public interface IInputSource
{
    (double First, double Second) ReadOperands();
}

public class ConsoleInput : IInputSource
{
    public (double, double) ReadOperands()
    {
        var first = double.Parse(Console.ReadLine()!);
        var second = double.Parse(Console.ReadLine()!);
        return (first, second);
    }
}

// Changes when the output destination changes.
public interface IResultWriter
{
    void Write(double result);
}

public class ConsoleWriter : IResultWriter
{
    public void Write(double result) => Console.WriteLine(result);
}

// Changes when the workflow changes. Nothing else.
public class CalculatorApp
{
    private readonly IInputSource _input;
    private readonly Calculator _calculator;
    private readonly IResultWriter _writer;

    public CalculatorApp(IInputSource input, Calculator calculator, IResultWriter writer)
    {
        _input = input;
        _calculator = calculator;
        _writer = writer;
    }

    public void Run()
    {
        var (first, second) = _input.ReadOperands();
        var sum = _calculator.Add(first, second);
        _writer.Write(sum);
    }
}

Move to a GUI and you write a new IInputSource. Calculator does not know. Move to a file and you write a new IResultWriter. Calculator still does not know.

A test that takes ten seconds: describe the class in one sentence without using "and" or "or". If you cannot, you have found the seam.

Open/Closed Principle

Software entities should be open for extension but closed for modification.

You should be able to add behaviour by adding code, not by editing code that already works. The existing code has been tested and shipped. Every edit puts that at risk, and risk to working code is what this principle is really about.

A salary calculator with three employee types: Manager on 100000, Officer on 50000, Clerk on 20000.

public enum EmployeeType { Manager, Officer, Clerk }

public class SalaryCalculator
{
    public double GetSalary(EmployeeType type) => type switch
    {
        EmployeeType.Manager => 100000,
        EmployeeType.Officer => 50000,
        EmployeeType.Clerk   => 20000,
        _ => 0
    };
}

Then the client adds a Human Resource Manager on 35000. Add an enum value, add a case, rebuild, retest everything. Add an intern next month and do it again. The switch grows, and every new type is a chance to break an old one.

Let the type answer for itself:

public interface IEmployee
{
    double Salary { get; }
}

public class Manager : IEmployee { public double Salary => 100000; }
public class Officer : IEmployee { public double Salary => 50000; }
public class Clerk   : IEmployee { public double Salary => 20000; }

Now the HR manager is a new file, and you edit nothing:

public class HumanResourceManager : IEmployee { public double Salary => 35000; }

Closed against which axis?

Here is where most explanations stop and where the interesting problem starts. The client asks for tax on salaries above 50000. The tempting answer:

public double GetSalary(IEmployee employee)
{
    double salary = employee.Salary;
    if (salary > 50000)
    {
        return salary - (salary * 0.01);
    }
    return salary;
}

That is a modification, the exact thing OCP asks you not to do. The design solved the "new employee type" axis and left the "new salary rule" axis running straight through the same class. Rules change more often than types do.

So make the rule a thing:

public interface ISalaryRule
{
    double Apply(double salary);
}

public class TaxRule : ISalaryRule
{
    private readonly double _threshold;
    private readonly double _rate;

    // Naming this _rate prevents the classic bug: "1% tax" written
    // as 0.1 deducts ten times too much, and nothing will tell you.
    public TaxRule(double threshold, double rate)
    {
        _threshold = threshold;
        _rate = rate;
    }

    public double Apply(double salary) =>
        salary > _threshold ? salary - (salary * _rate) : salary;
}

public class SalaryCalculator
{
    private readonly IReadOnlyList<ISalaryRule> _rules;

    public SalaryCalculator(IReadOnlyList<ISalaryRule> rules) => _rules = rules;

    // Closed. A new rule is a new class and a line of configuration,
    // never an edit here.
    public double GetSalary(IEmployee employee) =>
        _rules.Aggregate(employee.Salary, (salary, rule) => rule.Apply(salary));
}

Provident fund next quarter? New class. Bonus for one department? New class. SalaryCalculator was tested once and stays tested.

The C++ trap that silently deletes your polymorphism

Worth a detour, because the same design in C++ has a way of failing that produces no error at all.

class Officer : Employee                        // trap 1
{
public:
    double getSalary() { return 50000; }
};

double SalaryCalculator::getSalary(Employee type)    // trap 2
{
    return type.getSalary();
}

Trap 1: class Officer : Employee is private inheritance. In C++, class defaults to private inheritance where struct defaults to public. Without the word public, Officer IS-A Employee only inside Officer, and the conversion the whole design depends on is not legal outside it.

Trap 2 is worse: taking the base class by value slices the object. Pass a Manager and C++ copy-constructs an Employee from it, keeping the base part and discarding everything that made it a Manager. type.getSalary() then calls Employee::getSalary. Every employee earns the base salary. The program compiles, runs, produces numbers, and the numbers are wrong.

Slicing punishes exactly the instinct that good design encourages: take the base type and let polymorphism sort it out. Polymorphism needs a reference or a pointer. Take a value and you have kept the shell and thrown away the object.

// By reference. Now the vtable survives the call.
double SalaryCalculator::getSalary(const Employee& employee)
{
    return employee.getSalary();
}

And virtual double getSalary(); with no body and no = 0 is not an abstract method. It is a promise to define it later. The compiler believes you and the linker does not. Pure virtual is = 0.

The honest caveat

OCP is the principle people most often take too far. You cannot be closed against every axis of change. Being open to new employee types cost nothing here. Being open to new salary rules cost an interface and an aggregation. Being open to everything costs a configuration language and a program nobody can read.

Wait until you have seen a change happen twice before building the seam for it. The first time, just edit the code.

Liskov Substitution Principle

If code works with a base type, it must keep working when handed any subtype, without knowing.

This is the least understood of the five, because most explanations reduce it to "a subclass should not remove methods". That is a symptom. Barbara Liskov's actual point is about behaviour: a subtype may not strengthen what it demands, nor weaken what it promises. A subclass that accepts less, or delivers less, than its base advertised has broken the contract even if every method is present and every signature matches.

The obvious violation

Animals eat, drink, run and fly:

public class Animal
{
    public virtual void Eat() { }
    public virtual void Drink() { }
    public virtual void Run() { }
    public virtual void Fly() { }     // the mistake is already here
}

Then a lion arrives. It eats, drinks, runs. It does not fly. Whatever you write in Lion.Fly is a lie: throw, and you break every caller holding an Animal; do nothing, and you have an animal that silently fails to fly. Neither is substitutable.

The base class is the problem. It promised something not every animal can keep. Common behaviour goes in the base, specific capabilities go in interfaces:

public abstract class Animal
{
    public abstract void Eat();
    public abstract void Drink();
}

public interface IRunnable { void Run(); }
public interface IFlyable  { void Fly(); }

public class Lion : Animal, IRunnable
{
    public override void Eat() => Console.WriteLine("Eats flesh");
    public override void Drink() => Console.WriteLine("Drinks water");
    public void Run() => Console.WriteLine("Runs fast");
}

public class Eagle : Animal, IFlyable
{
    public override void Eat() => Console.WriteLine("Eats flesh");
    public override void Drink() => Console.WriteLine("Drinks water");
    public void Fly() => Console.WriteLine("Flies high");
}

The trap: hiding is not overriding

There is a way to write this that looks correct and destroys substitutability without a single warning in C++:

class Animal
{
public:
    void Eat();      // not virtual
};

class Lion : public Animal
{
public:
    void Eat();      // this does NOT override. it HIDES.
};

Without virtual, Lion::Eat does not override Animal::Eat. It hides it. Which one runs is decided by the type of the reference, at compile time, not by the object:

Lion lion;
lion.Eat();                  // "Eat flesh"

Animal* animal = &lion;
animal->Eat();               // "Can eat"  <-- the SAME object

The same object gives two different answers depending on what you are holding it by. That is the precise opposite of substitutability, and nothing in the build will tell you.

C# is stricter and saves you here. Methods are non-virtual by default too, but hiding a base member without saying new is a compiler warning, and you cannot write override unless the base is virtual or abstract. The language makes you say which one you meant:

public class Lion : Animal
{
    public new void Eat() { }        // legal, explicit, and still almost always wrong
    public override void Eat() { }   // what you actually wanted
}

The violation no signature will catch

The animal example is really about missing capability, which is the easy case. Genuine LSP violations are quieter. The classic:

public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }
    public int Area => Width * Height;
}

// A square IS-A rectangle. Ask any mathematician.
public class Square : Rectangle
{
    public override int Width
    {
        get => base.Width;
        set { base.Width = value; base.Height = value; }   // keep it square
    }

    public override int Height
    {
        get => base.Height;
        set { base.Width = value; base.Height = value; }
    }
}

Every method is present. Every signature matches. It compiles. And this passes for Rectangle and fails for Square:

void ResizeAndVerify(Rectangle r)
{
    r.Width = 5;
    r.Height = 4;
    // Rectangle: 20. Square: 16, because setting Height also changed Width.
    Debug.Assert(r.Area == 20);
}

Nothing is missing. The behaviour differs, and the caller had no way to know. This is what Liskov was talking about, and it is why "IS-A" from the real world is a trap. A square is a rectangle in geometry. A mutable square is not a mutable rectangle, because the base's contract includes "setting one dimension leaves the other alone".

The practical rule: if a subclass overrides a method to throw, to do nothing, or to tighten what it accepts, the inheritance is wrong. Not the method. The inheritance.

Interface Segregation Principle

No client should be forced to depend on methods it does not use.

Make interfaces small, specific and cohesive. If a class implements an interface and half the methods throw, the interface is describing several things at once.

A smart device that prints, faxes and scans:

public interface ISmartDevice
{
    void Print();
    void Fax();
    void Scan();
}

The all-in-one is delighted. Then the cheap printer arrives:

public class EconomicPrinter : ISmartDevice
{
    public void Print() => Console.WriteLine("Yes I can print.");

    // Forced. These exist only to satisfy the compiler.
    public void Fax() => throw new NotSupportedException();
    public void Scan() => throw new NotSupportedException();
}

Those two throws are the interface telling you it is wrong. A type is publicly claiming a capability and then failing at run time, which also makes this an LSP violation: hand an ISmartDevice to code that faxes and it explodes. ISP violations usually arrive wearing an LSP violation.

Split it:

public interface IPrinter { void Print(); }
public interface IFax     { void Fax(); }
public interface IScanner { void Scan(); }

// Implements exactly what it can do.
public class EconomicPrinter : IPrinter
{
    public void Print() => Console.WriteLine("Yes I can print.");
}

// Still free to do everything.
public class AllInOnePrinter : IPrinter, IFax, IScanner
{
    public void Print() => Console.WriteLine("Printing.");
    public void Fax() => Console.WriteLine("Beep boop biiip.");
    public void Scan() => Console.WriteLine("Scanning.");
}

Now a method that needs to print takes IPrinter, both devices qualify, and nothing throws.

Two notes if you write this in C++. __interface is a Microsoft-specific extension, not standard C++; portable code uses a class with pure virtual functions and a virtual destructor. And throw new exception; throws a pointer. C++ throws by value and catches by reference; throw new leaks and is rarely caught by the handler you expected.

The judgement ISP needs: segregate by client, not by method. One interface per method is not the goal, and plenty of codebases read that way. If every caller who prints also scans, IPrintAndScan is a fine interface. Split when a real client needs a subset, not because a method count looked high.

Dependency Inversion Principle

High level modules should not depend on low level modules. Both should depend on abstractions.

And the half everyone forgets: abstractions should not depend on details. Details should depend on abstractions.

A Manager directs a Worker:

public class Worker
{
    public void DoWork() => Console.WriteLine("working...");
}

public class Manager
{
    private Worker _worker;
    public void SetWorker(Worker worker) => _worker = worker;
    public void ManageWorker() => _worker.DoWork();
}

Then a SuperWorker appears, and watch what it does to Manager:

public class Manager
{
    private Worker _worker;
    private SuperWorker _superWorker;

    public void SetWorker(Worker worker) => _worker = worker;
    public void SetWorker(SuperWorker worker) => _superWorker = worker;

    public void ManageWorker() => _worker.DoWork();
    public void ManageSuperWorker() => _superWorker.DoWork();
}

Manager has doubled for a change that has nothing to do with managing. Now imagine Manager is not this toy but a real class, with working time calculation and daily salary generation, half of it built on Worker. A third worker type arrives and you are editing the most valuable class in the system for a reason that is not its own.

Invert it. Put an abstraction between them and make both point at it:

public interface IWorker
{
    void DoWork();
}

public class Worker : IWorker
{
    public void DoWork() => Console.WriteLine("working...");
}

public class SuperWorker : IWorker
{
    public void DoWork() => Console.WriteLine("working much more");
}

public class Manager
{
    private readonly IWorker _worker;

    // Constructor injection: a Manager cannot exist without a worker,
    // and can never be handed a different one behind its back.
    public Manager(IWorker worker) => _worker = worker;

    public void ManageWorker() => _worker.DoWork();
}

A fourth worker type is a new class. Manager is untouched.

The word "inversion" is doing real work in that name, and the diagram above is the whole idea. Before, the arrow ran from Manager down to Worker: the important class depended on the replaceable one. After, both arrows point at IWorker. The low level module now depends on the high level module's requirements, which is the direction dependencies should run.

The half that gets missed

The interface belongs to the consumer, not the implementation. IWorker should live next to Manager and be shaped by what Manager needs. Put it in the same assembly as Worker, shaped like Worker, and you have added an interface without inverting anything: your abstraction now depends on the detail, which is exactly what the second half of the principle forbids.

That is the difference between dependency inversion and dependency injection. Injection is a technique for supplying a dependency. Inversion is about which side owns the contract. You can inject your way into a design that is still pointing the wrong way.

Prefer constructor injection over a setter. A settable SetWorker means Manager has a legal state where the worker is null, and every method must defend against it. Take it in the constructor and that state cannot exist. If you use a DI container, this is what it is for. If you do not, do it by hand; the container is a convenience, not the principle.

When not to do any of this

Every principle here trades a concrete cost now for flexibility later. An interface is a file, an indirection, and one more hop for whoever reads the code in six months. That trade is excellent when the change arrives and pure loss when it does not.

Things I have watched go wrong, more than once:

• An interface with exactly one implementation, forever. Named IThing for Thing, in the same folder, changed only ever together. That is not abstraction, it is a second file with the same information.
• SRP taken to atoms. Forty classes, each with one method, and no way to find where anything happens. Cohesion is a virtue too. SRP says one reason to change, not one line of code.
• OCP against changes that never came. A configurable rules engine for a rule that has not moved in four years, built because a rule might move.
• DIP as ceremony. Every class behind an interface, every interface registered in a container, a stack trace nobody can follow, in an application with one implementation of everything.

Martin said it himself: they are not laws, and they are not perfect truths. They are the accumulated experience of people who watched code rot in specific ways. They tell you what to do when the rot appears. Applied pre-emptively to everything, they produce a different kind of rot with better vocabulary.

The rule I would give anyone learning these: let the code ask. Write the switch. When it grows a third time, that is OCP asking for an interface, and now you know exactly which axis to open. Put the logic in the class. When two teams keep colliding in it, that is SRP asking for a seam, and now you know where. These principles are much better at recognising a problem than at predicting one.

The five, in one line each

• SRP: one actor may make you change this. Not one thing, one source of change.
• OCP: add a file, do not edit a tested one. Along the axis that actually changes.
• LSP: a subtype may not demand more or promise less. Matching signatures are not enough.
• ISP: nobody should implement what they cannot do. Segregate by client, not by method.
• DIP: both sides point at the abstraction, and the abstraction belongs to the consumer.

Learn them well enough to recognise which one a piece of code is failing, and you will get more out of them than any checklist can give you.

Thanks for your endurance.

Modern C# practices, real-world examples, and the design lessons every developer should know.

I first wrote this post in 2013. I have shipped a lot of C# since then, and rereading it I found two kinds of problem: code that would not survive contact with a real program, and advice that was true for Java rather than for C#. Both are fixed below. I have also stopped pretending that object orientation is a set of four words you memorise for an interview.

So this is the same journey, rebuilt: what an object actually is, why the philosophy matters more than the syntax, and how each idea looks in C# in 2026 rather than C# in 2008. The examples are the ones I have always used, because they still work.

Everything can be an object, and that is the least useful thing about it

Look around you. Computer, chair, table, pen. All objects, because each one has attributes and activities. A computer has a processor, RAM, a keyboard. It runs programs, displays information, accepts requests. Attributes and behaviour, bundled.

Fine. Now the part that took me years to actually understand.

An object's data and responsibilities depend entirely on the problem domain. Ask two engineers to model a "customer" and you will get two different answers. One gives you name, email, phone, and the ability to purchase and bargain. The other gives you first name, middle name, last name, gender, credit card, and the ability to open an account. Neither is wrong. One was thinking about a grocery store and the other about a bank.

This is why "is Name an attribute or an object?" has no answer in the abstract. In a banking system, Name is an attribute of Customer. In a business that sells names for newborn babies, Name is an object, because now it has meaning, length, origin, and popularity.

The lesson I would give my 2013 self: you are not modelling reality. You are modelling a problem. Reality is infinite and your program is not. Every attribute you add is a claim that your problem cares about it. Most of the bad class designs I have reviewed came from someone modelling the world instead of the requirement.

A class is a description, an object is an instance

A class describes objects that share attributes and behaviour. It is the blueprint. If Nashra, Maksura and Misha are students, then Student is the class and those three are objects.

Take a real requirement: "the user provides a first, middle and last name, and wants the full name and the reversed full name."

Read it and pull out the noun. There is one object here:

• Person: has a first name, a middle name, a last name. Can tell you its full name. Can tell you its reversed name.

In 2013 I wrote it like this, and I want to keep it visible because it is what most people write first:

namespace OOPWalkThrough1
{
    class Person
    {
        // Public fields. We will regret this in about four paragraphs.
        public string firstName;
        public string middleName;
        public string lastName;

        public string GetMyFullName()
        {
            return firstName + " " + middleName + " " + lastName;
        }

        public string GetMyReverseName()
        {
            string reverseName = "";
            string fullName = GetMyFullName();
            for (int index = fullName.Length - 1; index >= 0; index--)
            {
                reverseName += fullName[index];
            }
            return reverseName;
        }
    }
}

The data is represented by fields, the responsibilities by methods. Any object created from this class represents our domain Person. That much was right.

Two things were not. The public fields break encapsulation, which I admitted at the time and we will fix shortly. And GetMyReverseName builds a string by repeated concatenation inside a loop. Strings are immutable in .NET, so that loop allocates a brand new string on every single iteration. For a name it does not matter. For anything long it is quadratic, and I have profiled production code where exactly this pattern was the bottleneck.

Here is the same class as I would write it today:

namespace OopWalkthrough;

public sealed class Person
{
    // Auto-properties: the compiler writes the backing field.
    // Private set means the value is fixed once the object exists.
    public string FirstName { get; }
    public string MiddleName { get; }
    public string LastName { get; }

    public Person(string firstName, string middleName, string lastName)
    {
        // Validate at the boundary. An object should not be constructible
        // in a state it cannot honour.
        FirstName = firstName ?? throw new ArgumentNullException(nameof(firstName));
        MiddleName = middleName ?? string.Empty;
        LastName = lastName ?? throw new ArgumentNullException(nameof(lastName));
    }

    // A computed value with no side effects is a property, not a method.
    public string FullName => string.Join(' ', new[] { FirstName, MiddleName, LastName }
                                              .Where(part => !string.IsNullOrWhiteSpace(part)));

    // One allocation instead of one per character.
    public string ReverseName
    {
        get
        {
            var chars = FullName.ToCharArray();
            Array.Reverse(chars);
            return new string(chars);
        }
    }
}

Note sealed. My 2013 self left every class open to inheritance by default, because that felt generous. It is not generous, it is a promise. Sealing by default and opening deliberately is the habit I wish I had started with.

Separate the logic from the interface

This is the section that has aged best, so I am keeping the argument intact.

Most of us write a calculator like this the first time:

public partial class CalculatorUI : Form
{
    private void addButton_Click(object sender, EventArgs e)
    {
        double firstNumber = Convert.ToDouble(firstNumberTextBox.Text);
        double secondNumber = Convert.ToDouble(secondNumberTextBox.Text);
        double result = (firstNumber + secondNumber);
        resultTextBox.Text = result.ToString();
    }

    private void subtractButton_Click(object sender, EventArgs e)
    {
        double firstNumber = Convert.ToDouble(firstNumberTextBox.Text);
        double secondNumber = Convert.ToDouble(secondNumberTextBox.Text);
        double result = (firstNumber - secondNumber);
        resultTextBox.Text = result.ToString();
    }

    // ... and two more that are identical apart from one character
}

Now change it to a web application. Delete CalculatorUI.cs and your arithmetic goes with it, because the arithmetic never existed anywhere else. Every operator lives inside a button click handler. You would rewrite all of it. Scale that thought to an enterprise application and you can see the shape of a very bad quarter.

There is a second problem that is worse in the long run. If you want to add numbers somewhere else in the program, you rewrite the logic there. Now the same rule lives in two places, and one day someone fixes one of them.

So what did I actually do wrong? I mixed everything into CalculatorUI. A UI is responsible for displaying information and collecting it from the user. That is the whole job. I gave it a second job it was never suited for.

Refactor it. Take baby steps rather than a grand rewrite, because a grand rewrite is how refactors die. The four arithmetic operations suggest an object:

public class Calculator
{
    public double Add(double firstNumber, double secondNumber) => firstNumber + secondNumber;
    public double Subtract(double firstNumber, double secondNumber) => firstNumber - secondNumber;
    public double Multiply(double firstNumber, double secondNumber) => firstNumber * secondNumber;
    public double Divide(double firstNumber, double secondNumber) => firstNumber / secondNumber;
}

And the UI shrinks to what it should always have been:

public partial class CalculatorUI : Form
{
    private readonly Calculator _calculator = new();

    private void addButton_Click(object sender, EventArgs e)
    {
        var first = Convert.ToDouble(firstNumberTextBox.Text);
        var second = Convert.ToDouble(secondNumberTextBox.Text);
        resultTextBox.Text = _calculator.Add(first, second).ToString();
    }
}

Change to a web app now and you delete CalculatorUI only. Calculator is untouched. Need arithmetic elsewhere? Create the object and call it. The logic exists in exactly one place, which means it can be fixed in exactly one place.

Thirteen years later I would add one thing my original left out. Divide has a bug hiding in plain sight. It is a design decision disguised as a missing check: what should happen when secondNumber is zero? Doubles answer Infinity rather than throwing, so the UI cheerfully prints ∞. Deciding that is the calculator's job, not the button's. That is the real lesson of this section: when logic moves out of the UI, the questions it was hiding become visible.

Data hiding, constructors and properties

Data hiding restricts direct access to data. You reach it through a safe mechanism instead. A motorbike is the example I keep coming back to: you have no access to the piston. You press the start button, and the button controls the piston. If the manufacturer exposed the piston directly, controlling what happens to it would be impossible.

Which brings us back to the crime scene:

class Person
{
    public string firstName;    // anyone can write anything here
    public string middleName;
    public string lastName;
}

Make them private, and now nothing outside can touch them. So how does the UI read a name? In 2013 I wrote getters and setters:

public void SetFirstName(string firstName)
{
    this.firstName = firstName;
}

public string GetFirstName()
{
    return firstName;
}

Small correction to my old post, and it is embarrassing: it then showed personObject.GetFirstName("Nashra"); to set a value, and string firstName = personObject.GetFirstName; to read one. The first calls the getter with an argument. The second forgets the parentheses. Neither compiles. If you copied them and they failed, that was my fault, not yours.

The correct calls are:

personObject.SetFirstName("Nashra");
string firstName = personObject.GetFirstName();

But do not write this at all. Three attributes means six methods, and the class becomes noise. There is a better reason to avoid them than the typing: a method represents a responsibility. "GetFirstName" is not something a Person does. It is something you do to a Person. Modelling data access as behaviour makes the object look busier than it is. Use a property:

public class Person
{
    public string FirstName { get; set; }
    public string MiddleName { get; set; }
    public string LastName { get; set; }

    // Combinational data belongs in a get-only property, not a method.
    public string FullName => $"{FirstName} {MiddleName} {LastName}";
}

The rules I still use, unchanged since 2013 because they were right:

• If client code does not need the data, do not write a property for it. Keep it private.
• If the data should be read but not written, write get and no set.
• Computed values get a property with only a get. FullName, not GetMyFullName().

Modern C# adds one worth knowing. init lets a property be set during construction and never again, which gives you an immutable object without a constructor full of parameters:

public class Person
{
    public required string FirstName { get; init; }   // required: C# 11
    public string? MiddleName { get; init; }
    public required string LastName { get; init; }
}

var person = new Person { FirstName = "Nashra", LastName = "Maksura" };
// person.FirstName = "other";   // compile error: init-only

And if the type is nothing but data, a record says so in one line and gives you value equality for free:

public record Person(string FirstName, string? MiddleName, string LastName)
{
    public string FullName => $"{FirstName} {MiddleName} {LastName}";
}

Constructors

A constructor initialises an object when it is created, or does some initial work:

public Person(string firstName, string middleName, string lastName)
{
    this.firstName = firstName;
    this.middleName = middleName;
    this.lastName = lastName;
}

var personObject = new Person("Nashra", "Misha", "Maksura");

The point that deserves more weight than I gave it: a constructor is a contract that says what an object needs in order to exist. If Person cannot function without a first name, the constructor should demand one. Every optional constructor parameter is a state your class has promised to handle.

Overloading

Overloading allows several methods to share a name and differ by parameters. The bike again: Start has two forms, auto start and kick start. Same intent, different inputs.

Suppose the calculator must add three numbers. You could write AddThreeNumber, then rename the original to AddTwoNumber. Now your client sees five methods for four operations, and two of them do the same job with different arity. The object looks more complicated than it is.

public double Add(double firstNumber, double secondNumber);
public double Add(double firstNumber, double secondNumber, double thirdNumber);

Your client sees one Add. Similar responsibilities should share a name. The corollary matters more, and I did not say it in 2013: if two overloads do genuinely different things, giving them the same name is a lie. Overloading is for the same idea with different inputs, not for saving a word.

Constructor overloading follows the same rule, and constructors can chain so the logic lives once:

public Person() { }

public Person(string firstName, string lastName)
{
    this.firstName = firstName;
    this.lastName = lastName;     // note: the field, not the property
}

// ": this(...)" reuses the two-argument constructor instead of copying it
public Person(string firstName, string middleName, string lastName)
    : this(firstName, lastName)
{
    this.middleName = middleName;
}

One more correction. My original wrote this.LastName = lastName; in that middle constructor, mixing the property LastName with the field lastName. It happened to work only if a matching property existed. The convention that prevents this entire category of confusion: fields _camelCase, properties PascalCase, and then the two can never be mistaken for each other.

Static members, namespaces and access modifiers

Some data and behaviour belongs to the class rather than to any instance of it. That is what static means.

Consider a Trainee:

class Trainee
{
    public string name;
    public string id;
    public string email;
}

Name, id and email belong to each trainee. Now ask whether "number of trainees" is an attribute of a trainee object. It is not. No individual trainee has a number-of-trainees. The class does:

class Trainee
{
    public string name;
    public string id;
    public string email;

    // Belongs to the class, not to any one trainee.
    public static int numberOfTrainees;
}

Trainee.numberOfTrainees = 30;
int count = Trainee.numberOfTrainees;   // through the class, never through an object

The test I use: if the value would be the same no matter which instance you asked, it does not belong to the instance.

Now apply it to Calculator. Does it have data of its own? No. Every method takes its inputs as parameters and returns a result. It is a utility, so the methods can be static and callers never construct one:

public static class Calculator
{
    public static double Add(double firstNumber, double secondNumber) => firstNumber + secondNumber;
    public static double Subtract(double firstNumber, double secondNumber) => firstNumber - secondNumber;
    public static double Multiply(double firstNumber, double secondNumber) => firstNumber * secondNumber;
    public static double Divide(double firstNumber, double secondNumber) => firstNumber / secondNumber;
}

double result = Calculator.Subtract(firstNumber, secondNumber);

A static class forces every member to be static and cannot be instantiated.

An honest warning I owe you, having watched it happen. Static is convenient, and convenience is how it spreads. The moment a static class holds mutable state, you have global state: two tests interfere, two threads race, and nothing can be substituted for a fake. Static is right for Calculator precisely because it holds nothing. Add one static field and reconsider the whole design.

Static constructors

class Trainee
{
    static Trainee()
    {
        numberOfTrainees = 30;
    }

    public static int numberOfTrainees;
}

You cannot call a static constructor. The runtime runs it once, before the first instance is created or any static member is touched. It takes no access modifier and cannot be overloaded.

My old post asked "is it possible to use non-static members from static members?" and never answered. The answer is no, and the reason is worth more than the rule: a static member has no instance. There is no this for it to reach through. The question is not "is it allowed", it is "which object would it even mean?"

Namespaces

Namespaces are a logical grouping. They organise your application internally and prevent name collisions with other code. The .NET root namespace is System:

Namespace	Purpose
System.Windows.Forms	Classes for building Windows Forms applications
System.IO	Reading and writing data to files
System.Data	Data access
System.Web	Web Forms applications

A using directive tells the compiler where to look. Modern C# adds file-scoped namespaces, which remove one level of indentation from every file you will ever write:

namespace Contoso.Banking;   // no braces, applies to the whole file

public class Account { }

Access modifiers

Modifier	Access is limited to
public	Nothing. Any other class can reach it.
private	The containing type only.
internal	The same assembly.
protected	The containing class and types derived from it.
protected internal	The same assembly, or derived classes in any assembly.
private protected	Derived classes, but only within the same assembly. Added in C# 7.2.

Default to private and widen only when something outside genuinely needs it. Every public member is a promise you have to keep.

Inheritance

Inheritance lets you build a new class from an existing one and add to it. A bike manufacturer reuses the mechanism of last year's model and adds features, rather than starting from nothing.

In a banking domain you find Branch, Customer, Loan, all distinct. You also find Savings Account and Checking Account, which are not distinct at all. Both have an account number, a customer, a withdraw and a deposit. Savings has an interest amount. Checking has a service charge and a transaction count.

That shared part is an IS-A relationship, and IS-A is what inheritance means. Start with the base:

public class Account
{
    private string accountNumber;
    private double balance;

    public bool Deposit(double amount)
    {
        balance += amount;
        return true;
    }

    public bool Withdraw(double amount)
    {
        balance -= amount;
        return true;
    }
}

Then the subclass:

public class SavingsAccount : Account
{
    private double interestAmount;

    public double InterestAmount
    {
        get { return interestAmount; }
        set { interestAmount = value; }
    }
}

SavingsAccount now has everything public and protected that Account has, plus its own interest amount. It does not get accountNumber and balance, because those are private. Private means private to the containing type, and a subclass is a different type. This surprises people constantly.

So expose them from the base, and note that balance is read-only because only a transaction may change it:

public string AccountNumber
{
    get { return accountNumber; }
    set { accountNumber = value; }
}

public double Balance
{
    get { return balance; }     // no setter: changed by Deposit/Withdraw only
}

C# does not support multiple inheritance of classes. A class has exactly one base. Interfaces are how you get multiple contracts, and we will come to them.

Polymorphism

Polymorphism means the ability to take more than one form: the same operation behaving differently depending on the object. Overloading is one form of it. Overriding is the other, and it is the one that earns the name dynamic polymorphism, because the decision is made at run time.

Method overriding, and the bug in my original post

Change the requirement. Savings must keep a minimum balance of 1000. Checking may go to zero. Withdraw already lives in the base class, so how do we give Savings its own rule?

Mark the base method virtual, which means "a subclass may replace this":

public virtual bool Withdraw(double amount)
{
    balance -= amount;
    return true;
}

Then override it. And here is where my 2013 post was wrong in a way that would take your program down. It published this:

public override bool Withdraw(double amount)
{
    if (Balance - amount >= 1000)
    {
        return Withdraw(amount);   // BUG: this calls ITSELF, forever
    }
    return false;
}

The comment beside it said "use base class Withdraw method if condition is fulfilled". It does not. Inside an override, Withdraw(amount) resolves to the most derived implementation, which is the method you are already standing in. It calls itself, which calls itself, until the stack runs out and the process dies with a StackOverflowException that you cannot even catch in .NET.

The keyword you need is base. It means "the implementation I inherited", and it is the only way to reach past your own override:

public override bool Withdraw(double amount)
{
    if (Balance - amount >= MinimumBalance)
    {
        return base.Withdraw(amount);   // the inherited implementation
    }
    return false;
}

I am leaving the broken version visible rather than quietly correcting it, because the failure is instructive. It compiles. It passes review. It looks like it is delegating. It only fails when someone withdraws money, which is to say, in production. Infinite recursion through an override is one of the classic ways inheritance bites, and it bites precisely because the code reads as though it is doing the right thing.

To override, the signature must match the base exactly.

Using base constructors

Savings needs an account number and an interest rate. The direct version works:

public SavingsAccount(string accountNo, double interestRate)
{
    AccountNo = accountNo;              // via the base property
    this.interestRate = interestRate;
}

But the base should initialise its own data. Give Account a constructor:

public Account(string accountNo)
{
    this.accountNo = accountNo;
}

And chain to it:

public SavingsAccount(string accountNo, double interestRate)
    : base(accountNo)
{
    this.interestRate = interestRate;
}

Savings initialises only what it owns. The base initialises what it owns. That is the division of labour inheritance is supposed to give you.

Now a trap that catches everyone once. Add a parameterless constructor to Savings and Checking and the build breaks:

public SavingsAccount() { }    // compile error

The reason is not obvious from the message. A constructor that does not chain explicitly calls base() implicitly. Account used to have a parameterless constructor, but writing any constructor destroys the compiler-generated default one. So the implicit base() now refers to something that no longer exists. Give the base one back:

public Account() { }

Up-casting and down-casting

A subclass object can be held in a base class reference:

Account mySavingsAccount = new SavingsAccount();

That is up-casting. Two questions follow, and the answers are the heart of polymorphism.

Can you reach InterestRate through mySavingsAccount? No. The reference type is Account, so you see only what Account declares. The interest rate is there in memory; you just have no way to name it.

Which Withdraw runs, Savings or Account? Savings. This is the important one. The reference decides what you can call. The object decides what actually runs. That gap is the whole mechanism: your code speaks to an Account and the correct behaviour executes anyway.

Down-casting goes the other way, and it can fail:

// Old and dangerous: throws InvalidCastException if it isn't a SavingsAccount
var savings = (SavingsAccount)mySavingsAccount;

// Better: pattern matching. Asks and acts in one step.
if (mySavingsAccount is SavingsAccount s)
{
    Console.WriteLine(s.InterestRate);
}

One thing I would tell my younger self: if you find yourself down-casting often, the polymorphism is not doing its job. Every cast is you telling the compiler that you know better than the type system, and that is a bet you will eventually lose. The usual fix is a virtual method on the base, so the object answers instead of you asking what it is.

Encapsulation

Encapsulation means keeping behaviour and data together in one unit. The bike has actions (light, horn) and attributes (colour, weight), bundled into one thing. In code, methods and properties live together in an object.

The advantage is that the implementation is not accessible to the client. The user needs to know what the unit does and what to give it, and nothing else.

The one line to remember: encapsulation is not "make fields private and add properties". That is the mechanic, not the idea. A class with a private field and a public get/set pair for it has encapsulated nothing at all; it has just made the field's exposure take three lines instead of one. Encapsulation is when the object protects an invariant. Balance is a good example. It is get-only, and it changes only through Deposit and Withdraw, so the object can guarantee that money never appears from nowhere. That guarantee is the encapsulation. The property is just how it is spelled.

Interfaces

An interface is a contract. It states what to do, not how to do it. It declares the members an implementer will provide, and says nothing about how they work. Different classes can implement the same interface in dramatically different ways.

A Car might implement IDrivable. So might Truck, Aircraft, Train and Boat. The Driver has no idea which one it is holding. It knows the interface:

public interface IDrivable
{
    void GoForward(int speed);
}

public class Truck : IDrivable
{
    public void GoForward(int speed) { /* ... */ }
}

public class Aircraft : IDrivable
{
    public void GoForward(int speed) { /* ... */ }
}

Now, the part I have to correct. My 2013 post listed rules for interfaces that were Java's rules, not C#'s. I had been reading Java material and did not notice the language switch. If you learned any of these from me, please unlearn them:

• "Each variable declared in an interface must be assigned a constant value": wrong. A C# interface cannot declare fields at all. It declares methods, properties, events and indexers.
• "Every interface variable is implicitly public, static and final": that is Java. C# has no final keyword.
• "If a class implementing an interface does not implement all its methods, the class becomes an abstract class": that is Java again. In C# it is simply a compile error unless you explicitly declare the class abstract.

What is true in C#: members are implicitly public and cannot carry an access modifier; an interface may inherit other interfaces; and both classes and structs may implement any number of them. That last point is how C# gives you multiple inheritance of contract while refusing multiple inheritance of implementation, which is the ambiguity it was avoiding all along.

And one genuine change since I wrote the original. Since C# 8, an interface can carry a default implementation:

public interface IDrivable
{
    void GoForward(int speed);

    // Default implementation: implementers get this free, and may replace it.
    void Halt() => GoForward(0);
}

This exists mainly so a library can add a member to a published interface without breaking every implementer on earth. It is a versioning tool. Reaching for it as a way to share logic between classes usually means you wanted an abstract base class.

Abstract classes

An abstract class cannot be instantiated. It exists to be inherited. Usually one or more of its members is abstract, meaning declared but not implemented, which forces derived classes to supply the behaviour. A class can be abstract with no abstract members at all, and that is still useful: it says "this is a base, not a thing".

public abstract class Account
{
    private double balance;
    private string accountNo;

    public Account() { balance = 0; }
    public Account(string accountNo) { this.accountNo = accountNo; }

    public double Balance => balance;
    public string AccountNo => accountNo;

    public virtual bool Deposit(double amount)
    {
        balance += amount;
        return true;
    }

    public virtual bool Withdraw(double amount)
    {
        balance -= amount;
        return true;
    }
}

Here the class is abstract but nothing inside it is. The only difference from the non-abstract version is this:

Account accountObj = new Account();        // compile error: cannot instantiate
Account accountObj = new SavingsAccount(); // fine: up-casting still works

That is not a small difference. "Account" on its own is not a thing a bank has. It has savings accounts and checking accounts. Making the base abstract encodes that fact in the type system rather than in a comment.

Add an abstract member and you place a requirement on every subclass:

public abstract class Account
{
    private double balance;

    // No body. Every concrete subclass MUST answer this.
    public abstract double GetYearlyDeductionAmount();

    public double Balance => balance;
}

Savings and Checking must now implement GetYearlyDeductionAmount with their own logic. This is design guidance enforced by the compiler. When a Loan account arrives next year, the compiler tells the author exactly what they owe.

Interface or abstract class?

	Interface	Abstract class
Multiple inheritance	A class may implement many.	A class may extend only one.
Default implementation	Since C# 8, yes, but intended for versioning rather than code sharing.	Full code, default code, or abstract stubs that must be overridden.
State	No fields. Cannot hold state.	Fields, constructors and instance state, all available.
Homogeneity	Best when all the implementations share is a set of signatures.	Best when implementations are all of a kind and share status and behaviour.
Adding a member	Every implementer must supply it, unless you give it a default.	Provide a default implementation and existing code keeps working.

The way I actually decide, after years of getting it wrong in both directions:

Ask whether you are describing a capability or a kind. IDrivable is a capability. A Truck and an Aircraft have nothing in common except that both go forward, so an interface is right. Account is a kind. Savings and Checking share a balance, an account number and the meaning of a deposit, so an abstract class is right, because there is real state and real shared behaviour to inherit.

And when both fit, prefer the interface. It costs you the single inheritance slot you may need later, and it is the thing your tests can substitute.

What I would tell my 2013 self

The four words are the easy part. Encapsulation, inheritance, polymorphism, abstraction: you can memorise them in an afternoon and still design badly for years, which is roughly what I did.

The parts that took longer:

• Model the problem, not the world. Every attribute is a claim that your problem cares about it.
• Inheritance is the most over-used idea here. It couples a subclass to a base forever. Reach for it when there is a genuine IS-A and genuine shared state. Otherwise compose.
• Encapsulation is about protecting invariants, not about the ratio of private fields to public properties.
• Seal by default. Openness is a promise, and promises have to be kept.
• Check which language your rule came from. I published Java's interface rules under a C# heading and did not notice for years.

The examples in this post are the same ones I used thirteen years ago. They still teach the ideas, and the ideas have not changed. The code around them has, quite a lot, and it is better now, mostly because I have been wrong often enough to notice the patterns.

Thank you for staying with me. Best of luck.