Constructing a SOLID Software Foundation

by

SOLID Principles of Software Development: The Construction Site Analogy

Building software is much like managing a major construction project. To ensure a structure is safe, scalable, and easy to maintain, architects and engineers follow strict sets of rules. Without good planning and adherence to industry standards, a building risks structural failure; similarly, in software, we use the SOLID principles to prevent “code rot” and ensure our project doesn’t collapse under its own weight as it grows.

Here are the five principles we will be exploring through the lens of a typical construction site:

1. Single Responsibility Principle (SRP)

Focus: One job, one person.

On a construction site, you wouldn’t ask a painter to operate a 20-ton excavator, nor would you expect a heavy machine operator to handle the delicate finishing touches of interior trim.

Each worker has a single responsibility. If the machine operator starts painting, they are likely to do a poor job, and they aren’t available to dig the foundation. In software, a class should have only one reason to change. If a class handles both database logic and UI rendering, a change in how you store data shouldn’t risk breaking how the user sees the screen.

The following C# example demonstrates how we separate these concerns into distinct, specialized classes:

// The HeavyMachineOperator has one reason to change: Changes in heavy machinery operation logic.
public class HeavyMachineOperator
{
    public void OperateExcavator()
    {
        Console.WriteLine("HeavyMachineOperator: Digging the foundation trenches...");
    }

    public void MoveEarth()
    {
        Console.WriteLine("HeavyMachineOperator: Clearing site debris and leveling soil.");
    }
}

// The Painter has one reason to change: Changes in painting or finishing techniques.
public class Painter
{
    public void ApplyPrimer()
    {
        Console.WriteLine("Painter: Applying high-grip primer to the walls.");
    }

    public void PaintRoom(string color)
    {
        Console.WriteLine($"Painter: Applying two coats of {color} paint.");
    }
}

2. Open/Closed Principle (OCP)

Focus: Extension without demolition.

An excavator is a versatile machine because its arm is designed for extension. The machine itself is “closed” to modification—you don’t weld new parts onto the engine every time you need a new function. Instead, it is “open” to new attachments. Whether you use a bucket for digging, a hydraulic hammer for breaking rocks, or a new grapple for lifting logs, you simply swap the attachment without rebuilding the excavator.

// The Interface defines what an attachment MUST do
public interface IExcavatorAttachment
{
    void PerformAction();
}

// Existing attachments
public class BucketAttachment : IExcavatorAttachment
{
    public void PerformAction() => Console.WriteLine("BucketAttachment: Scooping and moving soil.");
}

public class HammerAttachment : IExcavatorAttachment
{
    public void PerformAction() => Console.WriteLine("HammerAttachment: Breaking through concrete and rock.");
}

// We can add a NEW Grapple attachment without changing the Excavator class
public class GrappleAttachment : IExcavatorAttachment
{
    public void PerformAction() => Console.WriteLine("GrappleAttachment: Grasping and lifting heavy logs.");
}

public class ExcavatorArm
{
    public void AttachAndWork(IExcavatorAttachment attachment)
    {
        Console.WriteLine("ExcavatorArm: Securing attachment to the arm...");
        attachment.PerformAction();
    }
}

3. Liskov Substitution Principle (LSP)

Focus: Interchangeable parts.

If you are building a wall with “Standard Bricks,” you should be able to swap one brand of standard brick for another without the wall falling down. In software, a subclass should be able to replace its parent class without breaking the application.

To satisfy LSP, a subclass must adhere to the contract and behavior promised by the parent class. If a subclass “refuses” to perform a behavior that the parent promised (violating the base class’s expectations), it is no longer a valid substitute. Below is an example of a broken implementation where a GlassBrick fails to act like a load-bearing Brick.

public class Brick
{
    public virtual void SupportWeight() 
    {
        Console.WriteLine("Brick: Supporting 500kg of structural load.");
    }
}

// This follows LSP: It can replace a standard brick perfectly.
public class ReinforcedBrick : Brick
{
    public override void SupportWeight() 
    {
        Console.WriteLine("ReinforcedBrick: Supporting 1000kg with steel cores.");
    }
}

// BROKEN IMPLEMENTATION (LSP VIOLATION)
// A GlassBrick is technically a "Brick", but it cannot support weight.
public class GlassBrick : Brick
{
    public override void SupportWeight()
    {
        // Violating LSP: Code expecting a 'Brick' will CRASH here.
        // A substitute should not throw new exceptions for base behaviors.
        throw new InvalidOperationException("Glass bricks are decorative and will shatter under load!");
    }
}

// Structural Load Test: This method expects ANY brick to be load-bearing.
public void BuildFoundation(List<Brick> materials)
{
    foreach (var brick in materials)
    {
        // If a GlassBrick is in this list, the whole construction process crashes.
        brick.SupportWeight(); // <-- Runtime Error occurs here for GlassBrick
    }
}

4. Interface Segregation Principle (ISP)

Focus: Acquiring specific skills, not a universal burden.

On a site, you shouldn’t be forced to obtain a “Master Construction License” (covering plumbing, electrical, and painting) just to be allowed to paint a single wall. It is better to have specific certifications for each trade.

This allows for composition. A junior worker can hold a single specific license, while a seasoned veteran like a Site Foreman can hold multiple licenses. By keeping these “interfaces” small, the junior isn’t burdened with management responsibilities they aren’t trained for, yet the senior member can still perform both roles legitimately.

// Specific, segregated interfaces (Specific Trade Licenses)
public interface IPainterTrade { void PaintWall(); }
public interface IForemanRole { void SignOffWork(); void ManageSchedule(); }

// The Junior: A worker who is only certified for one specific trade.
public class JuniorPainter : IPainterTrade
{
    public void PaintWall() => Console.WriteLine("JuniorPainter: Carefully applying paint.");
}

// The Senior: Qualified for management AND skilled in the trade.
// This class implements BOTH interfaces.
public class SiteForeman : IForemanRole, IPainterTrade
{
    public void PaintWall() => Console.WriteLine("SiteForeman: Painting the complex feature wall.");
    
    public void SignOffWork() => Console.WriteLine("SiteForeman: Inspecting site and signing safety logs.");
    
    public void ManageSchedule() => Console.WriteLine("SiteForeman: Updating the project timeline.");
}

// The benefit: We can ask for JUST a painter without needing a foreman.
public void FinishInterior(IPainterTrade worker)
{
    // Both the JuniorPainter and the SiteForeman can be passed here!
    worker.PaintWall();
}

5. Dependency Inversion Principle (DIP)

Focus: Hiring for the skill, not the person.

High-level modules should not depend on low-level modules; both should depend on abstractions. Crucially, the high-level module should define the abstraction it needs. In construction, the Excavator (the high-level tool) defines the standard control layout; it doesn’t care which specific person is in the cab, so long as they can operate those specific controls.

Instead, the Excavator depends on the Interface of a “Machine Operator.” As long as the person assigned to the cab knows how to follow the standard controls, the machine can do its job.

// The Abstraction: The Excavator defines the controls it requires
public interface IMachineOperator
{
    void Work();
}

// Low-level Implementation
public class JoeBucketSpecialist : IMachineOperator
{
    public void Work() => Console.WriteLine("JoeBucketSpecialist: Operating the bucket.");
}

// Low-level Implementation
public class PeteHydraulicHammerSpecialist : IMachineOperator
{
    public void Work() => Console.WriteLine("PeteHydraulicHammerSpecialist: Operating the hammer.");
}

// High-level Module: The Excavator depends on the interface (the license)
public class Excavator
{
    private readonly IMachineOperator _operator;

    public Excavator(IMachineOperator machineOperator)
    {
        _operator = machineOperator;
    }

    public void StartShift()
    {
        Console.WriteLine("Excavator: Engine started...");
        _operator.Work();
    }
}

Leave a Comment