Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Why Every Element of SOLID is Wrong
Daniel Terhorst-North
PRO
January 20, 2017
Technology
127
92k
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
Rethinking Transformation
tastapod
PRO
1
44
CUPID - for joyful coding
tastapod
PRO
3
4.1k
agility at scale - a meeting of mindsets
tastapod
PRO
1
280
SWARMing into action
tastapod
PRO
0
280
Deliberate Advice
tastapod
PRO
3
1k
Governing Agile Delivery
tastapod
PRO
14
300
Complexity
tastapod
PRO
12
780
SWARMing
tastapod
PRO
25
2k
How to break the rules - Cucumber mix
tastapod
PRO
10
850
Other Decks in Technology
See All in Technology
2022年度新卒技術研修「良いコードの書き方」講義
excitejp
PRO
0
300
セキュリティ 開運研修2022 / security 2022
cybozuinsideout
PRO
3
3.6k
Meet passkeys
satotakeshi
0
100
アジャイル推進活動におけるBeAgileへの変化の兆し/Signs_of_Change_to_"Be_Agile"_in_Agile_Promotion_Activities
m_iyama
0
160
データエンジニアリングの潮流を俯瞰する
tetsuroito
1
720
Autonomous Database Cloud 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
10
18k
HoloLens2とMetaQuest2どちらも動くWebXRアプリをBabylon.jsで作る
iwaken71
0
190
マネージャーからみたスクラムと自己管理化
shibe23
0
1k
Design for Humans: How to make better modernization decisions
indualagarsamy
2
120
インフラのCI/CDはGitHub Actionsに任せた
mihyon
0
110
UWBを使ってみた
norioikedo
0
400
How to start with DDD when you have a Monolith
javujavichi
0
270
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
73
4.1k
The Straight Up "How To Draw Better" Workshop
denniskardys
225
120k
Streamline your AJAX requests with AmplifyJS and jQuery
dougneiner
126
8.5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
29
4.3k
A designer walks into a library…
pauljervisheath
196
16k
How GitHub Uses GitHub to Build GitHub
holman
465
280k
Visualization
eitanlees
124
11k
Optimizing for Happiness
mojombo
365
63k
Building Applications with DynamoDB
mza
83
4.7k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
224
49k
The Language of Interfaces
destraynor
148
20k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
151
13k
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!