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
クリーンアーキテクチャ をGoでする場合に不要な Interfaceは消しやがれ
Search
garebare
June 17, 2022
Programming
0
110
クリーンアーキテクチャ をGoでする場合に不要な Interfaceは消しやがれ
6月17日に行われたNEWDEBUG!!!!で発表した史料です。
https://caspur.wintu.dev/front/lives/264
garebare
June 17, 2022
Tweet
Share
More Decks by garebare
See All by garebare
ペンギンをおすすめする
garebareda
0
27
hey-techcamp-2022
garebareda
2
57
Rustで作った自作コマンド群の話
garebareda
0
140
自作Git作った話
garebareda
3
650
Rustで自作言語のインタプリタ作って Webで動くようにした話
garebareda
0
740
Vtuberをやりたくなりました
garebareda
1
68
Other Decks in Programming
See All in Programming
生成AIでGitHubソースコード取得して仕様書を作成
shukob
0
540
わたしの星のままで一番星になる ~ 出産を機にSIerからEC事業会社に転職した話 ~
kimura_m_29
0
210
nekko cloudにおけるProxmox VE利用事例
irumaru
3
460
これでLambdaが不要に?!Step FunctionsのJSONata対応について
iwatatomoya
2
3.8k
各クラウドサービスにおける.NETの対応と見解
ymd65536
0
190
rails stats で紐解く ANDPAD のイマを支える技術たち
andpad
1
300
コンテナをたくさん詰め込んだシステムとランタイムの変化
makihiro
1
150
技術的負債と向き合うカイゼン活動を1年続けて分かった "持続可能" なプロダクト開発
yuichiro_serita
0
160
Monixと常駐プログラムの勘どころ / Scalaわいわい勉強会 #4
stoneream
0
290
どうして手を動かすよりもチーム内のコードレビューを優先するべきなのか
okashoi
3
630
Androidアプリのモジュール分割における:x:commonを考える
okuzawats
1
210
「Chatwork」Android版アプリを 支える単体テストの現在
okuzawats
0
180
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
810
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Agile that works and the tools we love
rasmusluckow
328
21k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Done Done
chrislema
182
16k
Music & Morning Musume
bryan
46
6.2k
The World Runs on Bad Software
bkeepers
PRO
66
11k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Building Adaptive Systems
keathley
38
2.3k
GraphQLとの向き合い方2022年版
quramy
44
13k
Optimizing for Happiness
mojombo
376
70k
Transcript
クリーンアーキテクチャを Goでする場合に不要な Interfaceは消しやがれ @garebare521
By たふみ神
ということで考えて行こうと思います
クリーンアーキテクチャとは
Entity UseCase Cotroller UI DB
なんかこういうやつ!
Interfaceで依存を逆転させてるらしい
実装例 type Hoge struct { … } type HogeUsecase struct
{ … } type HogeRepository struct { …. } type Hoge Controller struct { … }
実装例 hogeRepo:=NewHogeRepository() hogeUse :=NewHogeUsecase(hogeRepo) hogeCtrl := NewHogeCtroller(hogeUse)
実装例 hogeCtrl.Post () hogeUse.Post () HogeRepo.Insert()
Interfaceなしだと モックが作れないので テストし難い
Interface書くしかない
クリーンアーキテクチャを Goでする場合に不要な Interfaceは消しやがれ
じゃあどうするか
とりあえず実装量が少なそうな UseCase層を取り除く
Entity UseCase Cotroller UI DB
Entity Cotroller UI DB
単純にインターフェースを削除すると テストが破綻する
テストしやすい形にしたい
じゃあもう実態持たせる必要なくない?
Entity UI DB Controller
Entity UI DB Controller こうしたい
実態を持たせずに Interfaceと同じようなことをしたい
関数を引数に渡せばよくね????
関数を渡すようにするとテストも書きやすい
HogeController func (c *hogeCtrl) Post(c Context, insert func(hoge Hoge) (error))
{ insert() } hogeCtrl.Post(c, hogeRepo.insert)
関数の引数をInterface代わりにして 解決!
ただ必要な関数が増えるたびに 引数も増えます