導入
実務で複雑なドメインモデルを扱う際、いつの間にか「この状態とこの状態は同時に存在してはいけないはずなのに、データ構造上は作れてしまう」といった問題に直面したことはありませんか？データ定義における「直交性」を意識することで、不正な状態を排除し、テスト容易性が高く、かつパターンマッチがスッキリと記述できる堅牢なコードを構築できます。
基礎知識
直交性とは、本来独立しているべき要素が互いに影響を及ぼさない性質を指します。関数型プログラミングにおけるデータ定義（代数的データ型）において、各コンストラクタが「唯一の独立した状態」のみを表現しているとき、そのデータ構造は直交性が高いと言えます。逆に、一つの型の中に「無関係なフラグ」や「null許容のフィールド」が混在している状態は直交性が低く、それらの組み合わせの数だけ考慮すべきケース（状態空間）が爆発してしまいます。
実装/解決策
直交性を高めるための鍵は「状態の列挙」です。
例えば、ユーザーの認証状態を定義する場合、`isLoggedIn`というフラグと`userName`というフィールドを別々に持つのではなく、認証されている状態とされていない状態を別のコンストラクタとして定義します。これにより、コンパイル時に「認証されていないのにユーザー名が存在する」といった不正なデータ構造を排除できます。
サンプルプログラム
以下のコード例では、直交性の低い定義と、高い定義を比較しています。
— 直交性が低い定義（不正な状態が作れてしまう）
— 認証されていないのに名前がある、という矛盾したデータが作れる
data UserStatus = UserStatus {
isLoggedIn :: Bool,
userName :: Maybe String
}
— 直交性の高い定義（状態が独立している）
— 認証済みか否かでデータ構造を明確に分離する
data User
= Guest — ゲスト状態にはデータを持たせない
| Registered String — ログイン済みには名前のみを保持
— パターンマッチも非常にシンプルになり、組み合わせ爆発を防げる
handleUser :: User -> String
handleUser user = case user of
Guest -> “こんにちは、ゲストさん”
Registered name -> “こんにちは、” ++ name ++ “さん”
応用・注意点
現場でこの設計を導入する際は、「このデータは同時に存在し得るか？」という問いを常に投げかけてください。もし、あるフィールドが特定の条件でしか意味をなさないのであれば、それはデータ型を分けるべきサインです。
注意点として、直交性を意識しすぎると型定義の数が増えすぎることがあります。過剰な細分化はコードの可読性を下げる可能性があるため、「ドメイン上の関心事」と「単なる属性の分離」を区別し、ビジネスルールにとって意味のある境界線で型を分けるのが、実務における適切なバランス感覚となります。
コメント