Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Why Every Element of SOLID is Wrong
Search
Daniel Terhorst-North
PRO
January 20, 2017
Technology
130
110k
Why Every Element of SOLID is Wrong
Five minute Ignite-style talk from PubConf London 2016
Daniel Terhorst-North
PRO
January 20, 2017
Tweet
Share
More Decks by Daniel Terhorst-North
See All by Daniel Terhorst-North
20 Years of BDD
tastapod
PRO
0
100
The best programmer I know
tastapod
PRO
3
400
How to bake a change
tastapod
PRO
1
560
The Most Dangerous Phrase
tastapod
PRO
7
6.3k
Rethinking Transformation
tastapod
PRO
1
420
CUPID - for joyful coding
tastapod
PRO
5
7.7k
agility at scale - a meeting of mindsets
tastapod
PRO
1
610
SWARMing into action
tastapod
PRO
0
400
Deliberate Advice
tastapod
PRO
3
1.5k
Other Decks in Technology
See All in Technology
オープンソースでどこまでできる?フォーマル検証チャレンジ
msyksphinz
0
140
PHPからはじめるコンピュータアーキテクチャ / From Scripts to Silicon: A Journey Through the Layers of Computing Hiroshima 2025 Edition
tomzoh
0
140
エンタメとAIのための3Dパラレルワールド構築(GPU UNITE 2025 特別講演)
pfn
PRO
0
310
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
3
5.5k
そのWAFのブロック、どう活かす? サービスを守るための実践的多層防御と思考法 / WAF blocks defense decision
kaminashi
0
200
ガバメントクラウド(AWS)へのデータ移行戦略の立て方【虎の巻】 / 20251011 Mitsutosi Matsuo
shift_evolve
PRO
2
200
綺麗なデータマートをつくろう_データ整備を前向きに考える会 / Let's create clean data mart
brainpadpr
3
510
いまからでも遅くない!SSL/TLS証明書超入門(It's not too late to start! SSL/TLS Certificates: The Absolute Beginner's Guide)
norimuraz
0
230
CoRL 2025 Survey
harukiabe
0
190
Claude Code Subagents 再入門 ~cc-sddの実装で学んだこと~
gotalab555
3
650
Introduction to Sansan Meishi Maker Development Engineer
sansan33
PRO
0
310
20251010_HCCJP_AdaptiveCloudUpdates
sdosamut
0
110
Featured
See All Featured
Being A Developer After 40
akosma
91
590k
Unsuck your backbone
ammeep
671
58k
GitHub's CSS Performance
jonrohan
1032
470k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
870
Java REST API Framework Comparison - PWX 2021
mraible
34
8.9k
Leading Effective Engineering Teams in the AI Era
addyosmani
5
420
Fireside Chat
paigeccino
40
3.7k
Scaling GitHub
holman
463
140k
jQuery: Nuts, Bolts and Bling
dougneiner
65
7.9k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Raft: Consensus for Rubyists
vanstee
140
7.1k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Transcript
Why Every Single Element of SOLID is Wrong! Dan North
@tastapod
Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion
Single Responsibility Principle “one reason to change” “only do one
thing”
Single Responsibility Principle What is a single responsibility anyway? ETL:
three responsibilities or one? How can you predict what is going to change? Pointlessly Vague Principle
Single Responsibility Principle Simple code is easy to reason about
Can easily do several related things Refactor until it Fits In Your Head Write simple code
Open-Closed Principle Open for extension, closed for modification “When requirements
change, extend behaviour by adding new code, not changing code that works”
Open-Closed Principle Open for extension, closed for modification “When requirements
change, the existing code is now wrong! so replace it with code that works” Cruft Accretion Principle
Open-Closed Principle Simple code is easy to change Simple code
is easy to test Simple code is both open and closed Write simple code!
Liskov Substitution Principle “Strong behavioural subtyping” Substitution with a subtype
preserves all “desirable properties” of the original type “Provably undecidable” but useful
Liskov Substitution Principle “There is nothing quite so useless, as
doing with great efficiency, something that should not be done at all.” Stuck in is-a and has-a modelling mindset Drucker’s Warning Principle
Liskov Substitution Principle What about acts-like-a, can-be-used-as-a? Composition is simpler
than inheritance Try to avoid object hierarchies altogether Write simple code!
Interface Segregation Principle Many small interfaces are better than one
big object Design small, role-based interfaces No client depends on methods it doesn’t use
Interface Segregation Principle Practically anything is better than one big
object Design small, role-based classes No client depends on methods it doesn’t use Stable Door Principle This is already true!! —>
Interface Segregation Principle Don’t write big objects in the first
place! Write code that Fits In Your Head If a class needs lots of interfaces, simplify the class! Write simple code!
Dependency Inversion Principle High-level modules should not depend on lower-level
modules Abstractions (e.g. interfaces) should not depend on details (e.g. concrete implementations)
Dependency Inversion Principle Reuse is overrated, design for use! DIP
leads to a different kind of dependency, dependency on DI frameworks! Wrong Goal Principle
Dependency Inversion Principle See how far you get combining simple
classes new is the new new! Assemble into small components that Fit In Your Head Write simple code!
Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion
Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Too
much to remember!
Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Write
simple code!