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
50
The best programmer I know
tastapod
PRO
2
310
How to bake a change
tastapod
PRO
0
510
The Most Dangerous Phrase
tastapod
PRO
7
6.2k
Rethinking Transformation
tastapod
PRO
1
400
CUPID - for joyful coding
tastapod
PRO
5
7.5k
agility at scale - a meeting of mindsets
tastapod
PRO
1
590
SWARMing into action
tastapod
PRO
0
390
Deliberate Advice
tastapod
PRO
3
1.5k
Other Decks in Technology
See All in Technology
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
110
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
2
280
PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025
shogogg
4
820
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
4
1.6k
セキュリティの民主化は何故必要なのか_AWS WAF 運用の 10 の苦悩から学ぶ
yoh
1
170
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
720
PostgreSQL 18 cancel request key長の変更とRailsへの関連
yahonda
0
120
Prox Industries株式会社 会社紹介資料
proxindustries
0
310
ひとり情シスなCTOがLLMと始めるオペレーション最適化 / CTO's LLM-Powered Ops
yamitzky
0
440
rubygem開発で鍛える設計力
joker1007
2
210
Agentic Workflowという選択肢を考える
tkikuchi1002
1
520
_第3回__AIxIoTビジネス共創ラボ紹介資料_20250617.pdf
iotcomjpadmin
0
160
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Statistics for Hackers
jakevdp
799
220k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.4k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
17
940
Site-Speed That Sticks
csswizardry
10
660
Embracing the Ebb and Flow
colly
86
4.7k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
VelocityConf: Rendering Performance Case Studies
addyosmani
330
24k
Adopting Sorbet at Scale
ufuk
77
9.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
930
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!