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
100k
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
How to bake a change
tastapod
PRO
0
240
The Most Dangerous Phrase
tastapod
PRO
7
5.8k
Rethinking Transformation
tastapod
PRO
1
280
CUPID - for joyful coding
tastapod
PRO
4
6.5k
agility at scale - a meeting of mindsets
tastapod
PRO
1
530
SWARMing into action
tastapod
PRO
0
360
Deliberate Advice
tastapod
PRO
3
1.3k
Governing Agile Delivery
tastapod
PRO
14
300
Complexity
tastapod
PRO
12
900
Other Decks in Technology
See All in Technology
LLM開発・活用の舞台裏@2024.04.25
yushin_n
1
340
長期間TiDBを使ってきた話 @ 私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT / Experiences with TiDB Over Time
chibiegg
2
900
反実仮想機械学習とは何か
usaito
PRO
11
4.7k
どうするコスト最適化のトレードオフ
tetsuyaooooo
1
530
ゼロから始めるVue.jsコミュニティ貢献 / first-vuejs-community-contribution-link-and-motivation
lmi
1
130
ServiceNow Knowledge 24の歩き方 EYストラテジー・アンド・コンサルティング
manarobot
0
200
EMとして2023年度に頑張ったこと / What we did well in FY2023 as a EM
pauli
1
170
AWSに詳しくない人でも始められるコスト最適化ガイド
yuhta28
1
250
エンジニアのキャリアをちょっと楽しくする3本の軸/Three Pillars to Make an Engineer's Career More Enjoyable
kwappa
0
2.7k
ChatGPT for IT Service Management (IT Pro)
dahatake
7
1.6k
GrafanaMeetup_AmazonManagedGrafanaのアクセス制御機能とマルチテナント環境下でのアクセス制御について
daitak
0
240
Azure Container Apps + Bicep 〜 こんな感じで運用しています
kaz29
2
480
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1025
450k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
244
20k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
125
32k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
17
1.4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
60
14k
How to Ace a Technical Interview
jacobian
272
22k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
241
1.2M
The Pragmatic Product Professional
lauravandoore
25
5.8k
Navigating Team Friction
lara
178
13k
Making the Leap to Tech Lead
cromwellryan
124
8.5k
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!