概要
グローバル状態は、コードの見通しを曇らせる最大の要因の一つである。
便利だが制御しにくく、依存関係を不透明にし、テストや再利用性を著しく下げる。
しかし、完全に排除することは現実的ではない。
だからこそ重要なのは、**グローバル状態を「管理する設計」**である。
本稿では、グローバル状態の構造的取り扱い、スコープ制御、依存性注入（DI）、状態の局所化による戦略的な状態設計について掘り下げる。
1. グローバル状態が持つリスク
let currentUser = null;
function login(name) {
currentUser = { name };
}
function greet() {
return `Hello, ${currentUser?.name ?? 'Guest'}`;
}
- ❌ 状態がどこで変更されたか分かりづらい
- ❌ テスト・拡張が難しく、複数のモジュールに影響
- ❌ モジュールの結合度が高まり、依存の方向が不明瞭に
2. スコープを絞った状態管理（クロージャ戦略）
function createUserStore() {
let user = null;
return {
login(name) {
user = { name };
},
getUser() {
return user;
}
};
}
const userStore = createUserStore();
- ✅ 外部からの直接操作を防ぎ、インターフェース越しにアクセス
- ✅ 閉包によるスコープ制御で安全性とテスト容易性が向上
3. 依存性注入によるグローバル回避
function greet(userStore) {
const user = userStore.getUser();
return `Hello, ${user?.name ?? 'Guest'}`;
}
- ✅ 依存関係を引数として受け渡す
- ✅ モジュールの独立性が保たれ、モックの注入も容易
4. モジュールスコープでの状態保持
// userStore.js
let user = null;
export function login(name) {
user = { name };
}
export function getUser() {
return user;
}
- ✅ 共有状態は モジュールの中で閉じ込める
- ✅ 名前付きエクスポートで明示的に責務を表現
5. UIレイヤにおける状態管理（React/Vue等）
const [user, setUser] = useState(null);
- ✅ グローバルでなく、ローカルな状態を必要な単位で管理
- ✅ グローバルが必要な場合でも Context API / Store構成で管理レイヤを定義
設計判断フロー
① その状態は複数箇所からアクセスされるか？ → ストアとして分離
② 外部から直接操作できてしまうか？ → クロージャまたはモジュールで制御
③ テストで状態を差し替えたいか？ → DI設計に変更
④ 状態が不透明に変更されていないか？ → getter/setter型のインターフェース導入
⑤ 将来的に非同期 or 永続化される可能性は？ → ストア層で切り出しておく
よくあるミスと対策
❌ 直接 window.X = ... でグローバル注入し、デバッグが困難に
→ ✅ モジュール or ファクトリを用いて明示的に設計
❌ 状態の変更箇所が散乱してトラブルシュート困難
→ ✅ setX, getX のインターフェース越しに管理統一
❌ グローバル状態を変更する関数が無制限に増殖
→ ✅ 状態のスコープと依存性を制御する責務分割を導入
結語
グローバル状態は「悪」ではない。
だが、それが制御されないまま野放しになることが危険なのだ。
- スコープを限定し、インターフェース越しに制御する
- 状態の変更経路を明示し、依存性の方向を単純化
- 必要なときだけ、必要な形で、安全にアクセスする
JavaScriptにおける状態設計とは、
“変更と依存を予測可能にし、構造の中で責務を分離することで、保守性と拡張性を保証する戦略である。”