#kosenconf_148onlineでの飛び入り参加のLTです

1. よい設計とは

2. 自己紹介
●
叶 弥悟
●
Twitter 鏡華 (@mirror_kt)
●
久留米工業高等専門学校 機械工学科 2 年
●
最近は限界開発鯖 (https://approvers.dev) とい
うコミュニティで開発しています

3. . よい設計とは何か
●
Pull Request の Review 時に設計に
ついて指摘することが多い気がして
きた
●
じゃあいい設計とはなんだという話
をしたいと思います

4. 単一責任の原則
●
各クラスが行う責務は 1 つに絞るべ
き、という原則

5. class GameManager {
fun startGame()
fun stopGame()
fun listGames(): List<Game>
fun drawText(gameId: UUID)
fun applyEffect(effectName: String)
}
いわゆる神クラス

6. 先ほどの例は、
●
ゲームその物の管理 ( 開始・終了 )
●
ゲーム全体の管理 ( ゲームの一覧 )
●
ゲームから利用する機能 ( エフェクト )
という責務がすべて GameManager に集まってい
るのが原因です
→ 責務ごとにクラスを分けてみましょう

7. class Game {
fun startGame()
fun stopGame()
}
class GameRegistry {
fun listGames()
}
class Effector {
fun applyEffect(effectName: String, target:
String): String
}

8. 責務の封印 ( カプセル化 )
●
あるクラスを使うとき、そのクラス
の内部の実装に依存するのは悪い設
計です

9. 先ほどの GameRegistry を例に出します
GameRegistry を使うクラスは、 GameRegistry
の「ゲームの一覧を保持する」「ゲームの一覧に
ゲームを追加・削除する」という機能に依存する
→ 機能に依存するのであって実装に依存するので
はない
GameRegistry がデータベースにゲームを保存して
ようがオンメモリだろうがファイルだろうが、使
う側は関係ない状態にするのが理想です

10. もし、 GameRegistry を使うクラスが DB のトラ
ンザクションを気にしなきゃいけない場合
DB を使っている、という内部実装が外に漏れ出
している
これを「責務の漏洩」という。

11. 依存方向
( 依存関係逆転の法則 )
相互依存するクラスが増えると、
機能の追加削除を行うのが難しくなる

12. Web バックエンドでよく使われる
3 層アーキテクチャ
●
アプリケーション層
●
ドメイン層
●
インフラ層
アプリケーション層 :
Web やモバイルといった、表示や入力に直接関わる部分
ドメイン層 :
プロジェクト固有の概念 ( ユーザーという概念やゲームという概念
など ) や、それらを利用したビジネスロジックを置く部分
インフラ層 :
データベースやファイルなどのインフラへのアクセスを提供する

13. 3 層アーキテクチャでは
サービス層はほかの層に
依存しない

14. サービス層は、
●
「データを受け取って」
●
「データを処理して」
●
「データを返す」
ことに専念する
どうやってデータをユーザーから受け取るか、ど
うやって表示するかは考えない
( アプリケーション層の役割 )

15. 前置きが長くなりましたが
依存関係逆転の法則です
ドメイン層はインフラ層にも依存しません
しかしファイルへの保存やデータベースへ
の保存は必要なはずです

16. ドメイン層で
「この機能が欲しい」
と宣言しておく (interface) ことで解決します
インフラ層はドメイン層で宣言された機能を実装
(= ドメイン層に依存する ) が、ドメイン層はドメ
イン層にある interface に依存する
→ ドメイン層はほかの層に依存しない
このように interface を間に挟むことで、ドメイン
層→インフラ層への依存関係をインフラ層→ドメ
イン層への依存関係にすることを「依存関係逆転
の法則」といいます

17. 結論
話長くなって申し訳ありません、き
れいなコードを書けるようになれば
幸いです