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
Clean Architecture
Search
Buzzvil
April 18, 2018
Programming
0
950
Clean Architecture
By Yohan
Buzzvil
April 18, 2018
Tweet
Share
More Decks by Buzzvil
See All by Buzzvil
220903_GFS
buzzvil
0
490
Git 해부하기 2 + 3
buzzvil
0
40
Metastable Failure
buzzvil
0
250
Git 해부하기
buzzvil
0
51
Introduction to Plate Solving
buzzvil
0
41
Airbnb Minerva
buzzvil
0
350
Shape up 방법론
buzzvil
0
970
Buzzvil Billing Data Pipeline
buzzvil
0
580
Journey of Dash's release-cycle
buzzvil
0
190
Other Decks in Programming
See All in Programming
意外と簡単!?フロントエンドでパスキー認証を実現する WebAuthn
teamlab
PRO
2
770
実用的なGOCACHEPROG実装をするために / golang.tokyo #40
mazrean
1
290
奥深くて厄介な「改行」と仲良くなる20分
oguemon
1
560
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
4
1.5k
複雑なフォームに立ち向かう Next.js の技術選定
macchiitaka
2
210
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
10
4.4k
Design Foundational Data Engineering Observability
sucitw
3
200
基礎から学ぶ大画面対応(Learning Large-Screen Support from the Ground Up)
tomoya0x00
0
3.3k
速いWebフレームワークを作る
yusukebe
5
1.7k
個人開発で徳島大学生60%以上の心を掴んだアプリ、そして手放した話
akidon0000
1
140
スケールする組織の実現に向けた インナーソース育成術 - ISGT2025
teamlab
PRO
1
160
Performance for Conversion! 分散トレーシングでボトルネックを 特定せよ
inetand
0
2.4k
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Navigating Team Friction
lara
189
15k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Git: the NoSQL Database
bkeepers
PRO
431
66k
4 Signs Your Business is Dying
shpigford
184
22k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Visualization
eitanlees
148
16k
Balancing Empowerment & Direction
lara
3
620
What's in a price? How to price your products and services
michaelherold
246
12k
The Language of Interfaces
destraynor
161
25k
Transcript
None
Clean Code - quick summary • Naming • Small functions
• Meaningful comments • Data abstraction • Error Handling • TDD(Unit Tests) • Building Systems
None
Goals At working at module level, software structure should •
Tolerate changes • Easy to understand • Basic components for reuse
Our Enemies • Rigidity - difficult to change • Fragility
- easy to break • Immobility - difficult to reuse • Viscosity - resistance against making changes
SOLID Principles • Single Responsibility • Open-closed • Liskov substitution
• Interface segregation • Dependency Inversion
Single Responsibility Principle (SRP) • A module should be responsible
to one, and only one, actor
SRP: Violation Employee -regularHours +calculatePay +reportHours +save Roy John Zune
SRP: Solution Employee Facade +calculatePay +reportHours +save PayCalculator +calculatePay HourReporter
+reportHours EmployeeSaver +save
Open-closed Principle • Open for extension but closed for modification
• Example with inheritance ◦ Bad ◦ Good
Liskov Substitution Principle • If for each object o1 of
type S, there is an object o2 of type T, such that, for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T
None
None
LSP Violation Rectangle +setHeight +setWidth Square +setSides User
Interface Segregation Principle (ISP)
ISP Violation Ops +ops0 +ops1 +ops2 User0 User1 User2
Dependency Inversion Principle • Source code should interact with abstractions,
not concretions • Stable vs volatile concrete elements
Takeaways • Consider actors in the system • Keep options
open with layers • Interact with abstractions over details