概要
JavaScriptではオブジェクトの変更がデフォルトで許可されているが、**意図せぬミューテーション（変更）**は予期せぬバグの温床になる。
この問題を制御するために導入されるのが、不変性（immutability）の概念。
Object.freeze() を使うことでオブジェクトをミューテーション不可能にできるが、実はこれには浅い制約しか与えられない。
本稿では以下の観点から、不変性を“設計”として導入する方法を提示する：
-
Object.freeze()の正しい理解と限界 - 深いネスト構造における凍結の再帰処理
- 状態管理における構造共有戦略（Structural Sharing）
- ライブラリを用いた実用的な不変性管理（Immer, Immutable.js）
Object.freeze() の基本挙動
const obj = {
name: 'Toto'
};
Object.freeze(obj);
obj.name = 'Changed'; // ❌ 無視される（strictならエラー）
console.log(obj.name); // 'Toto'
- ✅ プロパティの変更・追加・削除が不可
- ✅
Object.isFrozen(obj)で凍結状態を判定可能 - ❌ ネストされたオブジェクトは対象外（浅い凍結）
浅い vs 深い凍結
const deep = {
outer: {
inner: 'value'
}
};
Object.freeze(deep);
deep.outer.inner = 'changed'; // ✅ 変更される（freezeの対象外）
→ ✅ 深い構造では再帰的に凍結する必要あり
再帰的なディープフリーズの実装
function deepFreeze(obj) {
Object.freeze(obj);
for (const key of Object.keys(obj)) {
const val = obj[key];
if (typeof val === 'object' && val !== null && !Object.isFrozen(val)) {
deepFreeze(val);
}
}
return obj;
}
→ ✅ オブジェクト全体を凍結する安全な関数
不変性の設計的メリット
| 効果 | 説明 |
|---|---|
| 副作用の制御 | 状態が変更不可 → 安全な関数設計が可能 |
| デバッグ容易 | どこかで書き換えられた問題が原理的に起きない |
| パフォーマンス最適化 | 構造共有により shallow compare が可能 → React等で有効 |
| テストの一貫性 | オブジェクトが状態を変えないため、再現性の高いテスト設計が可能 |
状態管理における構造共有戦略（Structural Sharing）
const state1 = { a: 1, b: 2 };
const state2 = { ...state1, b: 3 };
console.log(state1 === state2); // false
console.log(state1.a === state2.a); // true（構造共有）
→ ✅ ミューテーションせず、新しいオブジェクトを作る
→ ✅ React, Redux, Vuex などでの変更検知に最適
ライブラリ活用：Immerによる不変性の“開発体験改善”
import { produce } from 'immer';
const base = { count: 0 };
const next = produce(base, draft => {
draft.count += 1;
});
console.log(base.count); // 0
console.log(next.count); // 1
- ✅
draftを書き換えるように書いても、元オブジェクトは不変 - ✅ 内部的に構造比較＋差分追跡 → 効率的な新状態を生成
Immutable.jsによる完全な不変コレクション
import { Map } from 'immutable';
const map1 = Map({ a: 1, b: 2 });
const map2 = map1.set('b', 3);
console.log(map1.get('b')); // 2
console.log(map2.get('b')); // 3
- ✅ 内部的に構造共有された不変コレクション
- ❌ 学習コストと専用メソッドの多さがデメリット
設計判断フロー
① 明示的に変更をブロックしたい？ → Object.freeze
② 深い構造も含めて凍結したい？ → deepFreeze関数を導入
③ 状態のミューテーションを避けつつ操作性を保ちたい？ → Immer
④ 大規模な不変データ管理が必要？ → Immutable.js
⑤ リアクティブな変更検知を最適化したい？ → 構造共有の実装
よくある誤解
❌ Object.freeze() で全ての変更がブロックされる？
→ ❌ ネストされたオブジェクトはそのまま変更可能
→ ✅ deepFreeze() を使う or ライブラリ利用が安全
❌ Object.freeze() はセキュリティ機構？
→ ❌ いいえ、設計的ガードであり、完全な秘匿化ではない
→ プロパティは Object.getOwnPropertyDescriptors() で依然可視
結語
Object.freeze() は、単なる構文ではない。
それは「データが書き換わらないという保証」を設計上に持ち込むための契約である。
- ミューテーションの副作用からロジックを解放し、
- 状態の変化を構造として明確に定義し、
- アプリケーションの一貫性と予測性を高める
不変性とは、変わらないという“前提”をコードに刻むことで、信頼できる設計を作る技法である。