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
3
The best programmer I know
tastapod
PRO
2
220
How to bake a change
tastapod
PRO
0
460
The Most Dangerous Phrase
tastapod
PRO
7
6.1k
Rethinking Transformation
tastapod
PRO
1
360
CUPID - for joyful coding
tastapod
PRO
4
7.3k
agility at scale - a meeting of mindsets
tastapod
PRO
1
570
SWARMing into action
tastapod
PRO
0
380
Deliberate Advice
tastapod
PRO
3
1.5k
Other Decks in Technology
See All in Technology
Pwned Labsのすゝめ
ken5scal
2
410
Two Blades, One Journey: Engineering While Managing
ohbarye
4
1.9k
OCI Success Journey OCIの何が評価されてる?疑問に答える事例セミナー(2025年2月実施)
oracle4engineer
PRO
2
140
OSS構成管理ツールCMDBuildを使ったAWSリソース管理の自動化
satorufunai
0
640
OPENLOGI Company Profile
hr01
0
60k
入門 PEAK Threat Hunting @SECCON
odorusatoshi
0
150
AWSアカウントのセキュリティ自動化、どこまで進める? 最適な設計と実践ポイント
yuobayashi
7
540
システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling
i125
1
320
Cracking the Coding Interview 6th Edition
gdplabs
14
28k
Exadata Database Service on Cloud@Customer セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
2
1.5k
クラウド関連のインシデントケースを収集して見えてきたもの
lhazy
5
370
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
5
860
Featured
See All Featured
Facilitating Awesome Meetings
lara
52
6.2k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
Code Review Best Practice
trishagee
67
18k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Faster Mobile Websites
deanohume
306
31k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
Optimizing for Happiness
mojombo
376
70k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
370
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!