Why SOLID is bad...
and everything Bob Martin says is highly suspicious
đź“ś Today's Menu
-
Principles, practices, and slogans
-
Why SOLID is bad
-
The two core principles of Agile
-
User-centric design
Code Metrics
Principle
A principle is a guiding truth that remains valid across tools, languages, and fads.
Principles are few, stable, and context-agnostic.
It describes why you act, not how.
Practice
A practice is a repeatable way of working that applies one or more principles.
Practices are tools, not truths.
It is situational and evolves with technology or culture.
Slogan
A slogan is a simplified statement that once hinted at a principle or practice but became detached from its rationale.
It’s often used as dogma instead of guidance.
What is SOLID?
SOLID is a group of five object oriented design principles coined by Robert C. Martin in the early 2000s and popularized by the software craftsmanship movement as a way to structure maintainable systems.
Single responsibility
- No one wants god classes
- What is a responsibility anyways?
- Why a single responsibility?
Reality check!
Keep classes small
Keep classes self-contained
Encapsulate properly
Every class should have only one responsibility
Open/Close
- No one cares about this
- And in any case it's just wrong
Reality check!
Class inheritance is usually not the way
Modifying classes is perfectly fine
Software entities should be open for extension, but closed for modification
Liskov
- Design by contract
- Irrelevant unless you have hierarchies
Reality check!
Why are you inheriting or implementing interfaces?
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
Interface Segregation
- No god interfaces
- No interfaces
- See single responsibility
Reality check!
Why are you inheriting or implementing interfaces?
Clients should not be forced to depend upon interfaces that they do not use
Dependency Inversion
- Every problem can be solved by another layer of abstraction
- Except the problem of too many layers of abstraction
Reality check!
The trade-off of adding abstractions and complexity versus keeping the code simple is a fundamental choice
Depend upon abstractions, not concretes
There is no empirical or peer-reviewed scientific evidence validating the SOLID principles as predictors of code quality, maintainability, or developer productivity.
What is SOLID?
Solid is a slogan.
Bob C. Martin
Bob Martin built a personal brand and consulting business around promoting SOLID. The principles are a cornerstone of his public persona, driving sales of training materials, speaking engagements, and corporate coaching under the “Uncle Bob” brand.
Actually...
Uncle Bob invented SOLID while making photocopier software:
- It was embedded code (hard to change)
- It was either C++ or Java
- It was a huge, slow enterprise environment
- It was a "plugin" system where everything derives from a single class
Principles
In a good codebase:
- It's cheap to add or change features
- It will be cheap next year, too
A good team:
- Is focused on delivering features fast
- Cleans up after themselves
- Makes itself faster
Simplicity
Don't add complexity
(abstractions, classes, interfaces,
tools, libraries, tests ...anything!)
that you don't need right now.
Remove complexity!
Simplicity–the art of maximizing the amount of work not done–is essential.
Cohesion
All code that you need to change should ideally live on a single screen.
Keep related logic together.
- Multiple locations add complexity
- Multiple files add complexity
- Multiple systems add complexity
Clean up
Can you make some code simpler? Go ahead, the future gain likely pays for it.
Implement new versions of frameworks, servers, libraries aggressively. Keep the technical debt down. Remember ESPx.
YAGNI
You ain't going to need it
DRY WET AHA
- Don't repeat yourself
- Write everything twice
- Avoid hasty abstractions
Some good practices
Anti-patterns
Known things which are bad™️
https://en.wikipedia.org/wiki/Category:Anti-patterns
Â
Code smells
Â
Things that should make you go: hmmmm
https://en.wikipedia.org/wiki/Code_smell
DB first design
Start from the data model, define tables and relationships, and let the database schema drive the structure of the code and API.
This approach ensures data integrity and performance are prioritized, but can constrain flexibility when business needs change quickly.
Class first design
Begin by modeling real-world concepts as classes, then derive persistence and APIs from that model.
It favors encapsulation and reuse, though it can drift toward abstraction and mismatch with how data actually lives in storage.
Test driven design
Write tests before writing code, allowing tests to define desired behavior and drive implementation.
It aims to improve design quality and maintainability, but often trades early clarity for ceremony when applied indiscriminately.
User-centric design
Design from the outside in: start with what the user needs to see and do, build the minimal interfaces to support it, and then backfill logic and data.
It optimizes for value and feedback speed rather than technical purity.
Why SOLID is bad and everything Bob Martin says is highly suspicious
By Marco Cecconi
