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
930
Clean Architecture
By Yohan
Buzzvil
April 18, 2018
Tweet
Share
More Decks by Buzzvil
See All by Buzzvil
220903_GFS
buzzvil
0
420
Git 해부하기 2 + 3
buzzvil
0
32
Metastable Failure
buzzvil
0
200
Git 해부하기
buzzvil
0
44
Introduction to Plate Solving
buzzvil
0
29
Airbnb Minerva
buzzvil
0
280
Shape up 방법론
buzzvil
0
900
Buzzvil Billing Data Pipeline
buzzvil
0
520
Journey of Dash's release-cycle
buzzvil
0
150
Other Decks in Programming
See All in Programming
個人アプリを2年ぶりにアプデしたから褒めて / I just updated my personal app, praise me!
lovee
0
340
Rails アプリ地図考 Flush Cut
makicamel
1
110
第3回 Snowflake 中部ユーザ会- dbt × Snowflake ハンズオン
hoto17296
4
360
sappoRo.R #12 初心者セッション
kosugitti
0
230
ファインディの テックブログ爆誕までの軌跡
starfish719
2
1.1k
chibiccをCILに移植した結果 (NGK2025S版)
kekyo
PRO
0
210
チームリードになって変わったこと
isaka1022
0
190
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
200
Bedrock Agentsレスポンス解析によるAgentのOps
licux
2
720
[Fin-JAWS 第38回 ~re:Invent 2024 金融re:Cap~]FaultInjectionServiceアップデート@pre:Invent2024
shintaro_fukatsu
0
400
iOSエンジニアから始める visionOS アプリ開発
nao_randd
3
120
Ruby on cygwin 2025-02
fd0
0
140
Featured
See All Featured
Statistics for Hackers
jakevdp
797
220k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
It's Worth the Effort
3n
184
28k
Speed Design
sergeychernyshev
25
780
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
51k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Fireside Chat
paigeccino
34
3.2k
Building Applications with DynamoDB
mza
93
6.2k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
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