カプセル化の極意：JavaScriptとTypeScriptにおけるPrivate/Protectedプロパティとメソッドの完全理解
モダンなフロントエンド開発において、堅牢なアプリケーションを構築するための鍵は「情報の隠蔽」にあります。JavaScriptがECMAScript 2022で公式にプライベートクラス機能を導入し、TypeScriptが長年提供してきたアクセス修飾子と統合されたことで、JavaScriptのクラス設計はかつてないほど洗練されました。本稿では、PrivateおよびProtectedプロパティ・メソッドの概念、実装、そして実務におけるベストプラクティスを網羅的に解説します。
カプセル化の重要性とアクセシビリティの概念
オブジェクト指向プログラミングにおける「カプセル化」とは、内部の複雑な状態を外部から隔離し、公開されたインターフェースのみを通じて操作を許可する設計手法です。これを実現するために用いられるのがアクセス修飾子です。
JavaScriptおよびTypeScriptには、主に以下の3つのアクセスレベルが存在します。
1. public（デフォルト）：どこからでもアクセス可能。
2. protected：クラス自身および継承したサブクラスからのみアクセス可能。
3. private：定義したクラス内部からのみアクセス可能。
これらを適切に使い分けることで、外部から不適切な値が代入されることを防ぎ、内部ロジックの変更が外部のコードに影響を与えるリスクを最小化できます。
TypeScriptにおけるアクセス修飾子の実装
TypeScriptでは、コンパイル時にこれらの修飾子をチェックし、安全性を担保します。
class UserProfile {
private id: string;
protected role: string;
public name: string;
constructor(id: string, role: string, name: string) {
this.id = id;
this.role = role;
this.name = name;
}
public getPublicInfo(): string {
return `Name: ${this.name}`;
}
protected getInternalId(): string {
return this.id;
}
}
class Admin extends UserProfile {
showInfo() {
// console.log(this.id); // エラー: 'id' は private なのでアクセス不可
console.log(this.role); // 成功: 'role' は protected なのでアクセス可能
}
}
このコードにおいて、`private`な`id`は`Admin`クラスからすらアクセスできません。一方で`protected`な`role`は継承関係にあるクラス内であれば安全に利用できます。
JavaScriptネイティブのプライベート機能: #接頭辞
ECMAScriptの仕様として導入された`#`接頭辞によるプライベートフィールドは、TypeScriptの`private`修飾子とは挙動が異なります。TypeScriptの`private`はコンパイル時のチェックに留まりますが、`#`を用いたプライベートフィールドは、ランタイム（実行時）においてもクラス外部からのアクセスを完全に遮断します。
class SecureData {
#secretKey: string;
constructor(key: string) {
this.#secretKey = key;
}
#calculateHash(): string {
return btoa(this.#secretKey);
}
public getHash(): string {
return this.#calculateHash();
}
}
const data = new SecureData("my-secret");
// console.log(data.#secretKey); // SyntaxError: 外部から直接アクセス不可能
// console.log(data.#calculateHash()); // SyntaxError: 外部から直接呼び出し不可能
実務においては、ライブラリ開発などで「絶対に外部から触れられたくない内部状態」を定義する場合、TypeScriptの`private`よりも、この`#`構文を利用することが推奨されます。
Protectedの正しい使いどころ：テンプレートメソッドパターン
`protected`は、継承を前提とした設計において非常に強力な武器となります。特に「基本構造は固定しつつ、特定の部分だけサブクラスでカスタマイズさせる」というテンプレートメソッドパターンにおいて真価を発揮します。
abstract class DataFetcher {
public async fetch(): Promise {
const data = await this.performFetch();
return this.processData(data);
}
// サブクラスで実装を強制する抽象メソッド
protected abstract performFetch(): Promise;
// サブクラスでオーバーライド可能なフックメソッド
protected processData(data: any): any {
return data;
}
}
このように、`protected`メソッドを公開インターフェースの一部として設計することで、クラス間の契約（コントラクト）を明確化し、継承関係を整理できます。
実務アドバイス：アクセス制御の設計指針
実務の現場では、以下の指針に従うことで保守性の高いコードベースを維持できます。
1. デフォルトは常にprivate：
最初はすべてのプロパティをprivateにしておき、外部から必要なものだけをgetter/setterやpublicメソッドとして公開する「最小権限の原則」を守りましょう。
2. 継承を避ける（Composition over Inheritance）：
`protected`を多用しなければならない設計は、継承が深くなりすぎているサインです。可能であればコンポジション（合成）を利用し、クラスの責務を小さく保つことを優先してください。
3. TypeScriptのprivateと#の使い分け：
– TypeScriptの`private`：コードの意図を明示し、開発中の型安全性を確保する。
– JavaScriptの`#`：ランタイムでの厳格な隠蔽が必要な場合（機密情報や、APIの互換性を破壊したくない内部実装など）。
4. テストの際の注意点：
privateメソッドを直接テストしたいという欲求は、そのメソッドが「単体でテスト可能な別のクラスや関数として切り出せるのではないか」というリファクタリングの合図です。無理にprivateを公開してテストするのではなく、責務の分割を検討してください。
まとめ
PrivateおよびProtectedプロパティ・メソッドは、単なる機能制限ではありません。それは「このクラスが何を隠し、何を公開するか」という設計の意思表示です。
フロントエンド開発が大規模化する現代において、不適切な状態共有はバグの温床となります。TypeScriptの型システムによる静的な保護と、JavaScriptネイティブの`#`によるランタイムの保護を適切に使い分けることで、チーム開発における認知負荷を下げ、堅牢で拡張性の高いコードを記述することが可能になります。
まずは現在のプロジェクトで、`public`として定義されているプロパティを見直し、本当に外部公開が必要なものだけを残すリファクタリングから始めてみてください。それが、プロフェッショナルなエンジニアへの第一歩です。
コメント