Interfaceのメソッド定義：関数型プログラミングとオブジェクト指向の境界線
TypeScriptの型システムは、その構造的型付け（Structural Subtyping）の美しさによって支えられている。しかし、初学者が陥りがちな罠であり、大規模アーキテクチャの設計者が常に直面する境界線の一つが 「Interface内でのメソッド構文による定義」 と 「関数型プログラミング（FP）を意識したプロパティ構文（アロー関数型）による定義」 の選択である。
一見すると、これらは単なるシンタックスシュガーのバリエーションに思えるかもしれない。だが、コンパイラの型評価、V8エンジンにおけるメモリ最適化、そしてメソッドのバインディング（`this`のコンテキスト）の挙動を追うと、両者の間にはランタイムとコンパイルタイムの双方において看過できない深い断絶が存在することがわかる。
本稿では、この「オブジェクト指向的なメソッド構文」と「関数型的なプロパティ構文」の境界線を、コンパイラ内部の挙動とランタイムの低レイヤの視点から完全に解剖する。
—
1. コンパイラ視点での決定的な違い：Bivariance（共変・反変）と型チェックの厳密性
まず、TypeScriptコンパイラ（tsc）がこれら二つの構文をどのように型評価しているのかを確認する。
以下のコードを見てほしい。
interface ObjectOriented {
// メソッド構文
execute(data: string): void;
}
interface Functional {
// プロパティ構文（関数型）
execute: (data: string) => void;
}
この二つは、厳密には等価ではない。最大の差異は メソッド引数の共変性（Covariance）と反変性（Contravariance）のルール である。
TypeScriptにおいて、オブジェクトのメソッド構文（Method Syntax）の引数は、歴史的な理由（JavaやC#などのOOP言語との互換性、および配列のミュータビリティに関する実用上の配慮）から、Bivariant（双変） として扱われる。一方、関数プロパティ（Property Syntax）は、厳格な関数型の原則に従い Contravariant（反変） として扱われる。
class Animal { name = “animal”; }
class Dog extends Animal { bark() { console.log(“wan”); } }
// — パターンA: メソッド構文 —
interface HandlerOOP {
handle(animal: Animal): void;
}
const dogHandlerOOP: HandlerOOP = {
// 引数に「Dog」を受け取る関数を代入してもエラーにならない（双変の挙動）
handle(dog: Dog) {
dog.bark();
}
};
// — パターンB: プロパティ構文 —
interface HandlerFP {
handle: (animal: Animal) => void;
}
// 厳密な関数型規約（反変性）により、ここで型エラーが発生する可能性がある
// （※ strictFunctionTypes が有効な場合）
const dogHandlerFP: HandlerFP = {
handle(dog: Dog) { // Error: Type ‘(dog: Dog) => void’ is not assignable to type ‘(animal: Animal) => void’.
dog.bark();
}
};
`strictFunctionTypes`（通常は `strict: true` で有効化される）の下では、プロパティ構文は「`Animal` を受け取れるべき場所に、より狭い `Dog` しか受け取れない関数を渡すな」という厳格な型安全性を強制する。
しかし、メソッド構文はこの制約をバイパスし、開発者に「便利だが危険な緩み」を提供する。安全性を極限まで高めるシニアエンジニアの設計においては、意図しない型安全性の穴を生むメソッド構文は避けられ、プロパティ構文が好まれる傾向にある。
—
2. V8エンジンとメモリ最適化：Hidden Classes（隠しクラス）とShapeの固定
ランタイム（Node.js / V8）のメモリレイアウトの観点からも、この選択はパフォーマンスに直結する。
V8は動的言語であるJavaScriptを高速化するため、オブジェクトの「形状（Hidden Class / Shape / Map）」を内部で追跡し、インラインキャッシュ（Inline Caching: IC）を構築する。
メソッド構文の挙動
Interfaceに定義されたメソッド構文は、通常、そのオブジェクトを生成するコンストラクタのプロトタイプチェーン（`prototype`）上に配置される。
class ServiceOOP implements ObjectOriented {
execute(data: string) {
// 処理
}
}
// メソッドは ServiceOOP.prototype に存在し、インスタンスごとに複製されない。
これはメモリ効率の観点で極めて優れている。何百万個のインスタンスを生成しても、メソッドの実体はプロトタイプに一つだけ存在する。
プロパティ構文（アロー関数）の挙動
一方、インターフェースを満たすためにオブジェクトリテラルやクラスプロパティとしてアロー関数を定義した場合、それはインスタンスごとの固有のプロパティ（Own Property）としてアロケートされる。
class ServiceFP implements Functional {
// インスタンス生成ごとにクロージャがヒープ上に生成される
execute = (data: string) => {
// 処理
}
}
- メモリ消費の増大: インスタンスの数だけ関数オブジェクトのクロージャがヒープ領域（New Space / Old Space）を占有し、ガベージコレクション（GC）のプレッシャーを高める。
- Hidden Classの断片化: プロパティの初期化順序や動的な代入が行われると、V8のインラインキャッシュがミスヒットし、メガモーフィック（Megamorphic）な状態に陥って最適化が阻害される。
—
3. `this`のコンテキストバインディングとイベントループ・非同期キューの安全防壁
関数型プログラミングパラダイムを好む開発者がプロパティ構文（アロー関数）を採用する最大の理由は、`this`のレキシカルな束縛である。
オブジェクト指向のメソッド構文では、呼び出し元（Caller）のコンテキストによって `this` の指す対象が変わり、バグの温床となる。
interface WorkerInterface {
run(): void;
}
class SystemA implements WorkerInterface {
private id = “Core-01”;
// メソッド構文
run() {
console.log(this.id);
}
}
const worker = new SystemA();
const detachedRun = worker.run;
// ランタイムエラー、または undefined の出力
// 実行コンテキスト（Call Stack）において ‘this’ が失われるため
detachedRun();
これを防ぐため、イベントリスナーや非同期コールバック、タイマー（`setTimeout`, `requestAnimationFrame`）にメソッドを渡す際、オブジェクト指向コードでは `.bind(this)` やラッパー関数によるオーバーヘッドが発生する。
// 従来の防壁
setTimeout(worker.run.bind(worker), 1000);
プロパティ構文によるイベントループ・キューの安全確保
これに対し、プロパティ構文としてアロー関数を採用した場合、関数は生成時にレキシカルなスコープの `this` を完全にキャプチャ（クロージャ化）する。これにより、イベントループのコールバックキューに単体の関数参照としてプッシュされても、`this` の文脈が破壊されることはない。
interface SecureWorkerInterface {
run: () => void;
}
class SystemB implements SecureWorkerInterface {
private id = “Core-02”;
// プロパティ構文（アロー関数）
run = () => {
console.log(`Executing worker: ${this.id}`);
}
}
const secureWorker = new SystemB();
const safeQueue = secureWorker.run;
// イベントループのどのフェーズで実行されようとも、this は SystemB のインスタンスを指し続ける
setTimeout(safeQueue, 1000);
セキュリティや堅牢性が求められるアーキテクチャ（例えば、プラグイン機構やサンドボックス化されたイベントディスパッチャ）において、コンテキストのロストによる未定義参照エラーやプロトタイプ汚染のリスクをコンパイル時およびランタイムで完全に排除できる点は、プロパティ構文の圧倒的なアドバンテージである。
—
4. チーフアーキテクトが導く実践的指針：どちらを選択すべきか？
極限のパフォーマンスと型安全性を両立させるための判断基準を以下に定義する。
| 評価軸 | メソッド構文 (`method(x: T): U`) | プロパティ構文 (`method: (x: T) => U`) |
| :— | :— | :— |
| 型システムの厳密性 | Bivariant（緩い・柔軟） | Contravariant（厳格・安全） |
| メモリ効率 (V8) | プロトタイプ共有（高効率） | インスタンス毎にアロケート（低効率） |
| `this` の安全性 | 呼び出し元に依存（要 `bind`） | レキシカルに固定（安全） |
| ユースケースの適性 | 大量のインスタンスを生成するドメインモデル、クラスベースのOOP設計 | コールバック、イベントハンドラ、関数型パイプライン、DIコンテナのモック |
結論としてのアーキテクチャパターン
1. ドメインモデルやエンティティ層では、メモリ効率とOOPの伝統に則り、メソッド構文を採用する。ただし、コールバックとして外部に渡す場合は必ずラッパーまたはアロー関数経由で行う。
2. APIクライアント、副作用を伴うサービス層、イベント駆動型のコンポーネントでは、`this` のロストを防ぎ、厳格な関数型インターフェース（反変性）を強制するために、プロパティ構文（アロー関数）を採用する。
言語仕様の裏側にあるコンパイラの型評価ルールと、ランタイムエンジンのメモリモデルを完全に理解した上でコードベースの筆を執ること。それこそが、破綻なき極限のシステムを構築唯一の道である。