Why Every Element of SOLID is Wrong (original) (raw)
Why Every Element of SOLID is Wrong
Search
Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers. → 
Daniel Terhorst-North January 20, 2017
110k
Five minute Ignite-style talk from PubConf London 2016
Daniel Terhorst-North PRO
January 20, 2017
More Decks by Daniel Terhorst-North
See All by Daniel Terhorst-North
tastapod0
33
1
16
0
170
3
510
2
660
7
6.4k
1
510
5
8.1k
agility at scale - a meeting of mindsets
1
650
Other Decks in Technology
mot_techtalk3
180
非エンジニアがClaudeと挑んだ「1ヶ月間プロダクト30本ノック」
askokc0
140
AIソロプレナー時代に2ヶ月で20人増員した事業創造会社の開発組織の話
miyatakoji0
260
AIを「創る」と「使う」の循環 — HRテックが実践するリアルなAI組織実装
taketo9570
1.8k
AI Adaptable なテストを整える工夫 / Ways to Make Your Tests AI-Adaptable
bitkey3
230
関西に縁あるMicrosoft MVPsが語るCopilotの未来
kasada0
1.2k
AI Testing Talks: Challenges of Applying AI in Software Testing: From Hype to Practical Use
exactpro1
140
探して_入れて_作って_使う_Agent_Skills___LT.pdf
peintangos2
180
ITエンジニアを取り巻く環境とキャリアパス / A career path for Japanese IT engineers
takatama4
1.8k
生成 AI × MCP で切り拓く次世代 SRE！自律型運用への挑戦と開発者体験の進化
_awache0
170
hayama172
220
Building applications in the Gemini API family.
line_developers_tw0
2.3k
Featured
Designing for humans not robots
tammielis254
26k
Agile that works and the tools we love
rasmusluckow331
21k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri2
210
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz37
6.5k
The Art of Programming - Codeland 2020
erikaheidi57
14k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai65
55k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda1
2k
Into the Great Unknown - MozCon
thekraken41
2.6k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen1
720
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek16
2k
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct2
390
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag254
22k
Transcript
@tastapod
2. ### Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion
3. ### Single Responsibility Principle “one reason to change” “only do one
thing”
4. ### 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
5. ### 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
6. ### Open-Closed Principle Open for extension, closed for modification “When requirements
change, extend behaviour by adding new code, not changing code that works”
7. ### 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
8. ### 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!
9. ### Liskov Substitution Principle “Strong behavioural subtyping” Substitution with a subtype
preserves all “desirable properties” of the original type “Provably undecidable” but useful
10. ### 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
11. ### 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!
12. ### 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
13. ### 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!! —>
14. ### 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!
15. ### 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)
16. ### Dependency Inversion Principle Reuse is overrated, design for use! DIP
leads to a different kind of dependency, dependency on DI frameworks! Wrong Goal Principle
17. ### 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!
18. ### Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion
19. ### Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Too
much to remember!
20. ### Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Write
simple code!
