SOLID Principles: The Physics of Software Architecture

Preventing Structural Entropy

If you build a bridge by welding every single beam directly to every other beam, the structure will tear itself apart under thermal expansion. Software is the same. "Code Rot" occurs when a system is so rigidly coupled that adding a new feature breaks three existing ones.

The SOLID principles are the engineering antidote to this entropy. They are the direct application of our core philosophy:

"Complexity is the enemy of scale. Abstraction is the art of hiding the complex inner workings of a system and providing a simple, intuitive interface for the user."

1. Single Responsibility Principle (SRP)

"A module should have one, and only one, reason to change."

In a data acquisition system, a Spectrometer class that reads hardware sensors, parses the raw byte stream, and saves the data to a database is a "God Class". It is doing too much. If the database schema changes, the Spectrometer class must be modified.

The Fix: Isolate the hardware reading, the data parsing, and the storage into three distinct, single-purpose modules.

2. Open/Closed Principle (OCP)

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

If you have a numerical integration loop, you should be able to add a new physical force (like Magnetic Drag) without altering the source code of the integrator itself. You achieve this by extending the system via Polymorphism and Interfaces, injecting new behaviors from the outside.

3. Liskov Substitution Principle (LSP)

"Subtypes must be perfectly substitutable for their base types."

If your system expects a ContinuousFunction interface, and you pass in a StepFunction that throws an error when evaluating at the discontinuity, you have violated LSP. The substitute must honor the mathematical and structural guarantees of the original contract. It cannot unexpectedly break the system's assumptions.

4. Interface Segregation Principle (ISP)

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

Avoid massive "God Interfaces." If you are defining components for an optical system, do not force a Mirror to implement an emitLight() method just because it shares a general OpticalDevice interface with a Laser. Keep your contracts small, focused, and mathematically precise.

5. Dependency Inversion Principle (DIP)

"High-level policy should not depend on low-level implementation. Both should depend on abstractions."

This is the pinnacle of abstraction. A spacecraft's NavigationController (High-Level) should never directly instantiate a HydraulicThruster (Low-Level). Instead, the controller should depend on an abstract ThrustProvider interface. The specific thruster is plugged in later. This completely decouples the navigation math from the physical hardware.

SOLID in Action: The Physics Integrator

Let's look at a system that violates these laws, followed by a system that obeys them.

{/* prettier-ignore */}

Now, we apply SRP (separating the logger), OCP (allowing infinite forces without changing the integrator), and DIP (the integrator depends on abstract forces, not hardcoded formulas).

{/* prettier-ignore */}

What You Have Learned

1. Entropy Prevention: Unmanaged code becomes infinitely complex. SOLID principles enforce boundaries that keep complexity localized.
2. Dependency Inversion: The core of scalable architecture. You plug hardware into the motherboard; the motherboard does not hardcode the hardware.
3. The Ultimate Abstraction: Adhering to SOLID naturally creates systems where the "inner workings" are hidden, and the interfaces remain perfectly simple.

In the next lesson: Creational Patterns — We know how objects should behave. Now we must learn the architectural patterns for efficiently manufacturing them in memory.