【#1】責務を分けるだけでenumがスッキリした話（SOLIDのS）

導入

9/1 ~ 9/30にかけて、minimoの負債返済チームでインターンをしていました。

この記事では、その中で学んだことや、今後さらに深めていきたいことを短いチップス形式でまとめていきます。インターン中に気づいた「設計・実装の小さな学び」をテーマごとに投稿していく予定です。

今回は、画面状態を管理する enum を書いたときに、「責務が混ざっている」と気づいた話です。

責務を分ける前

enum AccountScreenState {
    case idle
    case checking
    case canCreate
    case cannotCreate
    case creating
    case success
    case failed(Error)
}

canCreate は「アカウント作成可否（ドメイン）」、

creating や failed は「画面の状態（UI）」です。

これらを分けたら、一気にスッキリしました👇

責務を分けた後

/// 画面の状態を管理する（UI表示に関する責務）
public enum ScreenState {
    case idle          // 何もしていない
    case loading       // 読み込み中
    case success       // 成功して結果を表示できる
    case failed(Error) // エラーが発生した
}

/// アカウント作成可否など、ビジネスロジックの状態を管理する（ドメイン責務）
public enum AccountAvailability {
    case unknown       // 状況不明（初期状態）
    case available     // アカウント作成可能
    case unavailable   // アカウント作成不可
}

学び

• enumでも**単一責任の原則（SRP）**を意識する
• 変更理由を1つにすると、UIとロジックの混線を防げる

• 「変更が他の動作に影響を与えないように、動作を分離することが大事
  → SOLID原則のS

【参考】イラストで理解するSOLID原則

まとめ

SOLID原則については聞いたことがあったのですが、実際に実装されているコードを見てそういうことなのかと理解することができました