The SOLID principles—coined by Robert C. Martin—have long been gospel in object-oriented programming. Yet a growing contingent of engineers questions their universal applicability. A recent analysis dissects each principle, revealing startling conclusions: only one withstands scrutiny, one is obsolete, and three may actively harm code quality.

The Sole Survivor: Liskov Substitution

The Liskov Substitution Principle (LSP), formalized by Barbara Liskov in 1987, earns unequivocal endorsement:

"Subtype Requirement: Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T."

This mathematical foundation ensures substitutability without surprises—a cornerstone of sane type systems. As the critic notes:

"Anything you can observe about the base class remains true of its derived classes. That way you can pretend instances of the derived classes are also instances of the base class without any nasty surprise."

While languages like Java and C++ don’t enforce LSP, violating it remains a cardinal sin. Haskell’s type class laws embody this rigor, enabling optimizations like loop fusion.

The Obsolete: Open-Closed Principle

Bertrand Meyer’s 1988 Open-Closed Principle (OCP)—"software entities should be open for extension but closed for modification"—originated in an era where changing struct fields broke memory offsets and updating functions required manual call-site audits. Modern tooling negates these concerns:

// Pre-OCP mindset (1980s)
struct foo_old {
    uint32_t a;  // &foo + 0
    uint16_t b;  // &foo + 4
};

// Modern reality (offset-agnostic)
struct foo {
    uint32_t a;
    float x;     // New field added safely
    uint16_t b;
};

Compilers now flag call-site mismatches, and version control simplifies change management. Martin’s reinterpretation—"no one is allowed to make source code changes to [modules]"—is deemed extreme, leading to needless abstraction layers. The core reduces to Linus Torvalds’ mantra: "WE DO NOT BREAK USERSPACE."

The Questionable Trio

  1. Single Responsibility Principle (SRP):
    Martin’s definition—"a class should have only one reason to change"—conflicts with practical design. High cohesion matters more than artificial fragmentation. As the critique states:

    "We don’t want functions small, we want them deep: small interface with significant implementation."
    Overzealous SRP application produces "functions so small some take more characters to call than to copy & paste."

  2. Interface Segregation Principle (ISP):
    The premise—"no code should be forced to depend on methods it does not use"—misdiagnoses dependency management. Bloated interfaces signal poor depth, but ISP’s solution (splitting interfaces) often overlooks root causes. Recompilation costs, cited as justification, reflect tooling deficiencies rather than design flaws.

  3. Dependency Inversion Principle (DIP):
    Mandating that "high-level modules depend on abstractions, not concretions" systematically introduces indirection. A file-copy example demonstrates how DIP transforms simple code:

// Without DIP
class Copy {
    ReadKeyboard reader;
    WritePrinter writer;
    // Logic directly uses concretions
};

// With DIP
class Copy {
    Reader& abstractReader;  // Injected abstraction
    Writer& abstractWriter;  // Adds boilerplate
};

The verdict? "Rarely needed." Polymorphism should solve actual problems—like supporting multiple runtime implementations—not anticipate hypothetical changes.

The Path Forward

  • Embrace LSP religiously for type safety
  • Discard OCP as a historical relic
  • Prioritize depth over SRP/ISP dogma: small interfaces with rich functionality
  • Avoid DIP unless dependency flexibility proves necessary

As the analysis concludes:

"Don’t plan for a change you cannot anticipate. Keep your program short and simple. When change comes (it always does), you’ll have a simpler program to modify."

This critique challenges developers to reject ritualistic SOLID adherence in favor of contextual judgment—valuing simplicity and maintainability over architectural theater.

Source: Loup Vaillant's SOLID Deconstruction