DEV Community

Cristian Sifuentes
Cristian Sifuentes

Posted on

6 - SOLID Revisited — A Post-Pattern Perspective

#backend #csharp #dotnet #architecture

SOLID Revisited — A Post-Pattern Perspective <br> *Why the principles matter less than the forces behind them*

SOLID Revisited — A Post-Pattern Perspective

Why the principles matter less than the forces behind them

SOLID is not a checklist.

It is a historical compression of deeper forces.

This is Part 6 of the series:

  1. Classes in C#: From First Principles to Architectural Mastery
  2. Abstract Class vs Interface — A Systems View
  3. Composition vs Inheritance — The Physics of Change
  4. Encapsulation & Information Hiding — Designing for Ignorance
  5. Polymorphism — Designing for Substitution, Not Reuse
  6. SOLID Revisited — A Post-Pattern Perspective

This article assumes you already know SOLID.

Our goal is to understand why it exists, when it breaks, and what remains when patterns fade.

The Problem With Teaching SOLID as Rules

Most developers learn SOLID as five independent commandments:

  • Single Responsibility
  • Open/Closed
  • Liskov Substitution
  • Interface Segregation
  • Dependency Inversion

They are taught as:

  • static rules
  • local code checks
  • refactoring heuristics

But SOLID was never meant to be used that way.

SOLID is an emergent description of systems under change.

SOLID Is About Change, Not Code

Every SOLID principle exists to answer one question:

“Where does change land — and how far does it spread?”

SOLID is not about beauty.
It is about damage control.

S — Single Responsibility Principle

(Actually: Single Reason to Change)

SRP is not about “small classes”.

It is about separating reasons for change.

public class ReportService
{
    public void Generate() { }
    public void SaveToDisk() { }
    public void SendEmail() { }
}
Enter fullscreen mode Exit fullscreen mode

This class has:

  • one responsibility (reports)
  • three reasons to change

SRP is violated when organizational boundaries overlap.

SRP is about who asks for changes, not how big the class is.

O — Open/Closed Principle

(Designing for Extension Without Coordination)

OCP exists to reduce coordination cost.

public interface IDiscountPolicy
{
    decimal Apply(decimal price);
}
Enter fullscreen mode Exit fullscreen mode

New behavior appears as new code, not modified code.

The real benefit:

  • no meetings
  • no merge conflicts
  • no fear of breaking others

OCP is a social scaling principle.

L — Liskov Substitution Principle

(Preventing Semantic Drift)

LSP is not about inheritance syntax.

It is about meaning preservation.

Stream s = new MemoryStream();
Enter fullscreen mode Exit fullscreen mode

This works because:

  • expectations remain valid
  • semantics are preserved

If behavior surprises callers, LSP is broken — even if the compiler is happy.

LSP protects trust in abstractions.

I — Interface Segregation Principle

(Minimizing Cognitive Load)

ISP exists because humans are the bottleneck.

public interface IWorker
{
    void Work();
    void Eat();
}
Enter fullscreen mode Exit fullscreen mode

Not all workers eat.

ISP is violated when:

  • implementers are forced to care about things they don’t need
  • understanding requires reading unrelated methods

ISP optimizes for mental bandwidth, not runtime.

D — Dependency Inversion Principle

(Reversing the Flow of Volatility)

DIP is the keystone of SOLID.

High-level policy should not depend on low-level detail.

public class OrderService
{
    public OrderService(IPaymentGateway gateway) { }
}
Enter fullscreen mode Exit fullscreen mode

The direction of dependency is reversed:

  • stable code depends on stable abstractions
  • volatile code hangs off the edges

DIP is about protecting the core.

SOLID as a Force Diagram

Principle Primary Force Controlled
SRP Organizational change
OCP Coordination cost
LSP Semantic stability
ISP Cognitive load
DIP Volatility direction

SOLID works when these forces matter.

When SOLID Becomes Harmful

SOLID fails when:

  • applied mechanically
  • enforced prematurely
  • optimized locally instead of systemically

Examples:

  • Interface-per-class explosion
  • Over-abstracted domains
  • “Because SOLID says so” code

This is cargo-cult architecture.

Post-Pattern Thinking

Patterns and principles are maps, not territory.

In mature systems:

  • constraints matter more than patterns
  • forces matter more than rules
  • evolution matters more than elegance

SOLID fades into the background —

and what remains is intentional design.

The Unifying Mental Model

SOLID minimizes the surface area of change.

That’s it.

If a design reduces:

  • blast radius
  • coordination
  • surprise
  • fear

It is SOLID — even if it breaks a textbook rule.

Final Takeaway

Junior developers ask:

“Is this SOLID?”

Senior engineers ask:

“What happens when this changes?”

That question contains all five principles.

✍️ Cristian Sifuentes

.NET / C# • Architecture • Systems Thinking

Principles don’t scale systems.

Understanding forces does.

Top comments (0)